那些在设计iOS应用时犯过的错误.pdf

那些在设计 iOS 应用时犯过的错误 本文是由 FreshBooks 的产品经理和创意总监所写的开发实例，译者 @C7210 。FreshBook 是一款 在线的发票服务软件，其服务的用户群体，决定了他们提供的功能必须在操作上简单、快速、高效 。 因此，他们的产品界面和功能体验上有着很高的要求。本文就是他们在具体实践方面的经验之谈。 以下正文，以作者为第一人称编译： 今年，我们 (英文原文作者及团队 )发布了 FreshBooks 的第一款 iPhone 应用。从前我们的产品一直是 通过 Web 端应用的方式为客户们服务的。这次，我们把 iPhone 应用的设计开发过程看作一张空白的 花布，尽力在其中实现一些新的功能概念和设计想法。在这个过程中，我们着实学到不少东西。 不要害怕犯错 对于移动应用这样的产品，在设计开发过程中必然会面对不少较为复杂的用户体验设计方面的挑战 与问题，尤其是对于新手来说更是如此。 无论你的线框稿在逻辑上有多缜密， UI稿在视觉上有多漂亮，当它们落实成为原型或最终产品时， 总会有问题呈现出来。这并不完全是坏事；我们在设计 FreshBooks 的iPhone 应用时甚至将犯错这 件事也纳入到了流程规划当中，这就意味着： 接下来，我将向各位描述一下我们在项目中犯过的三个错误，以及我们是怎样解决这些问题的。 应用的主界面 在项目开始的时候，我们对 FreshBooks 的一些现有用户进行了访谈，了解他们在生活和工作中是怎 样使用移动设备的，包括他们面对的实际问题，以及他们对移动应用版本的 FreshBooks 的期望。 根据这些访谈，我们归纳出了一些基本的设计原则，例如下面这条： 以任务为中心的用户体验： 移动应用版本的产品应该围绕着一系列互不相关的帐单任务进行优化，包括时间追踪、为收 据拍照存档、开票等等，这些是移动应用所处的使用场景当中最常见的任务。 而其他方面的复杂任务，包括批量编辑、权限管理、定制化等，则留给传统的 Web 端应用来 承担，以此来保证移动版本在功能上的简约与集中。 基于这条原则，我们设计了应用的主界面。它由一系列最重要的任务组成，视觉上采用图标加文字 标题的形式，点击进入相应的任务流程。例如，用户点击了其中的 “New Invoice之后会进入发票列” 表界面，然后创建新发票的界面会自动滑入视图。 这种以典型任务为中心的设计思路在意图上是好的，但接下来我们发现了一些问题。 为什么会出问题 经过可用性测试，我们发现被测者普遍会在主界面中产生困惑，因为这种设计方案与他们通过使 用Web 端的 FreshBooks 所建立起的心智模型不符，而且和很多其他的 iPhone 应用也存在模式上的 差异。 同时我们还发现，之前归纳出的一些典型任务，包括创建发票、跟踪时间、记录开支等，对于用户 来说，本质上都属于一种 创造“ ”行为。从这个角度看，其实我们忽略了这个纬度上的其他一些重要 任务类型，包括： 这类任务需求其实比 创造“ ”更加普遍，尤其是在移动设备上，用户更加倾向于在短时间内以最简单 高效的方式查看和更新内容，而不是创造内容。我们之前所聚焦的重点则恰恰相反。 解决方案 很简单，我们改变了之前方案当中的信息结构，使内容和功能的组织结构更加符合用户在移动应用 上下文环境中的预期。在新的设计方案中，用户点击主界面中的 发票“ ”(之前是 创建新发票“ ”)，进入 发票列表界面进行查看；如果他确实需要创建新发票，那么可以点击右上角的加号按钮。 相关阅读：产品早期的原型设计与用户测试 初次使用的体验 我们特别为应用初体验 (用户安装应用后第一次打开 )制订了两条设计原则： 移动优先“ ”与 顺畅进入任“ 务流程 ”。具体来看： 移动优先： 如今，我们不能再假设用户是通过桌面设备上的 Web 浏览器找到我们的，他们很有可能是在 移动设备上与我们发生第一次接触的，我们不能让这类新用户产生复杂的认知负担。举个 例子，我们的 Web 端应用可以