由于字数过多，这篇文章分为了上、下两篇来发表。你现在看到的是下篇。（上篇《揭秘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都有几个共性：
- 文字一定要大，行间距和段间距也要大，这样你就算只写几十个字也很有成就感，仿佛是写了一篇大作。
- 光标不能用默认的，要用大的，闪烁起来要有呼吸感，而且最好不要被行高限制住，要往下延伸到下一行的顶部，这样能激发人的写作欲望。
- 最常用的按钮不要放在顶部，而是放在键盘上面，而其中最重要的那个按钮要放在右边，这样写完了之后不用抬手，右手大拇指轻松就能点到保存（老罗调研过，手机用户中，右手为主的用户比例虽然低于生活中右手为主的人，但还是轻松超过一半）。
所以，我就截了几张UI放进设计稿里，简单拼凑了一下，照葫芦画瓢做了个左图中的UI，顺便把键盘改成跟上半部分统一的黑白色（iOS原生输入法可以定制颜色）。
我觉得这样的写作页面没有什么需要画蛇添足的地方了，再减一个元素就影响使用，再加一个元素就导致臃肿，那么现在我手上有两个页面的UI概念图都达到了我要的标准。
但问题是，它们一个是纯拟物，一个是纯扁平，这要如何是好？经过思考，虽然「App」强调的是拟物，但是我可以把"拟物层"和"操作层"做成两种对撞的风格——所有关于纸张、墙壁这些"物理环境"的设计都做成纯拟物，而所有交互的内容都做成纯扁平的，这样看起来效果最好。如果我一根筋地去把所有的交互界面都做成拟物的，反而会弱化纸张和墙壁的拟物感。所以我决定把"操作层"做成扁平的，让薄如蝉翼的"操作层"漂浮在厚重的"拟物层"之上，就会在带来沉浸感的同时，给人一种操作起来很轻便的感觉。
依照这种设计思路，扁平和拟物的风格不需要强行统一，反而是对比越强烈效果越好，这就让我面临一个问题：怎样的扁平设计是最纯粹的？
你认为哪个扁平设计更纯粹？
左图是一个很纯粹的扁平UI设计；右图相反，是一个四不像的扁平UI设计。左图之所以够纯粹，仔细观察可以发现原因：
- 虽然颜色看起来很缤纷，但除了不同透明度的白色之外，实际上只有黄、蓝对撞色。
- 所有的图形，甚至包括字体，都是圆角的，圆角的半径也基本是相同的。
- 字体看起来很多，但实际上字体和字号都只有一种，看起来多只是因为颜色或加粗带来的效果。
当时研究了很多例子，发现优秀的扁平化设计，毫无例外可以用一个观点来概括：能用一种字号解决的，不要用两种字号；能用一种颜色解决的，不要用两种颜色……所以我就带着这种思路重新整理了一下其余的概念图（这就是为什么不要那么早确定设计标准），基本形成了「App」在"扁平化"部分的设计规范：
将所有系统字精简为"大"、"小"字
1、两种字体
（１）系统默认字体
除了用户自己写的文字内容需要单独来制定字号、行距、段间距之外（因为这个内容最重要，需要区别设计），其它情况尽量用2种规格来解决（见上图），那就是"大字"和"小字"。在设计规范中，我分别定义了两种字体的字号、行距、段间距。
得到它们具体规格的手段很简单，就是去复刻那些优秀App界面中的字体，把它们应用到你设计稿中的若干个主要页面中，输出成几个重要机型的效果图，分别放到这些机子中去看实际效果，反复微调几次就基本搞定了。在这个过程中，不要像很多人那样，总是填上那些排版最好看的文字内容，而是要尽可能让文字的排版丑陋。例如，一行字多出一个字跑到第二行，连续两次空行，连续敲很多个句号……你永远无法预测到用户会输入什么文字，如果你能在文字最不适合排版的情况下，也能保证排版看得过去，那么你设置的字体才是最有适应力的。
用"刻宋"体作为交互类字体，提升UI档次
（２）自带字体
这是由于我发现，之所以很多中文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通道来确定"纸"的切图范围
纸的光环境是灯泡从右上角照过来，因此它阴影的边缘自然在左边和下边。为了拿到切图，我必须确定边缘，从效果图（左上）里直接找到边缘很困难，用通道+曲线很容易就找到了（左下）。有了左下角的边缘之后，我就能完整把它切出来。为了文本对齐方便，显然我在纸张的顶部和右边也要留相同的空隙，这样纸张切图"纸"的部分就能刚好处在切图的中心（右）。
形成"纸"的统一文档
那么接下来就是给这张通用的"纸"来写文档。见上图：
- 文本框的宽、高，以及它相对于这张纸切图的位置，我都用它们与切图尺寸的比例关系来表示。这样做之所以可以成功适配，是因为不论纸张有几种规格的切图（@3x、@2x，或以后更高规格的切图），我们要明白一个特点，那就是文本框与切图的比例关系是不应该发生改变的。
- 标题的底部距离文本框的高度，并不需要用具体数值来表示，而是可以刚好隔开一行文本的距离，那么在文档中我就定义这个距离=正文的字号。也就是说，假设正文的字号是12pt，那么它们的间隔就是12pt。这样做的好处在于，不论我怎么调整正文字体的大小，标题与正文看上去永远刚好隔着一行。
- 标题的字号不是一个具体的数值，而是正文字号的1.4倍。因为从设计上来讲，标题之所以看上去是标题，就是因为它比正文的字要更大或者更粗。1.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」所要求的那样，去不断追求更好的自己。
【全篇完】
