揭秘App外包开发秘密:一款外包App诞生的全过程(下)

日期:2017-01-24 13:33:00

今天这篇文章向你分享的是:如果你想开发一款App,而又没办法组建一个完整的开发团队,那么你如何借助外包公司来做好这件事;你如何去揽下立项、原型、系统、UI、交互这些所有的工作,而在几乎没有任何面对面的交流,一切想法都通过文档来跟外包公司沟通的情况下,最终拿到一个跟你的预期丝毫不差的精品App。

由于字数过多,这篇文章分为了上、下两篇来发表。你现在看到的是下篇。(上篇《揭秘App外包开发秘密:一款外包App诞生的全过程(上)》)

五、UI设计/切图/适配文档:左右脑同时开工来制作拟物UI

由于是拟物设计且注重颜值,「App」的UI制作将会耗费成吨的开发精力,既包括我要一个人承担所有的UI设计工作,也包括要耗费大量iOS外包开发的Manday——我没有机会出错。

我没有条件去盯着开发者的电脑,告诉他:"这里再往上1pt"、"这个按钮再往右一点"、"iPhone 6 Plus的启动icon再调大一点"——我必须在开发之前彻底讲清楚所有的问题,把每张切图、每个排版细节、每个机型的适配方法都考虑进去——只通过一套文档,中间几乎没有任何沟通,开发者只出一个版本,就让「App」的UI在所有iOS机型上完美呈现。

正式做UI之前,首先要做每张页面的概念图,原则很简单——尽可能地偷懒,有些不重要的页面你甚至可以直接拿别人的截图来代替。我见过很多UI设计师在设计概念图时很纠结,来来回回对齐不同的图层,统一各种字号或颜色,这样的劳动除了让你多加班之外毫无意义。做概念图最紧要的就是"洒脱"二字。

不要有太多顾虑。当我做页面B的时候,我无需去考虑它的美术风格是否要跟刚刚做的页面A统一起来,因为说不定我在页面B上突然有了很好的设计灵感,做出了比页面A更漂亮的界面,那么反过来我重做页面A就是了。把每个页面当做一个独立的平面稿来设计,这将大大节省你找到最优设计方案的时间。

(1/2)文件夹页面的概念图(左)

在几天的概念设计之后,我发现其中2个页面比较有意思。第一个是文件夹页面,这个页面是用户在首页(上图右)点击某个文件夹之后跳转进来的。我发现,如果让文件夹页面变成墙壁的延伸(上图左)会很有意思——用户在首页点击某个文件夹之后,其余的文件夹直接消失,整个墙壁(包括光照)直接往右边平移,挪出左边的空间,然后文件夹下面的纸张统统飞到右边,形成文件列表。在我跟智超讨论之后,这套酷炫的转场效果被暂时搁置,因为我承担不起它所耗费的Manday,不过这并不影响我把文件夹页面确定成这样的设计,因为它最符合故事的情境。

(2/2)写作页面的概念图

第二个让我感兴趣的是用户写东西的页面(上图),我当时找来了很多主流日记、记事App的写作界面截图,发现其中那些比较优秀的UI都有几个共性:

  1. 文字一定要大,行间距和段间距也要大,这样你就算只写几十个字也很有成就感,仿佛是写了一篇大作。
  2. 光标不能用默认的,要用大的,闪烁起来要有呼吸感,而且最好不要被行高限制住,要往下延伸到下一行的顶部,这样能激发人的写作欲望。
  3. 最常用的按钮不要放在顶部,而是放在键盘上面,而其中最重要的那个按钮要放在右边,这样写完了之后不用抬手,右手大拇指轻松就能点到保存(老罗调研过,手机用户中,右手为主的用户比例虽然低于生活中右手为主的人,但还是轻松超过一半)。

所以,我就截了几张UI放进设计稿里,简单拼凑了一下,照葫芦画瓢做了个左图中的UI,顺便把键盘改成跟上半部分统一的黑白色(iOS原生输入法可以定制颜色)。

我觉得这样的写作页面没有什么需要画蛇添足的地方了,再减一个元素就影响使用,再加一个元素就导致臃肿,那么现在我手上有两个页面的UI概念图都达到了我要的标准。

但问题是,它们一个是纯拟物,一个是纯扁平,这要如何是好?经过思考,虽然「App」强调的是拟物,但是我可以把"拟物层"和"操作层"做成两种对撞的风格——所有关于纸张、墙壁这些"物理环境"的设计都做成纯拟物,而所有交互的内容都做成纯扁平的,这样看起来效果最好。如果我一根筋地去把所有的交互界面都做成拟物的,反而会弱化纸张和墙壁的拟物感。所以我决定把"操作层"做成扁平的,让薄如蝉翼的"操作层"漂浮在厚重的"拟物层"之上,就会在带来沉浸感的同时,给人一种操作起来很轻便的感觉。

依照这种设计思路,扁平和拟物的风格不需要强行统一,反而是对比越强烈效果越好,这就让我面临一个问题:怎样的扁平设计是最纯粹的?

你认为哪个扁平设计更纯粹?

左图是一个很纯粹的扁平UI设计;右图相反,是一个四不像的扁平UI设计。左图之所以够纯粹,仔细观察可以发现原因:

  1. 虽然颜色看起来很缤纷,但除了不同透明度的白色之外,实际上只有黄、蓝对撞色。
  2. 所有的图形,甚至包括字体,都是圆角的,圆角的半径也基本是相同的。
  3. 字体看起来很多,但实际上字体和字号都只有一种,看起来多只是因为颜色或加粗带来的效果。

当时研究了很多例子,发现优秀的扁平化设计,毫无例外可以用一个观点来概括:能用一种字号解决的,不要用两种字号;能用一种颜色解决的,不要用两种颜色……所以我就带着这种思路重新整理了一下其余的概念图(这就是为什么不要那么早确定设计标准),基本形成了「App」在"扁平化"部分的设计规范:

将所有系统字精简为"大"、"小"字

1、两种字体

(1)系统默认字体

除了用户自己写的文字内容需要单独来制定字号、行距、段间距之外(因为这个内容最重要,需要区别设计),其它情况尽量用2种规格来解决(见上图),那就是"大字"和"小字"。在设计规范中,我分别定义了两种字体的字号、行距、段间距。

得到它们具体规格的手段很简单,就是去复刻那些优秀App界面中的字体,把它们应用到你设计稿中的若干个主要页面中,输出成几个重要机型的效果图,分别放到这些机子中去看实际效果,反复微调几次就基本搞定了。在这个过程中,不要像很多人那样,总是填上那些排版最好看的文字内容,而是要尽可能让文字的排版丑陋。例如,一行字多出一个字跑到第二行,连续两次空行,连续敲很多个句号……你永远无法预测到用户会输入什么文字,如果你能在文字最不适合排版的情况下,也能保证排版看得过去,那么你设置的字体才是最有适应力的。

用"刻宋"体作为交互类字体,提升UI档次

(2)自带字体

这是由于我发现,之所以很多中文App用同样的设计方法来做扁平化UI却比不过欧美,很大程度上是因为字体的丑陋。

扁平化设计中,字体是很主要的视觉元素——英文App可以随随便便就嵌入一个几十k的字体,而中文App嵌入一个字体就意味着多几M的大小,而且简体字体制作成本超大(5000多个常用字),做出来也很少人有付费意识去买正版,所以精益求精的字体也很少。于是我购买了为数不多非常耐看的造字工房的"刻宋"体,除了一些非常重要的标题之外(例如用户自己起的标题),我将尽量让它只拥有一个最适合手指点击的字号,用来担任绝大多数点击类的字体。

黑白是更纯粹的扁平化设计

2、黑白设计

既然扁平化越纯粹,就能越凸显拟物和扁平的反差之美,那么我能想到的最极致的方案就是全黑白设计。市面上大多数App的UI设计滥用各种颜色,到处都是不同的彩色:这里需要强调,于是用绿色,那里更需要强调,于是用红色,还有个地方是重大通知,于是就用红色加粗加大,弄到最后,就变成了电线杆上的老军医广告。最极致的扁平化设计,就是拿最少的元素,把它们组合成最合理的视觉搭配,让它们自然地形成主次之分和操作引导。如果非要用红色才能突出某个视觉重点,只能证明我的版式设计还不够智慧。

《版式设计原理》,佐佐木刚士

关于版式设计,我当时买了佐佐木刚士的《版式设计原理》,版式设计是日本的传统强项,而且日语跟中文在视觉上有很多类似之处,它们都不能完全照搬英语系的版式设计美学。纸质读物的设计元素很有限,大部分内容都是黑色的字,没有现在手机UI那么多变的视觉表现力,那么在设计元素匮乏的情况下,怎样区别不同内容的轻重程度,让读者能自然地按照你设想的顺序去阅读这些内容,这就是版式设计的智慧。从以前的纸质杂志到现在的扁平化UI,变化的是媒介,不变的是人类的视觉习惯。

化繁为简的"设计规范"

把每个页面的效果图基本跑通,然后尽我所能地抽象其中的设计元素,我就得到了上图这些设计规范,具体包括:导航栏的布局、常用对齐线、常用图文按钮排布方式、常用列表类页面布局等等……这就是我为什么强调一开始做概念图的时候不要先确定设计规范,而是放开灵感去做,因为它们实在太难以预测了。只有把所有页面效果图确定到七七八八,你才能看到你需要多少种字体、多少种透明度、多少种对齐线……设计规范是用优质的概念图总结出来的,而不是一开头就拍脑袋决定的。

基本确定了设计规范之后(并不是说要100%确定下来,因为在具体设计的过程中,设计规范的添加或修改是在所难免的),接下来就是做正式效果图,这个环节跟扁平化UI设计会有一些不同:

1、100%还原图

扁平化设计中,你可以只做大致的效果图,做效果图的目的只是确定UI文档该怎么写,前端看的是文档,效果图只是视觉参照。在一个优秀的扁平化UI制作流程中,几乎所有设计素材都是单独储存的,有一个完整的素材库,只需按照设计规范把这些素材一个个摆进设计稿里就行了,而在设计稿里新产生的素材也会被迅速加入素材库中。最后它们可以从素材库里一次性切图。

拟物元素不能相互遮挡

但在「App」中,很多视觉元素是拟物的,如果我不在正式界面里做到100%还原,我就没法确定一个文件夹的封面是不是会不小心压住上面的吊灯(上图左);也没法确定文字的标题是否会跟"孔"重叠起来(上图右)。因此,我必须把涉及到拟物的页面效果图做到100%还原,以此来撰写我的适配文档。

2、最大机型画布

扁平化设计中,一般效果图只需要做一个大小适中、主流的机型,例如很多人在设计iOS App时只做iPhone 6的效果图。然而,位图跟矢量图不同,它只能缩小不能放大,所以我的100%还原图必须用6 Plus画布来做,因为很多拟物切图要直接从这里取材。

同时我还要另外去做各种小机型的,不必100%还原的效果图,来确保我的对齐方案在任何机型上都不会反常(例如,上文提到的,不能让封面遮住吊灯)。

鉴于以上两个原因,我就开始去做主要页面的iPhone 6 Plus 100%效果图。这里的"主要页面"包括两类,一类是需要从效果图中直接拿到切图资源的页面,也就是拟物设计非常强的一些页面;另一类是模板类页面,例如我们有三四个列表类页面,显然只做好其中一个就行了,其余的无需煞费苦心,只要一个大概的效果就足够了。

做完上述工作,就要开始出正式文件了。对于前端开发而言,需要的正式文件包括:效果图、适配文档、切图。这个章节的标题提到左右脑同时开工,之前的工作用右脑就能完成,而从这里开始就得用左脑了。

为了解决全部的适配问题,我先解决一个小问题,我的工作从这5张"纸"开始:

统一处理App中所有出现过的"纸"

这5张纸是「App」UI中所有会出现的纸,为了适配方便,我得把它们的文本位做成相同的。由于最右边两种纸的左上角有回形针,所以"标题"统一往下调整,以免压住回形针。

用RGB通道来确定"纸"的切图范围

纸的光环境是灯泡从右上角照过来,因此它阴影的边缘自然在左边和下边。为了拿到切图,我必须确定边缘,从效果图(左上)里直接找到边缘很困难,用通道+曲线很容易就找到了(左下)。有了左下角的边缘之后,我就能完整把它切出来。为了文本对齐方便,显然我在纸张的顶部和右边也要留相同的空隙,这样纸张切图"纸"的部分就能刚好处在切图的中心(右)。

形成"纸"的统一文档

那么接下来就是给这张通用的"纸"来写文档。见上图:

  1. 文本框的宽、高,以及它相对于这张纸切图的位置,我都用它们与切图尺寸的比例关系来表示。这样做之所以可以成功适配,是因为不论纸张有几种规格的切图(@3x、@2x,或以后更高规格的切图),我们要明白一个特点,那就是文本框与切图的比例关系是不应该发生改变的。
  2. 标题的底部距离文本框的高度,并不需要用具体数值来表示,而是可以刚好隔开一行文本的距离,那么在文档中我就定义这个距离=正文的字号。也就是说,假设正文的字号是12pt,那么它们的间隔就是12pt。这样做的好处在于,不论我怎么调整正文字体的大小,标题与正文看上去永远刚好隔着一行。
  3. 标题的字号不是一个具体的数值,而是正文字号的1.4倍。因为从设计上来讲,标题之所以看上去是标题,就是因为它比正文的字要更大或者更粗。1.4倍刚好可以体现这个关系。当我后期要调整正文字号的时候,标题就可以随之而改变大小,无需我手动去调整了。
  4. 纸张下方的小字,由于切图底部已经留出了空隙,所以直接让它0间距对齐就行了。

从上面整个文档来看,几乎所有的"约束条件"(元素之间的相对空间关系)都是用"比例"来表示,这就意味着,前端工程师只要把这套条件放进去,我们就无需考虑具体的机型,大到iPad小到iPhone 4都能完美呈现。同时意味着,如果我们对其中某个地方不满意,也无需去修改每个机型的数值,而是从宏观上去修改某个比例关系就行了。

而唯一能影响这些比例关系的变量就是正文的"字号"(切图大小是固定的,所以它不会影响比例关系),所以接下来就是来定义这个"字号"了。

(1/2)"日记字"在"纸"上的不同大小

首先,见上图,这张纸在iPhone 6P的3倍图里,和在iPhone 6/5/4的2倍图里,有两种不同的大小。(2倍图是共用的,我必须在最窄的屏幕(iPhone 5s、5和4)中确定2倍图的大小,以免纸张太大,遮住了右边的吊灯和封面)3倍图比较大,2倍图比较小,如果字号相同,那么2倍图容纳的字数就会少很多。然而,从产品理念上来讲,我希望不同机型上的纸所容纳的文字摘要字数基本相同,因为字数太多会导致很多纸张显示不满,给人一种空虚的感觉;而字数太少就没法形成摘要,每张纸都要点进去才能知道具体写的是什么。

为了满足这个理念,具体某个分辨率纸张上的字号,就应该跟纸张的大小挂钩。纸越大,字号就越大,纸越小,字号就越小——这样就能保证每个机型所显示的摘要字数相近。这个概念确定之后,先别急,再来看阅读界面的字体。

(2/2)"日记字"在阅读界面的不同大小

感觉到了吗?在阅读界面,同样是这个道理(如上图)。如果我只设置一种字号,那么要么是6plus用户觉得字太小,写很多内容都撑不满屏幕,没有成就感;要么就是小机型用户觉得字太大,一屏幕只能看几句话——我同样应该设计成:大屏幕字大,小屏幕字小,所以,结合上面的"纸",你应该猜得到我打算怎么做了——

用一句话来概括所有的"日记字"

如图,所有机型,不论是阅读页面的字,还是纸上的正文,它们用这简简单单一套规则就可以概括了。我们确定唯一的参照标准,就是当文本框宽度为363pt的时候,字的大小、行距、段间距分别是21pt、10pt、14pt,而其它所有的情况,无论是6plus纸上的字号,还是iPhone 4阅读界面的字号,都从文本框的宽度直接换算比例得到。

以上就是「App」UI制作的核心思想:把几种机型几十个页面的不同元素,从设计的角度把它们归纳起来,用一层一层的变量关系来嵌套,像一棵树那样,追溯到最后,它只有为数不多的几个数值。改变这几个数值就能改变整个App。

这些为数不多的数值就是前端层面的"设计规范",它与UI制作的"设计规范"实际上是一式两用的。在前端上,它们形成了设计规范的"宏",这个宏定义了UI适配中的所有变量。当我描述一个长度的时候,我并不说这个长度是15pt,而说它是1.3{小字},这里的{小字}就是一个变量,往前追溯,就能查询到我对"小字"事先约定的设计规范。

下面再举几个例子。

一套规则,适应所有机型

在上图中,由于中间的选项文字的段落属性是居中的,所以确定左右25%的对齐线就能让他们容纳最大字数的内容,而不会超出屏幕。唯一需要用数值来表示的是这些具体选项之间的间距,这里定义它是43pt,因为经过测试,小于这个距离就容易误触(这类情况比较少,否则可以定义一个叫做{最小按钮间隙}的变量)。然后,这个主要模块当然可以定义成居中于屏幕,于是我们就可以进一步定义:上、下模块各自从剩余的空间中取得中心对齐线——整个界面只有1个具体数值,其余都是变量,且适配于所有机型。

同样,一套规则,适应所有机型

在跟用户写的文字相关的界面中(例如上图),用户的文字是{日记字}的格式,它是这些界面视觉的核心,所以大部分的间距都要跟着{日记字}的段间距来走。确定了大致的视觉之后,把各种间距换算成它与{日记字}的比例关系。当屏幕变大变小,{日记字}会随之变大变小,而不同的间距都会随之变大变小,但它们看起来永远是和谐的,因为思考这些变量关系本身就是在思考"各种视觉元素以何种比例关系呈现出来才是最有美感的"。

将所有切图汇集到素材库,统一管理

当切图都汇集到素材库(上图)之后,还要给每类切图都单独制作一份适配文档,这是由于拟物UI的复杂性导致的。扁平化UI中,一般我们会把一个具体的切图定义为只有一个规格,例如不管在3倍图还是2倍图中,某个按钮的大小都是30pt * 50pt,这样它在不同的分辨率中都会有相近的物理大小。

BTW:

之所以手机开发用的单位不是px(像素)而是pt(点),就是因为每款手机的像素颗粒大小不同,屏幕的精度(ppi)越高,单个的像素就越小。

假设你定义一个字的字号是99px,这就意味着这个字的高度是99像素,你在你的电脑屏幕上看它有一个樱桃那么大,在iPhone 4里看它有大拇指指甲盖那么大,但是在iPhone 6 plus里看起来就只有黄豆那么大了。这是因为6plus的屏幕精度很高,在一个黄豆的尺寸里就有99 * 99个像素。

所以为了设计师的方便和机型的转换,大家就设计了pt这个单位,你在iPhone 4的效果图里设计了一个60* 60像素的图标,放到iPhone 4里看起来是一个小拇指盖的大小,你觉得刚刚好。那么由于iPhone 4的1pt = 2px,所以你就告诉程序员说,这个图标的大小是30 * 30pt。

某一天你打开iPhone 6 plus,发现这个图标看起来也是小拇指盖的大小,这是因为6plus知道自己像素很小,所以它告诉你的App说"我的1pt = 3px哦",所以你的App就自动把这个图标放大到90 * 90像素给它了(当然前提是你切图格式是矢量pdf,否则就模糊了)。

过了10年,iPhone 100问世了,它的像素密度已经高到了匪夷所思的程度,但是苹果工程师聪明地设置了1pt = 1000px(当然了,这已经超过人眼极限,这里只是夸张举例),所以你这个App在iPhone 100里打开,它依然是小拇指盖的大小。

——跨越不同终端不同屏幕之间的差异,为人的眼睛去寻找一个统一的标尺,这就是pt这个单位存在的意义。

封面图必须完美嵌入纸堆,不能有丝毫误差

然而,「theApp」中的某些拟物元素并不能依据我们想要展现的物理大小来决定,而是要依据它与周围元素的位置关系来决定。例如上图中,封面的图片必须完美地嵌入封面的切图中,不能有1pt的误差,否则看起来就不像是一个整体。这个时候,只能是下苦功,分别制作@3x、@2x两个规格的切图,然后老老实实量出图片位的具体大小。

用切图的留白,来代替复杂的适配

也有一些适配情况是极难用变量来描述的。例如,在上图左的界面里,封面的两张切图要完美契合在一起,非常难适配,所以我就干脆把这个工作揽过来,直接在效果图里设计好切图,给这些切图上下左右预留好精准的空隙。这样,程序员就无需适配,直接让两个切图中心对齐,就能呈现出最完美的视觉效果。

动画效果"冲击波"的时间轴设计

交互效果的设计则简单很多,我们同样先确定一些变量,然后用这些变量来描述具体的时间轴就行了。如果你使用过Flash或其它动画、特效软件,你一定很熟悉时间轴。实际上,你越熟悉时间轴,你就越不需要去做真正的动画给程序员看,因为你能在脑子里很轻松地视觉化这些时间轴,很确定它能实现你要的效果。

不过要注意的是,变量的设计要巧妙,用最少的变量来给你的动画埋下最多的后期可塑性。例如上图是"冲击波"效果的时间轴设计,我设计了变量o,调整o就能调整整个动画的速度,而调整4o为其它倍数(例如5o、3o)就能调整"冲击波"的宽度,两者一起调整就能实现很多不同的视觉效果。

整个UI制作的过程是很苦的,但最终我实现了预期的设想——仅通过一次开发,「App」的UI就基本在所有机型达到了完美的适配效果,后续的改动也很轻松,因为都是针对变量和比例关系的改动,无需在每个具体机型中反复调整。「App」在这个阶段省下的Manday足够开发一个同级别的产品。

六、成本控制:虚拟迭代

「App」曾经开发过1.0版本,虽然我对它的操作体验下足了功夫,但是体验只是给你产品加分的东西,它掩盖不了一个产品的致命伤。如下图,当时的设计是这样的:

1.0版本的"微博"设计

假设一个想要写下一条人生方向,例如:"我最致命的缺点是过分思考却不行动",这条人生方向就形成了一篇"微博",而每当这个人有了关于对"过分思考却不行动"的新看法,在生活中对它有了新的体验,或是看到一篇文章讲的也是这个话题,他都可以附带上新的观点来"转发"这条微博。

当他每天打开某个文件夹,例如这篇文章所在的"行动的巨人"文件夹,他就看到了一个完整的微博小站。这些微博默认按照时间流来排序,他可以看到他最近转发了什么,原创了什么。而当他切换到另一种排序方法的时候,「App」只向他展示原创的微博,而且那些转发次数最多的将会排在最前面,提醒他最重视的人生信念是什么。

上线前我对这套逻辑信心满满,然而上线后才使用了两周,我就发现了其中的大问题。其一,越是转发次数越多的微博,我就对原文越不满意,因为我的思考一直在往前走;其二,当我灵感一现,想要掏出「App」来写东西的时候,我往往会愣住,因为我不记得我有没有写过类似的"原创",如果有,我也很难第一时间找到它来转发。于是,我往往都是写去写一篇新的原创,这套转发机制逐渐成了摆设;其三,转发次数最多的微博,并不一定是我最应该去坚持的人生信念,有时候,它反而代表一个我走过很多弯路的错误信念。

从这件事情之后,我决定「App」以后每个版本在开发之前,都要经历足够多的"虚拟迭代"。这个名词是智超后来帮我总结出来的,它的含义是:在产品真正投入开发之前,尽最大努力在内心去虚拟这个产品上线之后真正的样子,不断地"使用"这个产品,从这个"使用"过程中提前发现产品的问题,不经过开发,直接进行下个版本的迭代。

如果一个产品原先要开发10个版本才能成功,通过虚拟迭代,你可能用3个版本就能达到同样的效果。由于「App」是外包开发,所以我这边"虚拟迭代"的时候,外包公司的人力费用并不需要我承担,所以你可能会说,我的情况并不能适用在一个需要每天养活开发团队的公司里。

但是反过来讲,为了让设计组、程序组不空转,就强行赶鸭子让产品组草率地设计一个版本出来,其中很多问题都没有仔细验证,上线之后立刻就改需求,一个想法接着一个想法,源代码被弄得千疮百孔,产品实际要解决的问题却还没找到关键的门路,随时面临打倒重来的危险,这样难道就是有效率的企业运作方式?

PM一个人再厉害也有很多情况是考虑不周的。当产品设计在不断"虚拟迭代"时,设计和开发组不必那么快就进入正式开发的工作,设计组可以趁这个时间多做一些概念图,跟PM一起把产品视觉确定下来,一起跟前端工程师去探讨每个细节的可行性。而开发组则可以提前梳理产品需要的模块和技术,提前攻破某些技术难点,跟PM一起讨论每个产品模块的性价比:哪些该做,哪些该寻找替代方案……所有人坐在一起讨论产品未来可能的走向,以便提前设计好一个拓展性最强的框架,减少未来迭代的成本——最好的产品一定是这个团队所有人作为一个整体来完成的,强行划分成策划、UI、开发的步骤,或是强行说:"你是UI设计师,你不要参与功能设计"、"我不管你们怎么设计,我等你的文档出来然后写代码",这跟工厂流水线生产罐头又有什么区别呢?

把产品设计在脑海里具象化

在「App」开发中,虚拟迭代分两步,第一步是让我在脑海里具象化这个App上线之后的样子,所以我会把效果图都贴在白板上,盯着他们看,想象自己在这些页面跳转;我也会拜托智豪同学帮我把效果图摆进墨客或Axure里,做成一个可以在手机里点击的高仿真H5原型。

当我从这一步中建立了我对这个App整体的视觉和操作记忆之后,我就会进行下一步,那就是做一份Word文档格式的"「App」",它很像桌游,我当做自己在使用真正的「App」那样操作它,每天记录很多东西,就像是在使用真的App一样。

我在办公室、咖啡厅、湖边和菜市场写东西,我在醒着和睡着的时候写东西,几个月里写了十几万字的个人思考和摘录。每当我在原型或效果图里觉得某个功能已经设计得很棒的时候,过不了几天我就会在"使用"Word版「App」时发现这样那样的问题,然后我就去修改设计方案,哪怕是打倒重来。

首先是第一次虚拟迭代。既然灵感来袭的时候,我也不知道到底该"原创"还是"转发",那么就去掉它们之间的差别——所有写下的东西都是一篇"感悟",我每次记录的文字之间不再有高低之分。等到我闲暇的时候,我就把某些描述同一个人生道理的"感悟"汇集到一起。例如,我发现我有3篇感悟都是在反思自己容易情绪化的毛病,还有5篇是从网上收集来的关于情绪管理的文章片段,那么我就把这8篇内容汇集到一个"信念"之中,然后给它起名叫"控制情绪"。

第一次虚拟迭代:"打孔"

并且,一个信念的权重也不再取决于他所包括的文件数量,而是你给它打了多少次孔。每天用户都将获得一个打孔器,选择当天对他生活起到真正帮助的那条信念,去给它打孔。日积月累,人生信念就会形成一个排行榜(如上图)。

当你看到一篇信念有50次打孔的时候,你就知道,它在生活中给了你50次的实际帮助,也许它是一个不起眼的大道理,但是你应该坚持下去;当你发现某个以前看到流泪的心灵鸡汤只有2次打孔,你就知道,原来它属于劣质的地摊成功学,它讲的都是虚的,它对你没什么帮助。

然而,当我在Word版「App」"使用"这套新设计时,我又很快发现了两个大问题。

其一是我可以作弊。我并不是每天都对生活有新感觉,但这些日子里,如果我不用打孔器它就会被浪费掉,为了不亏,我就随便找了个没用的信念给它打孔。等到我有一天突然发现一个好的观点时,我立马把那个没用信念跟它合并了起来,再把没用的部分删掉,这样它的打孔数就立刻上升了。

其二是我的内容很乱。我最感兴趣的一条信念是稻盛和夫的"做正确的事",我每天都有新感想写进去,但实际上很多并不是思想上有什么新的认识,而是我当天做了什么事。这些相当于流水账的内容掺杂到信念里,让我每天打开它不知道该看什么重点。

于是,在第二次"虚拟迭代"中,我设计了"涅盘"和"流水账"来解决上个版本的问题。

第二次虚拟迭代:"涅槃"

如上图,每个信念只能容纳9个最精华的感悟,多余的必须要"涅槃",涅槃实际上就是让你从感情上接受去删除那些不重要的思想,它约等于删除,但它的"英灵"永远存在于这个信念的一个小入口内,不允许彻底清除,供你瞻仰。

同时,用户在打孔数上作弊也没那么自在了,假设你为了把一个20次打孔的信念提高到50次,而合并进来一个打孔30次的不相关信念,那么当你去除那些不相关内容的时候,它将永远保留在涅盘区扎你的眼,让你不舒服。即使你先偷偷把那个不相关信念的内容都清除掉也没门,因为信念的合并也包括它们涅盘区的合并。

而"流水账"就能把每天的实践体会跟那些具有指导作用的文字隔离开,有什么实践体会,写流水账就行了,没必要写进信念里。但问题在于,写流水账这个功能并不在「App」的主线上,而一个完善的流程设计应该是"你一定会按照我的设计来做"而不是"某个功能你可以用也可以不用"。这个时候,我犯了一个非常愚蠢的错误,那就是额外设计了一套"分数"机制来保证用户会使用流水账这个功能——有时候,你沉浸在你的劳动中,于是忘记了你也曾是鄙视某种做法的人。

第三次虚拟迭代:"流水账"与"打孔"的结合

在接下来的"使用"中,我遇到的问题主要集中在流水账的设计上。在第三个虚拟迭代版本中,我终于找到了解决办法,那就是把"打孔"跟"流水账"结合起来(上图)。用户如果要打孔,就必须结合这个信念写下今天的流水账,讲一讲今天为什么要给这个信念打孔,发生了什么,自己做得如何,有什么感想。例如,你今天遇到一个老油条给你甩锅,但是你突然想起你写的一篇叫做"不做老好人"的信念,于是你战胜了这个老油条,那么今晚回到家,你就找到这个信念去给它打孔,打孔的时候你就写上了今天的流水账,讲述今天这个值得庆祝的事情。

这样的设计就让流水账融入了主线之中。另外,我设计了让流水账不能删除,写了就永远在那里,以保证每次的打孔必须是严谨的而不能是随意的。

在第四个虚拟迭代版本中,我还设计过一个叫"导航器"的东西,因为当我想要给一个信念打孔,或给它添加一个新的感悟时,有时候我很难立刻找到它。不过由于我一直坚信"附加功能"往往都是设计上智慧欠缺的遮羞布,所以我最终发现原来问题的症结来自于现有排序规则还不够完善,于是我就去掉了这个功能,然后完善了排序的规则。

最终,第N个虚拟迭代版本在我UI制作的一个月反复"使用",一直没有发现新的问题,于是我就提交文档给外包公司正式开发了。中间收到过30个左右的测试Build,经历了大概80次电话沟通,3次当面沟通和2000个左右的需求提交(包括Bug、细节改动,使用Worktitle平台),接着就有了现在的「App」2.0——感谢我的朋友李颖、陈智豪、刘明清,后面这些工作很多是由他们帮我完成的,我一己之力是根本无法做到的;也感谢我的外包公司的老板邓智超,「App」做到后期,很多模块的Manday都远远超出了预估,但是他没有多收我一分钱,因为他也逐渐爱上了这个产品。

虚拟迭代毕竟不是真实迭代,我总有一些地方会犯错,我会收到用户的各种反馈,正确看清这些反馈,我才能知道下一个版本迭代的重点在哪里。

《守望先锋》,源氏

《守望先锋》现在逐渐退热,很多用户都在抱怨各种问题,主要集中在英雄这个话题。有的抱怨"不能玩源氏了",有的抱怨"DVA太强了应该削弱",有的抱怨"凭什么我每天要玩奶妈",有的抱怨"说好的一个月出一个英雄呢?"……

如果暴雪一条一条去改正这些问题,它就输了,因为这些抱怨背后的原因都是一致的——那就是过分强调团队配合。一个团战基因太强的游戏(参见暴雪的《风暴英雄》),它必然导致很多人要补位,因为所谓的配合体系就是"肉、DPS、奶"的固定搭配;它必然导致每个版本都会出现一些最强势的英雄组合,于是就有人玩不了源氏;它必然导致出英雄的难度会随着英雄数量上升而呈几何指数加大,因为策划需要考虑的不是单个英雄之间的平衡,而是巨量的英雄组合之间的平衡,于是就有人抱怨出新英雄的速度太慢……

用户会向你暗示产品的问题,但很少能直接指出产品的问题。你要做的不是挨个地去满足每个用户的需求,而是去思考它们背后指向了产品的哪个根本性的症结。永远都会有人抱怨和质疑你的产品,你要做的不是去迎合,而是借助他们的智慧来更彻底地做自己。

「App」在Appstore的平均评分是4.5,它的评分是两极分化的,好评的人给的几乎都是满分,有些人写了几百字的评论;差评的人有时给的只有1分,然后配上"垃圾玩意儿不知道怎么用"这种愤怒的文字。但在我眼里,不论是给最高分还是给最低分的人,他们使用「App」的体验都是一样的,我不能因为那些好评就认为「App」只不过是门槛比较高,对于有心钻研的用户才能敞开他的大门。实际上,给最高分的人,他们所认同的是「App」优秀的那一面,从用户交流来看,他们一样会遇到那些给1分差评的用户遇到的问题,只不过他们对「App」更加宽容罢了。

有些人反映"进去不知道怎么用",有些人反映"是不是鸡汤App?",有些人反映"教程太过文艺",有些人反映"建立了一个文件夹之后,不知道怎么开始写",有些人反映"信念和感悟到底有什么区别",有些人反映"打孔器到底是干嘛的?"。经过对产品核心的审视,这些问题的产生绝大多数都来自于同一个错误,那就是我之前提到的,那个愚蠢的错误——为了把流水账功能融入主线,而额外设计了"分数"这个体系。虽然后来我改变了流水账的设计,但我并没有去掉"分数"这套体系。

由于"分数"体系绑定的是文件夹,而文件夹代表的是"人生目标",所以目前整个「App」的主线上,都会过于强调"人生目标"这个概念。由于"人生目标"卡在「App」和用户内容之间,我就无法避开它来直接呈现「App」的核心思想,我还得另外去写一些教程来引导用户,完整的用户流程中间出现了一个多余的环节,于是就产生了上述用户所抱怨的一切。

每个the App用户所追求的,都是成为更好的自己

实际上,大多数用户,包括我本人,只是偶然看到了书上一句点亮人生的话,只是偶然走在湖边,突然想通了从今以后要怎样面对这个世界。然后,我们不约而同地打开了「App」,只是想把这句话写进去,再在闲暇时把他归类到某个人生信念里,以便让双眼能更加清晰地看到前方的路。在这个过程中,我们并不关心人生目标是什么,因为所有「the App」用户的人生目标都是一致的,那就是去做更好的自己。

但如果不是虚拟迭代,我也许要在第5版、第10版才能发现这个问题,而不是在第3版就能解决它。在「App」接下来的2.1(或3.0)版本中,你将会看到一个更简洁但更有智慧的个人成长应用。

整个「the App」的开发过程,如果说有什么最重要的信念,那就是在极力减少每个版本Manday的同时,用虚拟迭代的方式让每个版本之间的跨度尽可能地扩大,因为一个产品很少在第一版就能成功,在有限的成本内,我们需要更多的、更有质量的试错空间。

在给「App」做UI之前,我的设计水平还停留在刚毕业时业余设计一些公益广告的阶段,我并不知道@3x的真正意义是什么,那么我就去查知乎、研究别人的作品,用尽各种办法把首页做出来,啃下这块硬骨头之后,后面的UI设计也就轻松多了;

ASO和H5架设我都没接触过,那么我就去万能的淘宝,看那些店家说自己是怎样做的,然后动手学过来;

当我在人员完备的互联网公司里做产品时,我曾对外包开发嗤之以鼻,觉得不天天盯着开发岂能做出一个满意的产品来?而后来,我们认识了智超,然后我们做到了。

过程很简单,那就是像「App」所要求的那样,去不断追求更好的自己。

【全篇完】

相关阅读

揭秘App外包开发秘密:一款外包App诞生的全过程(上)

让我们协助您将需求落地

*请填写需求信息,我们会在24小时内与您取得联系。