探索外包开发的极限：一个精品App诞生的全过程

副标题#e#

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

作者：黄联樵（微信：arubagod），欢迎交流。

全文目录：

一、解决一个问题就够了（产品定位/需求分析）

二、拒绝数学公式，用感性来立项（产品立项）

三、直接开始设计App的门面（概念图/交互设计）

四、用避免“反人类”的方法来设计原型（原型设计/文档撰写）

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

六、虚拟迭代（成本控制）

由于字数过多，这篇文章会分为上、下两篇来发表。你现在看到的是上篇。

前言

我耗尽心思写这篇文章，并不是想要给我的App打广告，而是总结我过去一年创业开发这个App的过程中探索到的所有关键性的经验，将它们凝聚到这27000字里，供给所有对App开发有兴趣的人了解——因此，本文所有涉及到App名称的地方，都会用「the
App」来代替。

我曾是一个海淘平台的产品负责人。一年前，我想给这个世界留下点自己的作品，于是辞职众筹开始做「the
App」。众筹的钱并不够我请一个完整的开发团队，帮我忙的几位朋友除了一名是专业测试之外，其他人并不是业内人士。于是，摆在我面前的只有一条路，那就是：代码外包，其它所有工作都由我来负责。

一年之后，「the App」上线了，它和我想象中一模一样，没有1px或1个逻辑的误差。虽然它存在一两个开发时没想到的毛病，还需要继续迭代，但是它入选了“最美应用”年度Top100，也拿到了不错的用户量，它在理念、逻辑、颜值上，都可以算是一个精品应用。

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

如果你是一名有志于开发理想中的产品的创业者，这篇文章将会告诉你很多的细节；而如果你是一名产品经理，这篇文章会从一名创业者的眼光带你重新看待产品开发这件事，这里不再有PM和程序员、设计师之间的矛盾，只有纯粹地追求做一个好产品，并为之付出自己的一切。

一、产品定位/需求分析：解决一个问题就够了

一个产品能解决好一个问题就够了，也许你会说，成功的产品需要“生态”和“盈利模式”。我只能说，除非你产品的核心功能本来就是去实现某种交易（例如p2p金融），或是致力于开发某种消费的冲动（例如“免费”手游），否则，生态和盈利模式都是建立在“最重要的那个问题已解决”的基础上的。

高屋建瓴一上来就要搞什么生态的App往往是认准了一个风口，恨不得把所有功能都加上去，BP上能画100个分析图，然而基本功能却做不到位，于是大多都被市场淘汰了。一个App的99%的营收也许都来自于它的附加功能，然而如果我们不把99%的力气花在那不起眼的、只占营收1%的核心功能上，这件事就会很尴尬。

微信的核心

以微信为例，不论微信迭代多少个版本，它始终是一开始那个“取代手机发短信功能”的App（也许你已经忘了，以前人与人之间是用短信来沟通的）。第一栏和第二栏永远是消息列表和通讯录，就算朋友圈是中国最大的社交圈子，游戏栏目是中国最大的手游流量入口，它们都不可能突然跳出来影响你的日常使用。“人”永远是通讯的主体，即使后来出现了公众号和应用号，它们也永远是被收纳在一个次级入口之中。

而当你打开一个具体的对话，它的核心永远是文字之间的交流，因为这才是“取代手机短信”的体现。哪怕是后来推出了划时代的“语音”，发送语音的按钮也永远是在发送文字的旁边，而语音的气泡也永远不会出现很多人要求的“暂停”或“后退”（除非未来微信推出插件式功能），因为聊天气泡的主体永远是文字气泡，其它所有类型的气泡，不管是现在的图片、链接、视频，还是未来的VR对话甚至是脑电波交流，它们在交互上都永远不能凌驾于“文字气泡”之上——除非文字已经不再是人类的第一远程交流方式。哪天我们能像三体星人那样用光的波长和频率来交流了，微信的这个最核心结构才会改变，否则它就是走向庸俗，然后走向堕落。

「the App」希望解决的唯一问题是：“这个世界上大多数人有动力去改变自己，然而他们没有一套行之有效的方法来坚持正确的人生信念”。这个问题可以拆分成以下3种现象，每个现象都对「the App」提出了1个必须做到的要求。

1、我们一面收集人生观，一面又在遗忘

当你看到一本好书，你会把那些醍醐灌顶的句子摘抄下来，贴在书桌前，现在那张纸肯定早就不见了；当你在朋友圈看到一篇好文章，你会立刻收藏下来，但你从来不会回头去看；有时你突然顿悟，觉得从今天起就能重获新生，但你一个月之后就变回老样子了……

——这要求「the App」必须是一个能快速记录，又能妥善保存的笔记工具。

2、我们总在一个人生问题上重复纠结，无法做到不断升华

例如，你的缺点是习惯向别人妥协，不能维持自己的底线。从小到大，你受到过很多次大的伤害，每次你都痛彻心扉，决定从明天起不再做个老好人。然而这么多年过去了，你对如何“不做老好人”并没有什么更深入的经验，因为每次你的实践周期都只有几天，然后就把它忘得影都没了，重新变成那个老好人，直到下一次重大挫折的到来。

——这要求「the App」必须是一个有效的知识整理软件，能把不同时期记录下来的，所有关于同一个人生道理的文字都汇集起来，并且给到你一种取其精华的整理方式，让你对这个道理的认识能不断升华。

3、由于人的劣根性，我们总在不同的人生观之间摇摆

人的本性是趋利避害，在一个浮躁的社会染缸里，我们很难顶住诱惑，去坚持一个不变的人生哲学。

#p#副标题#e#

去年你拜访了一个高僧，他告诉你要以德报怨，你激动得差点要去做居士；半年前你换了公司，你上司整天给你穿小鞋，你决定要做一个“厚黑”的人来保护自己；三个月前你看了一篇心灵鸡汤，讲了一个穷孩子兜揣10元钱最终成为澳门赌王的励志故事，你决定不再计较当下困扰，无条件提升自己的实力和境界；这一周你又煲完了《纸牌屋》，于是决定要做男主角那样能玩转办公室政治的人。你的人生观一直在摇摆，然而却鲜有成果，因为你很少在一个不动摇的人生方向上付出持续的努力。

——这要求「the App」必须拥有一套价值衡量体系，能精准地衡量不同人生观之间的优劣，帮用户淘汰掉那些劣质的心灵鸡汤和错误价值观，找到那个（或若干个）对自己最重要的人生方向，每天提醒自己来坚持。

我会用众筹资金的90%来解决这个唯一的问题。思索这个问题贯穿着「the App」开发的头和尾，也将延续到未来每个版本。每当我认为产品设计已经能完美解决问题时，过不了多久，我总会发现，我给产品增加了不少额外的功能，企图用它们来满足主要功能在智慧上的欠缺。

但最有效的问题解决方案永远是一条单一的路径，如果这条路上还有一些小岔路，只证明我还没有找到最优的办法。就像相对论把万有引力统一了进来，M理论貌似也能把几种弦理论、相对论和量子力学统一进来，科学家一直在寻找用最简单的一个理论来概括宇宙所有的原理。从上帝或文明高度发展的外星人来看，也许我们的这种追求很渺小，还有太长的路要走，但这个过程本身就是一种嘉奖。

#p#副标题#e#

二、产品立项：拒绝数学公式，用感性来立项

App要解决的问题已经摆在这里，接下来就是给产品设计一个大概的框架。按照套路，我应该先把产品需要的功能全都列出来，然后再把它们转化成干巴巴的、没有任何艺术感染力的原型设计图，这样做的问题在于，直到产品的UI设计图出炉之前，我没法用眼睛去真实地看到产品是个什么样子，我没法对它产生一个主观的感受。

人都是感觉的动物，一个人依赖一个产品，往往是因为他爱这个产品，而不是因为他需要这个产品（除非你做的是刚需产品，而且没有竞争对手，例如12306；或者你垄断了市场，例如淘宝），那么这些干巴巴的设计方案又怎能帮助我把握好产品的感觉呢？

我曾经去某个大公司的UGC新平台应聘产品经理，我提前去他们平台看了看，网站设计得很糟糕，让人没有阅读的欲望；明明是一个重度依赖用户原创内容的社区，然而各种困难的交互与产品中渗透出的强调权威的价值观让人没有创作的动力。于是，在重新规划框架之余，我详细地指出了每个页面的问题，把理想中的页面做成了效果图，希望让他们明白，我们要营造什么样的感觉才能让用户爱上它。

然而，当我跟他们的产品总监交谈时，他对这些视觉化的方案完全没有“感觉”，只是在一味地向我追问“用户画像”、“运营策略”这些比郁金香泡沫还要虚的东西，这场经历让我更加确信：一个不爱用户，不极力给产品营造“感觉”，试图用数学公式来推导产品设计的PM是永远没法做出有魅力的产品的。

每个人心中都有一片“信念”的森林

上图是我最开始设想的，也是最有魅力的场景概念。在这个概念下，产品设计极其简单，每个人的内心都是一片草原，当你进入我的App，我就给你呈现你内心的草原。你在生活中收集每一段感受，都是在这个草原上种一棵小树苗。每天你都能领到一些水，你用这些水去灌溉那些你认为最好的树苗。随着你度过的每一天，有些树木因为长期得不到水源而枯死了（草原的降雨量通常不足以支撑树木的成长，这是有科学依据的哼），那么这些枯树就会被送到树木坟场，提醒你再也不要相信这些虚伪的心灵鸡汤。而在你的草原上，总会有某些树苗长得比其它的都快，它们变成了苍天大树，提醒你在它的指引下面对每天的生活。

Unity市场的3D资源千差万别

#p#副标题#e##p#分页标题#e#

感性过后，就要回到专业的角度去衡量它的可行性。这个方案一共有两种执行办法：3D和2D。经过跟以前做游戏的同事探讨，3D最可行的方式是Unity

3D，然而当我花了一两周时间了解Unity之后，我发现，直接在Unity市场买来的模型并不能拼凑出一个和谐的场景，因为不同模型的贴图风格、面数、骨骼、动作都有很大的差异（如上图），我需要一个既有很强的原画功底以便能修改贴图，又会改模型和调动作的资深3D设计师才能把所有买来的素材统一化。而在程序方面，找到一个精通Unity且熟悉手机适配的C#工程师，其耗费的钱财和难度都远远高于去找一个制作原生iOS
App的资深工程师。所以这个方案已经远远超出了预算。

用分层动画来实现透视效果

而如果采用2D的方案，草原作为主场景实现起来并不困难，如上图，场景从近到远分成若干个图层，最近的前景（小草、杂石等）尺寸最长，而最远的天空背景尺寸最短。在iOS前端，我们只需要定义一条规则：滑到最左边时，所有的图层都靠在屏幕最左边；滑到最右边时，所有的图层都靠在最右边。那么自然地，当用户滑动屏幕时，他会发现前景滑动得很快，而背景滑动得很慢，不同的图层都有不同的速度，于是就形成了透视的感觉。

场景是很好解决，那么物件是不是也很简单呢？我们的最主要物件是“树”，也就是用户撰写的某个人生道理。为了确定“树”要怎么做，首先我得确定这个“树”包括哪些元素、操作以及它们以何种组织方式来呈现。

“树”应该是某种人生道理的集合

首先，如上图，我的App不可能设计成用户写的每一篇文字都算作一棵树。因为这个App的其中一个核心特点就是避免像日记或笔记应用那样：你收集了大量的文字，却发现很多文字讲的是同一个人生道理。我们必须把相同的人生道理归纳在一起，让它们组成同一棵树。例如，如果你收集了8篇文章，讲的都是关于“怎样利用好自己的内向性格”这个话题，显然它们应该放进同一个树里，而不是每次阅读他们都要去找到8颗不同的树。

#p#副标题#e#

在一颗树上，我不可能把这8篇文章设计成8个叶子。因为叶子要放在树枝上，8个叶子倒容易呈现，如果别人写100篇文章呢？我难道显示100个叶子和相对应的100根树枝？就算可以这样做，那么这100根树枝的组合必须符合树的生长规律，否则看起来就变成了反人类，这算法的编写和UI的重构又要耗费多少Manday呢？其次，树的高度取决于你给它浇过多少次水，而不取决于它有多少个树叶，那么显然，一个很矮的小树苗上长着100根树枝的情况是无法让我接受的。所以，我只能把具体的文章入口呈现为浮窗的列表里，点击某棵树之前，你顶多知道这棵树包括多少篇内容，但具体内容列表需要你点击之后弹出浮窗才能看到。

2D所需的美术资源是超限的

上面关于“树叶”、“树枝”的思考其实是不需要的，因为它们都被一票否决了，只要你看看上图就明白了。一棵树会随着浇水次数的增加而不断长大，如果是3D模型，我们可以把树分解成几个组成部分，然后给树木定义成几个阶段，每个阶段都设计一套随机算法来组合成符合这个年龄段特征的树木，在一个阶段内让树的零件数量与模型大小、贴图在两个端点之间平滑渐变就行了。然而这里是2D的树，不论是树干、树枝还是树叶，你都无法直接拉伸它们，因为这样带来的视觉效果会违背自然。那么我只能给树木做大量的实体图片，也许是10个、100个、1000个，这显然是非常愚蠢的方案，它导致的木桶效应意味着2D方案的破产。

那么我为什么还要提到关于“树枝”和“树叶”的思考呢？因为对这个细节的思考最终改变了「the App」的核心设计。「the
App」最终版本确定下来的原型设计，是从一次又一次失败的设计里提取出来的亮点组合而成的，而不是走流程走出来的。我想向你表达的是，如果你是一名PM，你的上司和团队要求你先设计原型，请你明白，他们并不一定是正确的。

你应该尽量避免那么早进入原型设计的阶段，原型设计牵扯太多全局性的东西，很多时候一个漏洞就意味着整个原型设计的报废。除非你并不在意这个App是否完美，否则，在进入正式设计前，请你多开脑洞，多去思考一些关键性的细节，并且跟开发、设计团队去讨论它们的可行性以及实现的代价，这样，你和你的团队都可以少走很多弯路。

你更愿意下载哪个App？

上面提到的3D和2D方案，它们的出发点都相同，那就是一个具有感染力的情景是最能打动用户的。例如左图这款风靡Appstore很久的时间管理软件Forest，右图是我把它迁移到一个普通界面后的效果，左右两个App功能完全相同，但如果它是右图这样的界面，你还有冲动去购买它吗？把产品的主线功能巧妙地融入一个情景之中，用App来打造这个情景，用这个情景的感染力来给用户洗脑，我至今仍然认为这将是成功速度最快的方案。

那既然没有成本去做这件事，除了“情境化”之外，我手上的选项就只剩一个“专业化”了。我决定把「the
App」打造成一个逻辑清晰、功能齐全、所有操作完美契合的专业化工具。产品的Point不再是“用情景给用户洗脑”，而是用专业化的工具设计来强调自己是这个细分市场上的不二选择，也就是强调细分的竞争力。虽然身边的人总提到我的竞争对手是日记类App、记事类App和个人管理App，但如果我在“自我成长”这个细分领域做到足够的专业性，那么我也就不存在什么竞争对手了。

专业性意味着一切，如果支付宝手机版能做好自己在“手机支付”这一块的专业性，那么当微信去做红包的时候，它就不会没有主见地采取跟随战略，而是早就忙着布局移动支付了。这导致的结局是，我身边便利店的手机支付大多都是微信这个支付领域的门外汉来普及的。

当一个产品永远只关注怎样把自己的核心诉求做得更棒的时候，它就能保持自己的竞争力；而当一个产品不看自己，总在看各种竞争对手和假想敌的时候，它就会心态爆炸，做事没有主次，以至于迷失自我。

拥有酷炫交互的Paper 51

既然定好了要做专业化的工具，那么我就去找参照。从我下载的众多App中，我发现了Paper
51，这是个了不起的参照样本，因为它不光能像便签、日记那样快速写东西，而且用户写的每条内容都是一片纸，这些纸张能自由拖拽，堆叠在一起，形成一个个纸堆——没有比这更直观的文字整理方式了（很遗憾，上图并没有展示纸张堆叠起来的效果，因为在截图时我发现，新版Paper51已经放弃了这个设计）。

而从视觉上来讲，Paper 51作为一个工具化的App有着了不起的交互效果，而这些效果竟然都是简单的2D切图构成的，这从成本上非常符合「the App」的开发思路——只要我能把2D切图、适配方案和交互设计做到完美，那么只靠一名原生iOS工程师就能把「the App」做出和Paper 51一样绚丽的视觉效果。

现在唯一不确定的是“纸张拖拽”的开发代价，我询问过我的外包合作者智超，智超也不确定纸张拖拽到底好不好做、会出现多少Bug。对待这个问题，其实解决方案很简单，那就是划清界限，让拖拽功能变成一个附加的功能，它的存在或去除并不影响这个App的其它模块。一方面，我们先做出一个没有拖拽功能的App，先上线再说；而另一方面，什么时候我们有闲余资金去开发拖拽功能了，它能作为一个单独的模块加到App里面，并不影响原有的布局。之所以这样考虑，是因为“拖拽”本身就是一个快捷操作，快捷操作的本质在于它是一个“捷径”，它只是“主要路径”的脚本化，它们都可以用“执行已有功能1+执行已有用能2……”这种句式来表达。

确定了「the App」的主要视觉元素是“纸”和“纸堆”之后，那么接下来就是思考怎样用这几个素材来解决上个章节提到的那3个要求，这样我就能给产品立项，以便开始具体的工作了。

第1个要求：「the App」必须是一个能快速记录和妥善保存的笔记工具

从目前iPhone的特性来看，在我不联通Siri也不跟其它App互通接口的情况下，快速记录最少的步骤包括：

1. 单击打开App。

2. 输入文字或粘贴文字。

3. 单击保存。

#p#副标题#e##p#分页标题#e#

但如果打开App默认就能直接输入文字，那么就意味着App启动的默认画面是输入界面，这样当用户不是想输入文字，而是想查看内容时，就要多一个退出的操作，这显然是反人类的设计。而如果换种思路，在首页常备一个输入框体，那么，假设这个输入框体在启动时默认就处于激活状态，那么键盘也会默认存在，不想写东西的用户照样多了一个退出的步骤；假设这个输入框体的默认状态是不激活，那么当用户要写东西时，一样需要一次点击操作才能激活这个输入框，从操作上来讲并没有节省一个步骤。

快速记录的最简步骤

#p#副标题#e#

综上所述，必须在步骤1和2之间加上一个“点击撰写新文字”的步骤，这样App才能获得最好的交互体验。最终得到的结论是，首页必须常驻一个空白的纸，点击或拖拽这张纸，就能立马写东西，然后单击保存就能回到主界面（如上图步骤）。

人生道理的整理过程

第2个要求：「the App」能把关于同一个人生道理的记录整合到一起，然后让用户取其精华

这就要求「the
App」在用户不那么忙的时候，能呈现用户记录的所有临时的纸张，用户从里面挑选那些相同的人生道理，把它们合并起来。这个过程是多次且可逆的，当用户觉得某篇文字实际上并不属于某个人生道理，他可以随时把这张纸从纸堆里抽出来；当用户某一天又收集了一篇新的人生感悟，他随时能把这张纸加入一个已存在的纸堆里。就像上图所示的那样。

不断提炼和升华自己的人生观

当用户形成了一个纸堆之后，他能随时去横向比较其中不同纸张的优劣，把那些过时或不够好的观点淘汰掉，精简这个纸堆。例如，小明最近发现自己最大的问题在于“担心没发生的事情”，他经常写一些关于这方面的感想，也经常收集一些知乎、壹心理、朋友圈、书籍上的有用文章，并且把它们都整理到了同一个纸堆里。随着他在生活中用实践来克服这个问题，他对这个问题的理解就越来越深刻，那么他就可以定期回到这个纸堆，淘汰掉那些不够深刻的文字，只保留对自己最有帮助的文字。同时，这个过程中也伴随着会发现一些超越这个话题的存在，那么小明这时就可以去为它开辟一个新的人生道理。就像上图所示的那样。

形成人生观的“排行榜”

第3个要求：「the App」必须设计一套严谨而方便的流程

只要每天坚持使用，那么用户就能自然而然地完成对他记录的每一条人生信念的“定价”。对于那些让自己在生活中摔跟头的劣质心灵鸡汤或是错误人生观，「the

App」会协助用户给它一个越来越低的“定价”，提醒用户把这个人生观“拉黑”，在未来整个人生中都不要去重蹈覆辙；而对于那些不易坚持却对人生最有长期效果的正品价值观，「the

App」会协助用户给它越来越高的“定价”，直至形成每个人的“核心人生观排行榜”，坚守那些少数的，实践证明最有效的人生观，就能保证心灵的高速成长（如上图）。

这第3个要求是最难实现的，它并没有在立项之初就找到最好的设计，在后面的“虚拟迭代”章节，你将看到它详细的诞生过程。

#p#副标题#e#

三、概念图/交互设计：直接开始设计App的门面

确定好产品大致框架之后，我依然没有开始做原型，而是直接着手设计App的首页——既然我选择了Paper 51做视觉参照，我就必须先眼见为实，确定这样真的能做出一个视觉效果达到并超过Paper 51的App。首页的视觉也会反过来影响到原型的设计，在线框图里看上去很有条理的首页原型，做成最终的效果并不一定能达到我要求的美感，这就会导致我设计的某些流程将连锁地报废，所以最保险的方案就是先把首页的视觉确定到9成。

首先是美术风格的确立。由于已经放弃了3D，或是用2D分层动画来实现伪3D，那我只剩3个选项：扁平、矢量风格和拟物。首先排除扁平风格，因为我们的设计元素都要围绕着“纸”，而扁平化最不擅长表现的就是实体感。Paper
51用的是简洁的矢量风格，但它有我们所不具备的拖拽交互方式，这种交互方式给人带来很强烈的物理感，弥补了矢量风格的不足。所以，为了超越Paper
51的视觉，我唯有选择拟物。

我第一眼就爱上的背景图

确定了拟物风格之后，我就开始找背景图，我花了十多个小时去图库里找素材，但当我看到负责测试的颖爷手上的锤子手机壁纸时（上图左），我立马就认为非它莫属了。老罗是个尊重艺术家的人，锤子系统的每一张壁纸都标注了作者，于是我顺利地在Depositphotos搜到了这张原图（「the
App」所有设计素材都是正版购买的）。原图是大白天的光环境，而「the
App」的风格应该是安静和隐私的，我希望给用户营造一种无人打扰的地下车库的感觉，在这里，他可以向这面墙壁倾诉任何内心深处的事，所以我把这张图处理成了黑夜的光环境（上图右）。

首页摆放的肯定是入口级的东西，那么显然就要先设计“纸堆”。Paper
51的纸堆是用算法自动地把它所包含的纸张堆叠起来，比如说，如果这个纸堆含有3张纸，那么就显示3张纸堆叠而成的样子。但是在制作效果图的时候我发现，「the

App」的纸张是拟物的，如果只有一个“纸”的素材，仅靠随机角度来堆叠，就会失去真实感，必须设计几张不同的纸来随机显示；另外，纸张的阴影并不能像矢量图那样直接运算生成，必须手绘才显得真实，而手绘阴影带来的问题就是，这个阴影的投射将不受控制：纸张A在纸张B的上面，它的阴影只应该投射在纸张B上，不应该投射在墙壁和纸张C上，这就要求纸张A在投影时必须以纸张B的轮廓作为遮罩区，因此实现起来会耗费大量Manday。

设计“纸堆”，初步形成首页

#p#副标题#e#

所以，最终我“偷懒”地给“纸堆”直接设计了一个整体的切图（上图左），而由于背景墙的顶部有个吊灯，所以这些纸堆只能放在屏幕中间，列表的滑动方式也只能是横向滑动，加上肯定要放在底部才能用起来顺手的“新增”按钮，首页的布局基本就确定下来了（上图右）。

实现真实的光照效果

最让我兴奋的是我发现了如何让整个首页突破静态PNG切图拟物的局限，达到真实光照效果的办法。我用通道+笔刷做了一个半透明的阴影覆盖层（上图中间），放在场景图层的最顶部。这样，滑动到屏幕两端的纸堆就会逐渐被阴影所吞噬，而中间不受阴影层所影响的部分，在对比之下看起来就像是被吊灯照亮了（上图右）。

用“开关灯”进一步强化光影

最后，我想着，既然强调了光影的变化，不如再做极致一些吧。于是我花了一两天的时间，给首页设计了开/关灯的交互效果。「the
App」在未来很多用户的手上是个很隐私的东西，没人愿意在「the
App」里写上“我很懦弱，从今天开始我要采用××办法改变这个现状”然后被其他人随意翻阅。所以，关灯的状态刚好可以做成锁定界面，如果用户设置了密码，那么这个界面就会显示密码盘，解锁之后才能开灯。

开/关灯对适配来讲是一个比较繁琐的过程，我的办法是，首先在PS设计稿里把所有图层重新整理一遍，变成最精简的结构。然后从这个图层结构中去思考：我们在App需要把图层分成几个大组，才能最方便地实现开关灯的效果，而且能有最高的扩展性，随时能加进去新的按钮或内容。

提炼出首页的4个UI大组

于是，如上图，我整理出了从下到上的：背景、内容、压盖、悬浮，这四个大组。开关灯能通过这些大组的UI响应来实现，后续要加进去什么内容或按钮，也能根据它的特点来加到“内容”或“悬浮”这两个组里，因为从情境上来说，所有真实拟物的按钮或入口，都应该加在“内容”这个组里，这个组在“光影”组的下层，所以会受到光影的影响，看起来就能跟整个场景融为一体；而所有附加功能的按钮或入口，都应该放在“悬浮”这个组里，这个组的内容会漂浮在整个空间之上，不受光影的影响，以强调它们是超越这个空间的，独立的存在。

#p#分页标题#e#

最后，用表格的方式来标注它们的排列顺序，以及显示/隐藏的细则（实际上，从开发来讲，这就是规范了每个UI组对于开/关灯“广播”所响应的“态”），然后再标准化所有切图文件的命名，这样，在整理首页交互思路之余，开关灯效果的文档也就顺便做好了。

#p#副标题#e#

四、原型设计/文档撰写：用避免“反人类”的方法来设计原型

我之所以强调设计原型的方法不要“反人类”，是因为我见过很多人设计原型的方法的确是反人类的（至少在我看来觉得很心痛，也许他们有自己的思维方式这也说不准），这里的“反人类”包括两方面，一个是违背你自己设计原型的最佳思考方式，另一个则是违背程序员开发的工作方式。

Axure是我见过的最反人类且最普遍的原型设计方式，之所以说是“设计方式”而非“工具”，是因为它有它作为一个工具的合理性（例如，用它来说服投资方、不懂产品的上司，设计交互，在原型完成之后做定稿，或进行虚拟迭代），但如果用它来从零设计原型，我觉得这种行为就像是用十字螺丝刀来拧一个内五角螺丝——心累。首先我讲讲Axure原型从程序员开发的角度来看为何反人类：

Axure原型跟直接截图没区别

#p#副标题#e#

假设这张瀑布流效果页是产品经理（或交互设计师）用Axure做给前端工程师的。它很美，没错，然而这跟你直接去其它网站截个图给程序员，然后说“照这样做”没什么太大区别，实际上这张图本来就是瀑布流鼻祖Pinterest的截图。

（1/2）用Visio定义瀑布流的“零件”

用Visio做就不同了，见上图，首先来定义瀑布流的单个“零件”。实际上还有一些图中没有说清楚的细节，例如文字位如果超过5行要怎样设计“展开”方式，以及整个“零件”的热区构成……这里只是大致的示例。

（2/2）用Visio定义瀑布流的布局

接着用第二张图来定义布局（上图）。同样这只是个示意，很多细节没办法写出来，且只局限于前端，但意思已经表达清楚了。当你拿着这两张图，配上UI设计师做出来的UI说明图、切图，前端（或重构）工程师就能很轻松地一次性交给你想象中的页面，也无需你那么辛苦地跟进工作。原型设计最有效的方式并不是去“直接呈现你想要的东西”，而是“用模块来重组产品，用最抽象的方式来概括全部的细节”。

#p#副标题#e#

而对于设计原型的人而言，Axure同样是反人类的，因为它违背了正常人类的思维过程。为什么很多人私底下讲话妙语连珠，大会上却变成口吃？因为私底下这些人讲话是“发散”的，想到什么就说什么，信手拈来；但是在大会上，他们不敢这样随意讲话，把嘴边的灵感都咽了下去，硬生生地用一些高大上的“首先呢”、“其次呢”、“第一点”、“既要……又要”这种句型来套路自己，把自己套路成了哑巴，这种扼杀灵感的思维方式就是“归纳”的。

Axure的使用方法就是“归纳”的，当你用它设计原型时，你就很容易变成思维上的“口吃”。它一上来就要求你做一个页面，紧接着做下一个，紧接着就要确定这两个页面之间的关联。但事实上，页面、模块和链接的成型是一个反复试错的过程，在Axure里，你一旦做出几十个页面，再想变动其中的大模块就太难了，约等于重做。它让你丧失了不断推翻自己原型设计的勇气，变得害怕灵感。

而用Visio设计原型则能做到“发散”和“归纳”自由切换，用它做原型时，我能像个精神分裂患者一样，一会切换成磕了药的艺术家状态，在画布上随意涂鸦我的灵感；一会又能切换成有点精神洁癖的理科男状态，给刚才那个人收拾战场，把那些乱七八糟的灵感整理成规整的文书——做原型最好的方式就是精神分裂。

自由绘制灵感草图

见上图，实际上，初期阶段的原型比上图的要复杂很多倍，到处都是密密麻麻的灵感和连线。这里为了你看得清上面的字，我就把它简化了一下。每当我想到一个新点子，我只需要画一个方块，然后在方块里写上几句话用来备忘；当我想细化它时，我就把这个方块做成一个稍微详细一点的页面，然后用箭头把它连接到某个地方。

我无需站在多么宏观的角度去思考要怎么设计页面，我只是盯着这个画布，一遍又一遍地假设我是用户，顺着箭头走，看看到了哪一步会遇到什么问题，被什么东西卡住，或是需要什么新的功能。做Visio原型是我在整个「the
App」开发中最享受的一个环节，我会听着FreeTEMPO喝着咖啡来做这件事，可惜它占整个开发的时间并不长，只怪它效率太高了。

轻松调整流程

如果你用的是Axure，当你流程设计有问题时，你需要把所有关于这一步的入口、出口都修改掉，随着原型详细度不断增加，可能每一次修改都会耗费你几十分钟甚至一天的劳动。然而在Visio设计图中，一切都是二维展开的，你需要修改的功能，有什么箭头指向它，以及它的箭头指向哪些模块，一切都一目了然，只需拖动几下鼠标就能调整整个流程，一次大改动一般只耗费几分钟的时间。

做原型最紧要的就是得比它高一个维度，四维空间（空间4维，不是3维空间+1维时间）的人看人类，五脏六腑都是展开的，所以看你一眼就知道你昨晚吃了什么。目前人类的App都是二维的，做在Axure里，你也只能困在那个二维空间里去探索，但做在Visio里，你就能一眼看到它的全局，因为在某个维度中去看低一个维度的东西，它就是展开的。

初具规模的App原型

一眨眼，整个原型变成了上图的样子（上图只是案发现场还原，因为当时的原型已经直接被继续细化了），一个有大概流程的原型稿。你可以注意到，原型已经被若干个灰色的“容器”分割成了几块，这样做的原因在于，当你开始细化某个模块时，它的内容就会越来越多，内部的箭头和连接线也越来越多，如果不用容器装起来，那么内部、外部的连接就会混杂起来，让你难以专注。

在专心设计某个容器内部的功能时，我通常会把整个容器拖开老远，跟其它部分完全隔离开，以便我能不被其它模块分心。在这个阶段，由于画布已经被撑得很大，所以我强烈建议你买一个带有横向滚轮的鼠标，Visio没有类似于PS的手型工具以便用来自由拖拽画布（只能点击鼠标中间来拖拽，但操作体验不流畅），横向滚轮+纵向滚轮可以描述任意一个二维空间向量，让你在越来越大的原型画布上自由冲浪。

用模块来拆分原型

当原型设计到这一步的时候，整个格局已经大致确定下来，不再需要每天给它做大手术了。此时如果我继续在一整张画布上作图，就会比较难受（卡顿，加上频繁的缩放和跳转），那么这时候就可以把原型根据模块来分成若干个页面。如上图，首页的原型被我单独分成一个页面，用5个橙色的方块来代表箭头对应的模块，写上“详见××模块”。

具体模块之：阅读模块

见上图，这是原型的其中一个具体模块——“阅读”模块，你看到的这个示例是「the App」早期的一个原型，当时的设计跟现在的有所不同，但它挺适合用来体现模块化思维。

（1/2）从后端而言，两种阅读内容是不平等的

如上图，从后端来讲，“感悟”包括“未淬火”和“已淬火”两类，而“信念”则应该定义为：个数∈[1，限定额]的若干个“已淬火感悟”的“组”——它们并不是平等的。但前端设计上它们有很多类似的地方。

（2/2）从前端来看，两者有很多共同点

#p#副标题#e##p#分页标题#e#

如上图，左边是“感悟”的阅读页，右边是“信念”的阅读页，它们阅读区域、删除、移动功能都是相近的，只不过是有一些细节的区别。

合并同类项

模块化的设计思维也好，面向对象的开发思维也好，其实都是合并同类项。

在用Visio做原型时，当我发现这两个页面有很多类似的地方，我就用鼠标把它们拖到一起，然后试着合并同类项。如上图，我把这两个页面的阅读模块摆到左右两边，把其中雷同的模块隐掉，放到中间的黑色容器来统一描述，就像一个夹心饼干。前端工程师拿到这页文档，只要开发中间黑色的馅儿就行了。

用一个流程图来表达两个功能

而至于“删除”功能就更简单了，画上一个流程图，它就是一个直接能翻译成代码的状态机。不管删除的是感悟还是信念，实际上只是一开始走的支路不同，而且这些支路仅限于前端展示，当状态机走到后端层面时，其实处理的逻辑都是完全一样的。

#p#副标题#e#

上面列举的这两件事，是把“信念”和“感悟”在原型层面能看到的一些相同之处归纳起来，让它们共享一些模块，但这种抽象能不能更高级一些？我发现一个现象：虽然“信念”在概念上是“感悟”的组，它们级别不同，但是在整个原型中它们很多的处理逻辑都相同，例如：移动、列表展示、打孔……这是因为在视觉设计上，它们只是不同类型的“纸”，必然会有很多雷同的地方，所以，何不直接把它们划分到一个“类”？

《黎明杀机》

一个很火的恐怖游戏《黎明杀机》最近出了个很大的BUG，各大平台主播都在玩这个BUG，玩出了很多搞笑的效果。首先说下这个游戏是怎么玩的，很简单，四个玩家扮演“逃生者”，一个玩家扮演“屠夫”。逃生者被屠夫抓住挂在树上就会死，要顺利逃出去你必须跟屠夫玩躲猫猫，偷偷修好5个发电机以便开启逃生门逃走。

屠夫一共有6种，他们的能力都是固定的，分别是能在草丛里偷偷放捕兽夹来阴人的“夹子屠夫”；手里拿着电锯，电锯拉开就能高速冲到你面前的“电锯屠夫”；敲一敲铃铛就能隐身的“小叮当”；喜欢在地上画个圈圈诅咒别人的“李奶奶”；《月光光心慌慌》的男主角“杀人鬼”和拥有瞬移能力的“护士”。

而作为逃生者，他们手上可以拿一些道具，例如可以用来晃瞎屠夫几秒钟的手电筒，或是可以用来包扎伤口的急救包。

于是奇怪的事情发生了，有一天，某个国外玩家发现了一个BUG：通过鬼畜地在“屠夫”和“逃生者”两个界面之间切换和点击，“逃生者”手上竟然可以拿到“电锯屠夫”的电锯，而如果这个人被一个“夹子屠夫”杀死了，夹子屠夫竟然可以捡起这把电锯，右键拉动电锯就能像电锯屠夫一样以60km/h的速度冲刺锯翻逃生者，还能拿到电锯屠夫专有的“电锯冲刺”奖励分数。

虽然这个BUG很重大，不应该出现，但是从这里可以看到《黎明杀机》通过对“类”的精妙划分而实现的高效开发（对于一个只有20人左右的小团队，能制作出占据Steam榜首的PC游戏，高效是必须的）。从玩家角度来看，不同的屠夫的能力都是固定的，但是从这个BUG可以看出，实际上这个“能力”都是由道具所赋予的。

电锯屠夫之所以拉电锯可以冲刺，并不是因为这个屠夫比其它屠夫多了一些专有代码，而是“电锯”这个道具本身就能赋予一个屠夫“高速冲刺”的能力；电锯冲刺的分数奖励，也并不是由其它模块来负责具体的计算，而是这个道具在使用时就会自动计算分数，然后把结算出来的分数“通知”给那个统一的计分模块；而逃生者手上可以拿电锯，屠夫可以像逃生者一样从地上捡起它则说明，所有的道具，不论是逃生者的急救包还是屠夫的电锯，它们都有很多共享的属性，例如：可以被捡起来、可以装备在手上、点右键可以发挥它的功能、屏幕左下角会用图标显示这个道具的状态……

《黎明杀机》对“类”的划分

如上图，实际上，在《黎明杀机》中，所有的道具都有一个通用的模板，这个总的模板就是“父类”，在此基础上细分下去，形成各有特点的屠夫和幸存者道具的“子类”，直到最后，变成实实在在的，某个具体的可以拿在手上的“对象”，例如工具箱和电锯。

“类”：NOTE

回到「the App」原型设计，经过跟iOS开发者智超的讨论，我们决定把“感悟”和“信念”设计成同一个叫做Note的“类”（上图），有了这个类的划分，我就能进一步去整合Visio原型中除了上面提到的“阅读”和“删除”之外的模块了。

Visio原型制作完之后，我把它们转移到OneNote之中，专门建立了一个描述“Note”的分区，按照类的结构来建立不同层级的页面，然后把做好的Visio图形粘贴到各个页面里……其它的模块也都用模块化的思路整理到OneNote里，到了这一步，一个完整的App文档就差不多搞定了。

同步这个OneNote文档给程序员，给他们分配阅读权限，我们就能协同工作了。「the
App」除了设计素材都是正版购买之外，所有软件也都是正版购买的，所以协同工作对我来讲只是点一下“保存到云”。正版是一种生活方式，每个月我大概花500月费来供养我整个电脑的所有软件和服务，这是爱的供养，这让我从来不需要到处去找破解版软件，我的电脑从不会中毒，我重装电脑之后所有软件的云端设置都会自动还原，我的所有资料也一直在付费云端增量更新，我从不担心它们会丢失，每天我一打开电脑就能安心工作。

#p#副标题#e#

Onenote文档中不光得有Visio原型，还需要很多的附加文档，从性质上看，主要包括“宏”、“系统文档”和“集中说明”。它们并不是我一开始就明白要去单独做的，而是做原型的过程中，遇到了用Visio无法说清的问题，或是即使说清了，也会让Visio图形变得太过臃肿，于是就自然而然地想到要另起炉灶了。

（1/3）附加文档：宏

（1）首先说“宏”

“宏”一般用来归纳那些App中零散出现的，但是不便于统一成某个模块的东西。上图是一个用来归纳「the
App」中所有后期可能要变动的数值的Excel表格，例如，打孔器的冷却时间是多少个小时？打一次孔的加分是多少？每个信念最多能容纳的感悟数量是多少？……这些数值我无法一次确定下来，需要在试用过程中不断调整，显然，如果我今天在A文档里去改数值α，明天在B文档里去改数值β，我和智超之间至少有一个人会疯掉的。

当我写一个宏文档，智超就会在代码里写一个宏，在这个宏里他就能直接修改这些数值，并能自动应用到所有关联的代码，只需要几秒钟就搞定了。而在后期测试的时候，我显然不能像数值中要求的那样：一个感悟写下来之后，隔9小时才能淬火——我只有1分钟的耐心。那么很简单，我在表格中多加入一列“测试数值”，写上“1分钟”，到时要个测试版就行了。

（2/3）附加文档：系统文档

（2）“系统文档”

Visio原型比较善于表达前端的流程或状态机的逻辑，而如果你想要详细阐述某个系统的原理就比较难了。「the
App」中“文件夹”这个概念，在Visio中主要描述的是看得到的部分，而看不到的细节就要用Word文档来描述了（上图左），例如：文件夹是否可以重名？是否可以为空？两个栏目的文件排序规则分别是什么？这些东西在Word文档中用论文的结构可以很轻松地交代明白。

「the
App」的文件夹都有封面，这些封面包括3种，第1种是特殊文件夹的固定封面（包括不设置封面时的默认代图），第2种是用户自己拍摄或导入照片，第3种是系统自带的封面。那么这就带来一些问题，例如：固定封面是否属于系统自带封面可供选择？用户自己拍摄的照片被替换掉之后，是否继续保存？……

这些问题很难用简洁的文字来概括，所以我做了一些“伪数据结构”（例如上图右），虽然这个数据结构设计得很外行，直接采用可能会引起手机爆炸，但文档的意义在于沟通，伪数据结构的表达方式在这里能用最少的废话讲清楚我要干什么，那么它就是最好的沟通方式。同理，你甚至可以用伪代码的方式来描述一些文字不便形容的逻辑，只要程序员能轻松理解到跟你完全一样的想法，何乐而不为呢？

（3/3）附加文档：集中说明

#p#分页标题#e#

最后一种情况是“集中说明”，顾名思义，「the
App」中很多东西是零散的，不便于在主文档中出现的。例如左图归纳了App中所有出现的文本输入窗口的具体属性，包括它们的窗口名、初始文本……这样我在原型中就不必列举每个文本输入页面的具体属性；再例如右图归纳了App中所有教程的出现时机、地点、展现方式，同理，这些凌乱的东西根本不应该出现在主文档不是吗？

#p#副标题#e#

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

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

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

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

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

（1/2）文件夹页面的概念图（左）

#p#副标题#e#

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

（2/2）写作页面的概念图

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

1. 文字一定要大，行间距和段间距也要大，这样你就算只写几十个字也很有成就感，仿佛是写了一篇大作。

2. 光标不能用默认的，要用大的，闪烁起来要有呼吸感，而且最好不要被行高限制住，要往下延伸到下一行的顶部，这样能激发人的写作欲望。

3. #p#副标题#e#

   最常用的按钮不要放在顶部，而是放在键盘上面，而其中最重要的那个按钮要放在右边，这样写完了之后不用抬手，右手大拇指轻松就能点到保存（老罗调研过，手机用户中，右手为主的用户比例虽然低于生活中右手为主的人，但还是轻松超过一半）。

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

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

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

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

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

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

1. 虽然颜色看起来很缤纷，但除了不同透明度的白色之外，实际上只有黄、蓝对撞色。

2. 所有的图形，甚至包括字体，都是圆角的，圆角的半径也基本是相同的。

3. 字体看起来很多，但实际上字体和字号都只有一种，看起来多只是因为颜色或加粗带来的效果。

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

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

1、两种字体

（１）系统默认字体

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

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

用“刻宋”体作为交互类字体，提升UI档次

（２）自带字体

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

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

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

2、黑白设计

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

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

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

化繁为简的“设计规范”

#p#副标题#e##p#分页标题#e#

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

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

1、100%还原图

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

拟物元素不能相互遮挡

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

#p#副标题#e#

六、成本控制：虚拟迭代

#p#副标题#e#

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

1.0版本的“微博”设计

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

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

上线前我对这套逻辑信心满满，然而上线后才使用了两周，我就发现了其中的大问题。其一，越是转发次数越多的微博，我就对原文越不满意，因为我的思考一直在往前走；其二，当我灵感一现，想要掏出「the

App」来写东西的时候，我往往会愣住，因为我不记得我有没有写过类似的“原创”，如果有，我也很难第一时间找到它来转发。于是，我往往都是写去写一篇新的原创，这套转发机制逐渐成了摆设；其三，转发次数最多的微博，并不一定是我最应该去坚持的人生信念，有时候，它反而代表一个我走过很多弯路的错误信念。

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

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

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

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

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

#p#副标题#e#

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

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

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

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

第一次虚拟迭代：“打孔”

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

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

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

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

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

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

第二次虚拟迭代：“涅槃”

#p#分页标题#e#

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

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

而“流水账”就能把每天的实践体会跟那些具有指导作用的文字隔离开，有什么实践体会，写流水账就行了，没必要写进信念里。但问题在于，写流水账这个功能并不在「the

App」的主线上，而一个完善的流程设计应该是“你一定会按照我的设计来做”而不是“某个功能你可以用也可以不用”。这个时候，我犯了一个非常愚蠢的错误，那就是额外设计了一套“分数”机制来保证用户会使用流水账这个功能——有时候，你沉浸在你的劳动中，于是忘记了你也曾是鄙视某种做法的人。

第三次虚拟迭代：“流水账”与“打孔”的结合

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

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

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

最终，第N个虚拟迭代版本在我UI制作的一个月反复“使用”，一直没有发现新的问题，于是我就提交文档给外包公司正式开发了。中间收到过30个左右的测试Build，经历了大概80次电话沟通，3次当面沟通和2000个左右的需求提交（包括Bug、细节改动，使用Worktitle平台），接着就有了现在的「the

App」2.0——感谢我的朋友李颖、陈智豪、刘明清，后面这些工作很多是由他们帮我完成的，我一己之力是根本无法做到的；也感谢我的外包公司的老板邓智超，「the
App」做到后期，很多模块的Manday都远远超出了预估，但是他没有多收我一分钱，因为他也逐渐爱上了这个产品。

#p#副标题#e#

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

《守望先锋》，源氏

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

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

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

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

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

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

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

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

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

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

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

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

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

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