编者按：今天这篇文章总结的5个步骤，从工作流程的优化开始，帮你快速试错，减少改稿次数，非常实用，建议阅读。
几个月以来，为了打造一个令人惊叹的移动App，你的整个团队全都卯足劲儿、干劲十足的干活，这是一个累并快乐的过程。最终，当团队成员接近精力极限并筋疲力竭时，你的App惊艳出场了！可是然后呢？你梦想中的App迎来了重击噩梦：有着旺盛需求的用户下载了你的App，可是一旦使用一次，他们再也不会第二次使用了。
这意味着近几个月的牺牲和辛苦投入全都付诸流水了，这到底是为什么？
互联网浪潮之下，大约41%的App正在遭受着同样地重击命运：用户使用一次后就被抛弃，这已经成为互联网世界的一种趋势。而你的App很不幸的成为了这个趋势浪潮的一员。这不仅让我想起已经有400年历史的瓦萨战舰，这个趋势与瓦萨沉船事故有许多相同之处，要知道这艘船可是当时最震撼的战舰之一呢。据说在它的处女行中，瓦萨号在水中晃荡了一会儿，仅仅行驶了1英里就沉船了，而沉船的原因是因为它的基础设计有问题。
让我们探索更多的瓦萨沉船的教训，使你的App避免跟它一样的命运：刚离开港口就沉船。
01 打造一个清晰的，引人入胜的愿景
虽然瓦萨号最终是个失败，但毋庸置疑它仍然是一艘无与伦比的战舰，它的建造者们是那么大胆。
因此，在讨论这艘战舰的所有设计问题之前，我们可以简单地看一下它的可取之处：首先它的建造者们有着宏伟的愿景，并且利用这艘战舰描绘出了一个引人入胜的故事，这个故事是关于皇室们的征服欲以及他们的荣耀。
即便是在400年后的今天，这个愿景还是如此地引人入胜。它展示了高超的技术、色彩艳丽的神像、令人畏惧的武器装备以及这艘船的整体形象。
说起产品愿景，你的移动端产品也应该跟瓦萨号一样引人入胜。
对于你正在打造的App，在决定怎样设计以及开发之前，你必须有一个非常清晰的想法思路，包括你的App会带来的价值好处。
相比于瓦萨号的愿景，幸运的是，描绘一个移动端产品的愿景还是一件比较简单的事。你可以利用非常方便实用的便签，来打造一个愿景故事版，描绘App目标用户的主要使用场景，这些基本在20到30分钟内就能完成。
在Greg Nudelman的书《$1 prototype》中所写的一个“成为一名英雄”的故事版就是一个很好地愿景示例：
△ 来自《 $1 Prototype 》书中“成为一名英雄” 的APP故事版 (Image: Greg Nudelman)
这个故事板描述了一个主要用户场景：用户希望通过给自己选定的慈善机构捐钱，来支援风灾救援。当然它的好处也是显而易见的：捐献物资的人会感觉自己像个英雄；同时灾难的幸存者可以得到及时的援助，来帮助他们重新开始生活。
根据财富报道，大多数创业项目失败的首要原因是因为他们打造了一个根本没人想要的产品。请确保你的产品不会变成只是一个统计数据（产品失败了），你需要规划出一个愿景，让人们听到后兴奋地想要尝试。
所以在做任何的设计以及开发之前，你需要花时间以“故事版”的形式描绘产品愿景。然后把故事版展示给潜在用户人群、利益相关者，来确保是否所有关键人群的反馈都是积极的。
你的愿景必须展现出一个明确、令人信服的利益点；否则的话，你的App不值得被打造出来。一旦明确了产品愿景，你就可以开始进行设计以及原型解决方案了。
02 提早测试，同时把结果告知主管
当瓦萨号的计划书刚被呈现给瑞典国王时，他做了两个大错特错的修改。一个是在船头装配上24磅的大炮；第二个是把船建的更薄一点，使它能够行驶更快。
很多人认为，这样的细节设计指导肯定意味着国王将亲自监督整个建设过程。但事实并非如此，国王只是在甲板上参观过一次。
事实上，在瓦萨号全部装配完成并且浮在水上之前，没有人给这艘船做过任何的稳定性测试，维基百科上是这样说的：“在上层甲板上，30个男人来来回回穿梭其间，启动战舰。但是仅仅在三次试行后，负责的舰队司令停止了测试，因为他怕船会侧翻。”
在战舰处女行之前，除了失败的稳定性测试，无论做任何事情都无法拯救这艘船了。没有人希望把不好的消息带去给国王，因为国王坚持尽快让战舰开始航行。
最后，我们可以说这位国王完全得到了他所想要的东西，但并不是他所需要的东西——一艘宏伟的战舰，但却在行驶里一英里后就沉船了。
对于已经计划好的设计（就是瓦萨号），向高层人员反馈以及提出建议是完全正确的。这两件事都是这整个项目中非常重要的一部分。然而这个项目所缺少的东西是早期的概念测试以及及时的反馈机制。
正如在每一个设计和发展的阶段，你的想法、原型需要被充分地测试；把测试结果传达给正确的人也同样重要。关键的人群需要被作为解决方案的一部分，否则这些人就会变成问题一部分。
作为一名设计师，你的工作就是就是向高层人员及时提供反馈。在问题能被处理之前，尽早地向高管们清晰地表达产品存在的问题，确保产品朝着“做出最好的设计”前进。
你要如何确保尽早得到管理人反馈？这就是一个最简可用原型大显身手的地方了。
03 MVP：最小可用原型
博物馆中，在打捞出来的瓦萨沉船旁边，放置着原船比例 1：10 的模型，这样的模型对优化设计来讲是最理想的，任何人都可以看的出来这么一件事：船被改造成更薄，更高的样子并且在顶部增加了的大炮会损害其稳定性。
然而，瓦萨号沉没后，打造这个 1:10 的模型，没什么卵用，当然除了可以警示我们：建立你的的移动产品原型，尽早得到反馈，并在开始开发前优化设计。
幸运的是在今天，打造你的App原型将会相当容易———你不需要木板、甚至任何特殊的设备或软件，更棒的是，你的设计和你的原型可以是相同的。
所有你需要的只是一包3×5英寸的纯色便签贴纸：
例如，下面是 Be a hero 的 MVP ：
最终用便签纸制成的Be a Hero 德最小可用原型
有了这个简单的原型，你可以快速，方便的测试和完善你的 App 的基本设计：信息架构、交互设计、复制等，你甚至可以测试图标。
所谓精益生产，其实就是动手之前先做实验，首先在纸上创建一个迷你Q版的原型图，然后直接摆在潜在用户面前进行测试，这大大加快了实验和反馈的过程，无论是内部的还是外部的。
事实上，就是以最低成本和最适宜的方式规避风险。
当你的项目启动后，尽早的对原型进行持续性的测试，有效减少可能致命的设计缺陷，也大大增加了成功的机会。
04 早期的设计优化，制造差异
瓦萨号非常有名，但很多人不知道瓦萨号的姐妹船：苹果，它的设计者做出了两个重要的改进，他们在上甲板上安装了较轻的枪，并对船体加宽了 1 米（只是瓦萨宽度的 10% ）。
这个简单的调整改变了一切：苹果成功航行了超过30年。
为了确保你的产品的成功，尽早测试，并在一开始就进行大量的迭代，直至达到设计初衷。而一开始就将时间和精力投入到高保真的完美设计上，只会适得其反。
例如在 Be a hero 的例子中，在团队第一次在便签纸上提出原型设计后，先后经历了5次迭代。
Be a Hero 应用的5次MVP迭代
当团队完善了设计的关键要素后，他们才投入了额外的时间来创建高保真的原型：
为Be a Hero app最终完成的设计
在设计的早期过程中，保持高保真的原型、适当的项目状态，有利于团队快速推进和解决大部分问题，使团队能够在短短三周的时间确定最终方案。
不知道你会做出什么举动，但这听起来就像你花费了一包便签纸的成本就避免了一艘艘沉船，连威严的瑞典国王肯定会批准这么做的。
05 确保你的App顺利启航
通过看到瓦萨号战舰的历史，如果在遵循一些简单而深邃的精益用户体验指南，可以帮助你的移动项目避免灾难性的后果。
在你开始之前，把你的愿景做为 Storyboard 挂起来，花时间与潜在的用户和利益相关者（股东）来测试———确保他们对你的想法有着同样的热情。
一旦愿景确定（被大家所接受），使用通过便签纸生成的 MVP 同步开始用户测试与设计。从这一点上来看，快速原型迭代与客户反馈应该是你的移动设计的核心。
一路上，也别忘了与管理人员和团队中的关键人员进行双向沟通的重要性。
通过包括所有的关键人的反馈回路中，确认团队中的每一个人的想法都被考虑到了，这最大限度的减少了任何人在最后一分钟的变化，使你不能充分测试或实现。
记得原型的精确度与项目的进度相匹配，在设计的关键部分，在你觉得很舒服之前，切记不要投入太多的时间和精力在高保真原型上。so，坚持尽可能长时间地使用低保真原型，测试设计快速迭代，并不断结合见解重新回（重构）到你的原型上。
精益，快速成型，再加上一个连续的反馈循环，将有助于您的团队工作顺利，结合新的想法，构建移动 App，不仅仅是首航成功，而是要在未来成功航行多年，并在对手的心中造成惊人的恐惧。
原文| Greg Nudelman
翻译｜王子娟、林佳
校对｜唐菁