咱们在设计iPhone应用时犯过的错误

本文是由FreshBooks的产品经理和创意总监所写的开发实例。FreshBook是一款在线的发票服务软件，其服务的用户群体，决定了他们提供的功能必须在操做上简单、快速、高效。所以，他们的产品界面和功能体验上有着很高的要求。本文就是他们在具体实践方面的经验之谈。

如下正文，以做者为第一人称编译：

今年，咱们(英文原文做者及团队)发布了FreshBooks的第一款iPhone应用。从前咱们的产品一直是经过Web端应用的方式为客户们服务 的。此次，咱们把iPhone应用的设计开发过程看做一张空白的花布，尽力在其中实现一些新的功能概念和设计想法。在这个过程当中，咱们着实学到很多东西。

不要惧怕犯错

对于移动应用这样的产品，在设计开发过程当中必然会面对很多较为复杂的用户体验设计方面的挑战与问题，尤为是对于新手来讲更是如此。

不管你的线框稿在逻辑上有多缜密，UI稿在视觉上有多漂亮，当它们落实成为原型或最终产品时，总会有问题呈现出来。这并不彻底是坏事；咱们在设计FreshBooks的iPhone应用时甚至将犯错这件事也归入到了流程规划当中，这就意味着：

坦承没有完美的设计，不管稿件和原型多么优秀。

真正的成功或失败都是由用户的反馈来定义的。

对于在设计过程当中看到的问题要迅速作出反应，根据从实际用户身上得来的验证结果进行迭代。

接下来，我将向各位描述一下咱们在项目中犯过的三个错误，以及咱们是怎样解决这些问题的。

应用的主界面

在项目开始的时候，咱们对FreshBooks的一些现有用户进行了访谈，了解他们在生活和工做中是怎样使用移动设备的，包括他们面对的实际问题，以及他们对移动应用版本的FreshBooks的指望。

根据这些访谈，咱们概括出了一些基本的设计原则，例以下面这条：

以任务为中心的用户体验：

移动应用版本的产品应该围绕着一系列互不相关的账单任务进行优化，包括时间追踪、为收据拍照存档、开票等等，这些是移动应用所处的使用场景当中最多见的任务。

而其余方面的复杂任务，包括批量编辑、权限管理、定制化等，则留给传统的Web端应用来承担，以此来保证移动版本在功能上的简约与集中。

基于这条原则，咱们设计了应用的主界面。它由一系列最重要的任务组成，视觉上采用图标加文字标题的形式，点击进入相应的任务流程。例如，用户点击了其中的“New Invoice”以后会进入发票列表界面，而后建立新发票的界面会自动滑入视图。

这种以典型任务为中心的设计思路在乎图上是好的，但接下来咱们发现了一些问题。

为何会出问题

通过可用性测试，咱们发现被测者广泛会在主界面中产生困惑，由于这种设计方案与他们经过使用Web端的FreshBooks所创建起的心智模型不符，并且和不少其余的iPhone应用也存在模式上的差别。

同时咱们还发现，以前概括出的一些典型任务，包括建立发票、跟踪时间、记录开支等，对于用户来讲，本质上都属于一种“创造”行为。从这个角度看，其实咱们忽略了这个纬度上的其余一些重要任务类型，包括：

查看：例如查看发票状态、查看历史记录等。

更新：例如更改发票状态等。

这类任务需求其实比“创造”更加广泛，尤为是在移动设备上，用户更加倾向于在短期内以最简单高效的方式查看和更新内容，而不是创造内容。咱们以前所聚焦的重点则偏偏相反。

解决方案

很简单，咱们改变了以前方案当中的信息结构，使内容和功能的组织结构更加符合用户在移动应用上下文环境中的预期。在新的设计方案中，用户点击主界面 中的“发票”(以前是“建立新发票”)，进入发票列表界面进行查看；若是他确实须要建立新发票，那么能够点击右上角的加号按钮。

初次使用体验

咱们特别为应用初体验(用户安装应用后第一次打开)制订了两条设计原则：“移动优先”与“顺畅进入任务流程”。具体来看：

移动优先：

现在，咱们不能再假设用户是经过桌面设备上的Web浏览器找到咱们的，他们颇有多是在移动设备上与咱们发生第一次接触的，咱们不能让这类新用户产 生复杂的认知负担。举个例子，咱们的Web端应用能够为用户提供定制化的子域名 (youraccountsubdomain.freshbooks.com)，这显然是专属于Web端的概念，彻底不须要在移动端体现出来。

咱们还能够随着产品价值的逐渐体现而将Web端的高级功能一点点的介绍给移动端用户。

顺畅进入任务流程

要让新用户在打开应用以后无需任何设置工做就能够顺畅进入任务，从而在最短的时间内发现产品价值。

为了贯彻这些原则，咱们在初版当中容许用户不执行任何注册或登陆的操做就能够马上在主界面当中执行任务(例如前面提到的建立发票、跟踪时间等)，只有在功能须要的时候才会引导他们进行账户方面的操做，例如在保存发票或收支记录时会要求用户建立账户或登陆。

另外在用户选择经过SnailMail发送发票的时候也会如此。

为何会出问题

咱们的用心是好的，可是在可用性测试中，咱们发现被测者们更指望在应用加载以后首先进行注册或登陆；直接让他们进行操做反而会引起他们的疑虑，例如数据怎样保存？

这种先操做后注册/登陆的方式也许相对有新意一些，并且会适合于某些类型的应用，但对于咱们的产品来说仍是过于激进了。

解决方案

最后咱们采用了一种相对传统但更加符合用户预期、能够给他们带来安全温馨感受的方案，也就是一开始就向他们提供三个明确的选项：

建立新账户

登陆已有账户

直接试用

若是用户以为本身已经准备好了，那么能够进行注册和登陆操做；他们还能够在不登陆的状况下先试用，以便对产品进行更全面的了解。

移动版与Web版的功能差异

咱们在设计流程开始以前详细规划了移动版产品在初期的功能范围，也就是对咱们的最小化可行产品(MVP)的形态进行界定。咱们相信：

在功能范围上未经详细定义的移动版产品(特别是初版)具备很大的风险，在设计开发流程中将产生极大的不肯定性。

在初期对产品功能范围进行合理的界定，将有助于那些基于市场及用户研究所得出的核心需求被更加准确的落实到最终产品当中。

早已投放市场并通过验证的Web端产品功能没法表明移动版的需求。移动应用有其特定的使用环境和场景。

移动版本中的某些功能会依赖于Web端。提早作好规划工做，将有助于开发工做的顺利进行。例如，移动版特有的为收据拍照的功能要求Web端必须具备相应的功能支持，包括查看收据照片等等。

不过，正像在前文中提到的，咱们曾经假设用户最想要的是快速建立内容。所以，在界定功能的时候，咱们基于这个错误的假设将核心功能限制在了这个范围当中。

报表

以财务报表为例，这是FreshBooks的Web版本当中的一个核心功能，但因为其规范化的格式难以适应移动设备的界面规格，加之咱们初期一直将重心放在“创造内容”上，因此咱们决定在移动版当中舍弃掉这个功能。

为何会出问题

财务报表实际上是财务软件当中很是重要的一部分。咱们在界定功能范围的时候将这部分功能从移动版当中移除，结果在可用性测试中发现这彻底不符合被测者们对于一个功能完整的财务软件的认知与指望。

另外咱们也意识到，在现实中，若是移动版的产品当中不包含这项功能，那么新用户颇有可能根本没法了解到其实咱们的Web版应用是提供了这个功能的，他们为此而放弃该产品的概率会变的很大。

解决方案

咱们显然不是无缘无故将报表功能从移动版本当中移除的，它在呈现方式上确实存在着难以解决的问题，但实际上这个问题并不是必定要被解决——经过进一步 思考，咱们认为用户的真正目标并非必定要在移动设备上看到报表，对他们来讲最重要的是了解到有这样一个功能存在，以及能够怎样去查看这些内容。

最终，咱们决定在移动端增长报表的入口，用户点击后会被引导进行注册或登陆。已经处于登陆状态的用户能够选择“将报表发到个人邮箱”或“在iPhone的Safari浏览器中直接查看”，同时界面还会提示用户，浏览报表的最佳方式是使用台式设备。

总结

敢于挖掘并面对设计当中的错误与问题，并思考相应的解决方案，这是不断提高产品价值及用户体验的关键要素。提出假设、与真实的用户进行沟通、验证假设并发现问题、思考解决方案、迭代——是咱们在设计工做当中应该保持的良好节奏。