移动应用开发过程中的迭代式原型设计

主要结论

• 移动应用原型创建过程中采用迭代式快速开发方法的重要性。
• 可以从对手身上学到什么，如何从他们的失误中获益。
• 如何为你的应用定义 USP，如何通过故事板（Storyboarding）、用户场景和故事图（Story-mapping）为自己挑选出最理想的用户。
• 如何使用纸面原型匹配团队的预期，并专注于共享的最终交付成果。
• 如何使用原型工具收集、管理和验证需求，进而在无需进行太多文案工作的情况下让产品解决方案具象化。

根据 Yahoo Flurry 提供的数据，消费者使用手机的时间中有超过90% 用于各种应用。移动应用市场的增长速度和持续发展趋势使得应用设计人员必须在移动应用开发工作中实施一种更迭代的方法。移动应用的开发过程与网站的开发大不相同，生命周期变化更频繁，开发者需要在设计和用户测试阶段考虑不同的设备种类、屏幕分辨率，以及操作系统。传统的网站开发方式以创建一个最终版本网站为目标，这种方式无法适应移动应用开发的需求，因而需要更敏捷的方法。

毫无疑问，所有这些因素迫使开发者必须采用迭代式的快速开发过程。原型是这种敏捷方法中必不可少的，可以帮助开发者以更低的成本快速进行构建、测试、迭代、重新测试，以及重新构建的过程（当然也能让利益相关者尽早参与到整个过程中）。UI 设计的原型也是移动应用设计过程中一个重要的组成部分。

本文将移动应用的开发过程分解为12 个步骤，并介绍了迭代式原型创建工作在不同阶段扮演的角色。

第1 步 – 定义应用的目标或USP

移动应用最终能否获得成功，灵感很重要，但灵感必须归纳整理为最终成果所要包含的清晰明确的目标。在将应用投放市场的过程中，第一步需要提出并回答一些核心问题：应用的主要功能是什么？主要是为了解决什么问题？主要受益者或受众是哪些人？

为了探寻这些问题的答案，可以首先考虑一下如何能让自己的应用变得更有“粘性” – 用户在自己设备上安装你的应用，并与你的品牌随时随地建立联系的原因是什么。应用为品牌忠诚度的促进提供了一个绝佳的机会，因此有必要在开发过程中针对最终成果为用户定义USP（Unique selling proposition，独特卖点）。例如Spotify 的USP 是让用户以合法方式随时随地欣赏数百万歌曲。很可能在开发工作开始时，Spotify 员工就确定了用户直接面临的问题或情况：有关非法或免费下载的顾虑，以及移动化生活方式的逐渐流行，他们的所有工作都以解决这些问题为主。

为了制定强有力的USP，无疑需要对目标受众进行妥善分析，因此在应用开发的这个阶段，需要发现最理想的客户以及他们的痛点/ 愉悦点。用户群体划分和调查问卷可以帮你为不同类型的用户创建档案，进而提炼出普适的移动应用首选项和行为。

确定目标、USP 以及目标受众，即可帮助自己定义最小可行产品（Minimum viable product，MVP），以及在构建完整解决方案之前进行测试进而指导开发工作的产品功能骨架。

第2 步 – 与团队一起在纸上建立线框

确定了目标以及自己的独特之处之后，可以开始通过诸如Photoshop 之类的工具设计界面。但如果需要团队协作（哪怕孤军奋战），还需要退一步在纸面上建立线框（Wireframe），这样如果随后需要改动设计中的某些基础元素，这一过程也会显得更快捷和简单。

通过拟定粗略的纸面原型将重要功能和主要用户流程实现具象化。虽然纸面原型通常主要用于规划个别UI，但只要恰当使用也能帮你设计用户操作流程和导航流程。此时可以一切从简，只使用马克笔和贴纸规划自己的应用，但其实也有很多实用的工具和模板可以帮你更顺利地完成纸面线框过程。网上有很多可供下载的移动设备屏幕模板，配合镂空的按钮和图标（也可以在网上下载）即可创建足以拿给潜在投资人看的纸面原型。如果打算针对某种特定操作系统进行大量开发，还可以考虑使用 UI Stencils 等金属模板，这些工具可以帮你更便利地通过模板为 iOS 和 Android 创建线框。

无论最终选择哪些工具或方法，现阶段需要让每个团队成员了解你的最终目标。做到这一点后，即可考虑用数字化的方式在原型工具中建立线框。

第 3 步 – 研究竞争对手，从他们的错误中学习经验

仅在 2015 年，每天平均就有 1000 款应用提交到 Apple 的应用商店，很有可能别人已经在试图解决你正在尝试解决的问题，或已经为用户提供了类似功能。对于这些竞争对手无需过于警惕，但你可以从他们的成功和失败中学习经验。

研究竞争对手可以让自己在四个重要方面获益：

• 发现有谁正在从事和你一样的事
• 从中获得灵感
• 洞察技术需求和功能
• 在市场需求和盈利能力方面获得榜样

使用相关术语或关键字在应用商店和 Google Play 搜索，深入了解相关应用和它们的条款。可以考虑将所有相关应用都记录下来并仔细查看客户评价，同时还可以考虑通过各种在线论坛了解用户在实际使用中的感受。

如果某个现有应用包含一些你非常喜欢的功能，可以看看这些应用是否用到了开源控件。为此可查看应用的致谢页面，其中通常会列出应用中使用的开源组件，你也可以使用类似的组件开发出更出色的用户体验。开源“商店” Cocoa Controls 提供了丰富的资源，你可以在这里查找竞争对手用到的开源控件。

当然也可以通过详尽的竞品分析了解自己有关应用的绝妙创意是否已经被别人成功开发并发布出来。如果你的应用解决方案已经有类似成品，可以通过品牌认知度或感知度工具了解对方的表现，或通过免费工具掌握市场对竞争对手产品的品牌看法。

如果无法确定自己的产品能为现有市场带来什么价值，或者无法制定稳妥的风险缓解策略，也许应该就此作罢转向下一个移动开发项目。设计和开发过程中的所有细节都要记录在案，就算项目在这一阶段彻底终止也要这样做，借此可以通过学到的经验教训对自己的方法论进行持续的完善。

第4 步 – 故事图和需求收集

确定目标和竞争对手后，可通过数字化或纸面记录的方式将构思进一步完善。如果希望用模拟方式做到这一切，也许可以开始构建用户故事，这些依然可以通过纸面方法进行，这是确保在将故事图付诸实现前维持开放心态和创新精神的一种好办法。

尽管如此，通过传统方式制作用户故事图的做法在某些情况下也会存在不足，尤其是涉及远程团队，或希望在整个设计过程中通过动态故事板保持实时和统一的情况下。如果决定通过数字化方式制作用户故事， StoriesOnBoard 和 FeatureMap 之类的工具提供了基于浏览器的解决方案，可以帮你将不同团队联系在一起。

虽然类似上文提到的故事板工具适合在很多项目中使用，但如果希望整体采用敏捷方法论，这些方式可能会妨碍到与报表有关的工作。此时你可能会希望改为使用交互式原型工具。在应用开发项目启动时，可以通过 Axure 、 InVision 或 Justinmind 等数字化工具搭建基本原型的线框，这样做可以帮助你抛砖引玉从利益相关者处获得新的或更好的需求，并确保大家能对项目界限达成共识。

这一阶段中，基本线框可以让为了解决第 1 步所确定的问题而开发的解决方案变得更形象，通过原型工具收集需求也可以免除拟定冗繁的需求文档需要付出的大量精力。

第 5 步 – 定义用户场景

借助线框可确定应用能否按照你自己或客户需要的方式工作，以及应用是否以用户为中心。你可以通过原型工具创建和测试用户场景，制作线框截图以及需要由用户执行的操作，借此定义导航流程。可以在场景中将不同组件链接在一起，借此为导航流程创建地图。一旦开始通过线框创建保真度更高的原型，还可以将其转换为功能流程。

此时项目需求已得到进一步完善，可以向利益相关者演示整个工作流，并指出所有需要讨论的领域。可以直接询问利益相关者或客户特定元素如何生效才能算作好的实践，就好像“what-if”场景一样通过讨论整个流程发现隐性需求。你可以在原型工具中添加注解，这样就算无法把所有利益相关者召集在一起，大家依然可以通过协作的方式继续对需求进行完善。

第 6 步 – 需求的更新

在这一阶段你可能会发现，自己漏掉了某个屏幕截图，某个导航流程走上了一条崎岖的单行道，或者没能充分满足某个需求。在开始为应用编写代码前，此时是发现所有此类问题的最佳时机。可以在原型工具中对需求进行定制，针对特定需求添加新的字段。

第 7 步 – 构建高保真度原型并引入利益相关者的意见

当需求经过全面修订并达成共识后，还需要将静态模型变为高保真度原型。可以为现有线框增加实际的动画和过渡效果，借此展示可以实现的交互并对前期假设的场景进行测试。

在不实际编写代码的情况下转换为交互式原型，意味着后期在设计和开发团队之间“诠释”（理解、误解）的空间会比较小。

第 8 步 – 针对不同移动操作系统对原型进行用户测试

用户测试是开发优秀移动应用的基础，通过测试可以发现 Bug 并找出以往可能没有注意到的多余设计元素。用户测试阶段也是确保项目能在预算内完成的关键：对于针对基本 UI 概念已经写好的代码进行更改，成本并不会很高，但对已经编写好的功能进行大量改动会产生不菲的成本，如果整个应用都要改动，有时可能会让成本翻倍。

用户测试可通过多种方式进行，选择恰当的软件组合可以确保整个过程的实现更为彻底。诸如 Validately 和 Crazy Egg 等用户测试软件可以帮你在无需自行搭建测试实验室的情况下针对目标受众和硬件进行测试，很多原型工具也能与此类软件全面集成。通过将这些工具与自己的 A/B 测试或其他技术配合使用，即可针对不同操作系统对高保真度的原型进行测试，借此可获得大量的用户反馈。

然而也要注意，虽然针对原型进行早期测试是缩减成本的关键，但也绝对不能将实际代码和软件的测试放到最后进行。取决于具体项目，你可能希望在这一阶段暂时忘却原型，让开发者将你的创意用代码写出来。用户到底是如何与实际软件交互的，没有 100% 精确的替代方法可以不借助代码完全体现出来，对软件代码进行迭代可以保证你能始终维持敏捷。

第 9 步 – 验证需求

在应用开发项目的这个阶段，可以在开始写代码前针对迭代原型核查最终的规则。对于依然在使用静态需求的项目，可以进行全面的文档审阅；对于交互式原型，可将提议的解决方案分享给所有利益相关者，并根据他们在原型工具中留下的注解对原型进行迭代。

第10 步 – 让开发者打好基础

至此手头已经有了一个清晰定义的应用，可以引入开发者让他们为敏捷开发冲刺打好坚实的基础。作为基础，开发团队需要设置API、服务器、和存储，通过需求和原型让他们更好地了解从何处着手开始迭代。

第11 步 – 构建你自己的UI 外壳和反馈周期

借助从利益相关者和用户测试中获得的注解，开发者已经可以将原型的截图和交互转换为更高保真度的外壳。开发者可以选择使用 Kinvey 等后端服务，并使用 Adobe PhoneGap 等 SDK 工具完善自己的前端。随着后端的逐渐推进，此时项目的重点应转向数据存储和集成，以及服务器端逻辑和版本控制。前端方面，此时可以将原型的屏幕截图硬编码至 UI 中。

无论开发团队使用何种技术，此时技术方面的首要目标是维持以用户为中心的角度，并将之前获得的用户反馈纳入考虑范围。

开发团队的管理方面应该以敏捷为主要目标。为了保持敏捷，开发团队应当对灵活性、快速的变更响应、迭代式方法，以及必要的用户协作等工作划分处轻重缓急。为了顺利实现自己的想法，可以安排整个团队进行 Scrum 冲刺，但也要注意 Scrum 有时候也会造成一些问题… 无论如何安排，迭代式开发和用户体验始终应该是整个过程的核心。

第 12 步 – 用户测试… 再一次

项目尾声阶段，移动应用的代码应该已经编写完成并已能够运行，其中不应该包含无用内容，UI 元素也已进一步打磨完毕。但在欢呼庆祝前还要记得针对所有设备和不同类型的用户再进行一轮用户测试。如果项目预算不足以支撑最终阶段的用户测试，还可以考虑其他方法：引入 ATryBox 等“用户市场”，让他们寻找合适的用户群体并进行测试，或者也可以使用测试应用，例如 Validately 或 Framer 。

如果希望通过用户测试获得更多创意，进行醉酒测试（Drunk testing）也许可以为你提供很多出乎意料的意见。

然后该干什么

迭代式原型是移动应用开发过程中的“大杀器”。从以用户和用户故事为中心，到前端/ 后端工具以及最终的用户测试，每个开发项目在最终实现和发布之前都需要经历一系列环节。虽然这些实践可以帮助你安排自己的任务和预期，但没有任何两个移动开发项目是完全相同的：借助不同的工具和方法论让你的团队实现积极主动的反应、协作和创新，最终即可获得能满足用户需求，提供出色用户体验的应用。

关于本文作者

Cassandra Naji是 Justinmind 的营销内容编辑，这款营销工具可供你为 Web 和移动应用创建原型，在无需编写任何代码的情况下使得软件解决方案具象化并对其进行测试。在转型为科技爱好者之前，Cassandra 曾在柬埔寨和台湾地区担任传统媒体记者和通信专家的职务。现在她居住在西班牙巴塞罗那。

作者： Cassandra Naji ，阅读英文原文： Iterative Prototyping in the Mobile App Development Process