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

在一颗树上，我不可能把这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. 单击保存。

（编辑：ASP站长网）