瓦萨号沉船与你的很配

　　瓦萨是一艘古战船的名字，它是瑞典国王古斯塔夫二世于1625年开始建造的。这艘战船本来是单层炮舰，可是国王得知当时瑞典的海上强敌丹麦已拥有双层炮舰，便不顾当时本国的技术条件，下令把炮舰改造为双层，1628年首航几分钟便沉没，直到1961年才重见天日。
　　几个月以来，你和整个团队都在疯狂工作为的是构建出一款令人惊叹的移动 App，最终，带着疲惫与兴奋，it’s showtime！但是，你寄于厚望的梦幻 App 却带来了无止境的梦魇：急切的用户下载了 App，使用过一次之后，就再也没有回来。
　　所有的牺牲和几个月的艰辛劳作———然并卵，哪里出了问题？
　　你的 App 已经成为最新趋势(comscore调查)的一个受害者———高达 41% 的 App 被使用一次之后就被抛弃。这个趋势与 400 年前瓦萨号沉船的故事如出一辙。这个当时令人惊叹的军舰，由于存在基本的设计问题，在它的首航分钟便沉没。
　　本文将探讨瓦萨号，希望能帮助你的移动项目找到正确的点。
　　斯德哥尔摩博物馆打捞出来的瓦萨号战舰
　　一个清晰、引人注目的愿景
　　虽然瓦萨号最终失败，但有一点无疑是极好的，建造者竟有如此雄心壮志。
　　so，在讨论瓦萨号的所有问题之前，让我们简单的了解一件它做对了的事情：船的建造者有一个宏伟的愿景，并讲述了一个引人入胜的关于王室的征服与骄傲的故事。
　　即使在 400 年后的今天，他们的愿景依然是吸引人的。这是出色的工艺、会声会色的描绘神话雕像、可怕的武器以及船舶的整体外观的表达。
　　谈到愿景，你的移动项目或许并没有那么吸引人。
　　在开始设计和实现 App 之前，你必须对正在构建的的产品有一个清晰的愿景———以及 App 所能够提供的价值。
　　幸运的是，描绘移动项目愿景相当简单，你可以在短短 20-30 分钟时间里，仅仅使用几张便签纸来描述 App 的主要使用场景。
　　＂Be a hero＂ Storyboard (英文作者)
　　Storyboard用户需求场景描述：一个用户想要通过向慈善机构捐款来支持台风救援工作，捐赠物资的人感觉像一个英雄，而灾难的幸存者也得到了迫切的帮助，开始重建他们的生活。
　　据《财富》杂志显示：大多数初新创公司失败的原因之一是他们制造了一个没有人想要的产品。制造出令人兴奋的愿景，并确保你的移动项目没有成为这个数据的一部分。
　　在做任何实际的设计和开发之前，花点时间搞清楚你的愿景是什么，把它展示给潜在的用户和你的股东，以确保所有关键人员的反应是兴奋的。
　　你的愿景必须清晰、引人注目，否则，App 就不值得构建，一旦愿景确定，就可以开始规划和设计原型解决方案。
　　尽早测试、调整
　　当＂瓦萨＂号的计划由瑞典国王首次提出后，他犯了两个致命的修改：一是武装上重达 24 磅重的大炮，二是使船变的更薄，以便使其更快。
　　许多人认为，如此详细的设计指导意味着国王会亲自监督，然而事实上，国王只对码头进行了一次访问。
　　实际上，第一次稳定性测试直到漂浮设备完备后才得以进行。据维基百科记录：三十个人在上层甲板来回跑去，但只进行了三次就被海军上将给叫停，因为他担心船会翻。
　　尽管稳定性测试做的很失败，但在首航前还是太晚开始做任何事情，没有人想告诉国王坏消息，只是坚持说，这艘船很快就可以开始航行了。
　　最终，我们可以这样以为，国王得到了他 想要 的东西，但不是他所 需要 的东西———一艘引人注目的船，但只在行驶了一英里就沉没了。
　　对于任何重要的项目，执行反馈或设计的修改建议都是没有错的，也都是至关重要的，这里缺少的是对早期原型测试与及时反馈。
　　正如你的愿景与原型需要在设计和开发的每一步都要经过充分的测试，向正确的人传达测试结果同样重要，关键人（ Key people）需要成为解决方案的一部分，否则他们将成为问题的一部分。
　　作为一名设计师，你的工作是向管理人员提供及时反馈，清楚的沟通任何早期的产品问题，同时也可以得到解决，以确保最好的设计得以向前推进。
　　如何确保你早日得到反馈？MVP（Minimum Viable Prototype ） 将会非常有帮助。
　　MVP：最小可用原型
　　最近在斯德哥尔摩参会（英文作者），我得以有机会去参观瓦萨沉船博物馆。
　　博物馆中，在打捞出来的瓦萨沉船旁边，放置着原船比例 1：10 的模型，这样的模型对优化设计来讲是最理想的，任何人都可以看的出来如何使船更薄，更高，在顶部增加了的大炮会损害其稳定性。
　　然而，瓦萨号沉没后，打造这个 1:10 的模型，没什么卵用，当然除了可以警示我们：建立你的的移动产品原型，尽早得到反馈，并在开始开发前优化设计。
　　幸运的是在今天，打造你的 App 原型将会异常容易———你不需要木板、甚至任何特殊的设备或软件，更棒的是，你的设计和你的原型可以是相同的。
　　所有你需要的只是一包 3×5 英寸的纯色便签贴纸：
　　例如，下面是 Be a hero 的 MVP：
　　有了这个简单的原型，你可以快速，方便的测试和完善你的 App 的基本设计：信息架构、交互设计、复制等，你甚至可以测试图标。
　　精益生产是关于实验的，通过创建一个 MVP 来建立你的实验，并直接面向潜在用户进行测试，也大大加快了实验和反馈的过程，无论是内部的还是外部的。
　　事实上，就是以最低成本和最适宜的方式规避风险。
　　当你的项目启动后，尽早的对原型进行持续性的测试，有效减少可能致命的设计缺陷，也大大增加了成功的机会。
　　早期设计优化，制造差异
　　瓦萨号非常有名，但很多人不知道瓦萨号的姐妹船：苹果，它的设计者做出了两个重要的改进，他们在上甲板上安装了较轻的枪，并对船体加宽了 1 米（只是瓦萨宽度的 10% ）。
　　这个简单的调整改变了一切：苹果 成功航行了超过 30 年。
　　为了确保你的产品的成功，尽早测试，并在一开始就进行大量的迭代，直至达到设计初衷。而一开始就将时间和精力投入到高保真的完美设计上，只会适得其反。
　　例如在 Be a hero 的例子中，在团队第一次在便签纸上提出原型设计后，先后经历了 5 次迭代。
　　当团队完善了设计的关键要素后，他们才投入了额外的时间来创建高保真的原型：
　　在设计的早期过程中，保持高保真的原型、适当的项目状态，有利于团队快速推进和解决大部分问题，使团队能够在短短三周的时间确定最终方案。
　　不知道你会做出什么举动，但这听起来就像你花费了一包便签纸的成本就避免了一艘艘沉船，连威严的瑞典国王肯定会批准这么做的。
　　确保你的 App 顺利启航
　　通过看到瓦萨号战舰的历史，如果在遵循一些简单而深邃的精益用户体验指南，可以帮助你的移动项目避免灾难性的后果。
　　在你开始之前，把你的愿景做为 Storyboard 挂起来，花时间与潜在的用户和利益相关者（股东）来测试———确保他们对你的想法有着同样的热情。
　　一旦愿景确定（被大家所接受），使用通过便签纸生成的 MVP 同步开始用户测试与设计。从这一点上来看，快速原型迭代与客户反馈应该是你的移动设计的核心。
　　一路上，也别忘了与管理人员和团队中的关键人员进行 双向沟通 的重要性。
　　通过包括所有的关键人的反馈回路中，确认团队中的每一个人以为他们的想法是从一开始就被考虑的，这最大限度的减少了任何人在最后一分钟的变化，使你不能充分测试或实现。
　　记得原型的精确度与项目的进度相匹配，在设计的关键部分，在你觉得很舒服之前，切记不要投入太多的时间和精力在高保真原型上。so，坚持尽可能长时间的使用低保真原型，测试设计快速迭代，并不断结合见解重新回（重构）到你的原型上。
　　精益，快速成型，再加上一个连续的反馈循环，将有助于您的团队工作顺利，结合新的想法，构建移动 App，不仅仅是首航成功，而是要在未来成功航行多年，并在对手的心中造成惊人的恐惧。
　　结语
　　成功的产品各有各的不同，失败的产品却是一样的原因。
　　部分句子依据上下文意义没有直译并有所发挥，请各位小伙伴查看原汁原味的英文原文。
　　我想起了自己做的第一个，也是彻头彻尾失败的产品，不说了，都是泪，但也恰恰是它的失败，而使我有所成长，正如：所有弄不死你的东西，终将使你更加强大！