今年在FreshBooks，我们发布了我们的第一个iPhone应用程序。我们公司已经成立将近10年了，这真的是我们推出云会计web应用程序以来的第一款新产品。我们将iPhone应用的开发当成一块空白的画布，在那里我们可以运用团队最新的设计原则。
我们还想强化我们在产品开发过程中所学到的经验教训。但最终，我们的官方iPhone应用程序的创建为我们提供了学习和成长的机会。
犯错是可以的
在设计像手机应用这样复杂的用户体验时，出错是不可避免的，尤其是当你从未做过的时候。和你的逻辑一样线框图虽然你的模型看起来很漂亮，但当你把它们放在顾客面前时，你的一些设计可能会失败。
不管你信不信，这是一件非常非常棒的事情。当我们设计FreshBooks iPhone应用程序时，我们将失败作为设计过程的一部分。接受失败意味着以下三件事:
- 认识到没有什么设计是神圣的，不管它在纸上看起来有多伟大。
- 承认我们的客户最终决定了设计的成败。
- 当某些东西不能工作时，迅速做出反应，并不断迭代，直到客户告诉我们我们做对了。
最终的结果是一个非常优秀的最终产品，并且减少了客户如何接受它的不确定性。所以，话不多说，以下是我们在iPhone应用程序中犯的三个错误，以及我们如何纠正它们。
手机主屏幕
在这个项目的开始，我们采访了一些现有的FreshBooks客户，以了解他们是如何使用的移动在他们的日常生活中，他们面临的问题，以及他们想在FreshBooks的移动体验中看到什么。我们在这些访谈中观察到的趋势和见解最终形成了一套设计原则。以下是我们从访谈中总结出的一个设计原则:
以任务为中心的用户体验移动用户体验将围绕离散的账单任务集(跟踪时间、拍摄收据照片、创建发票等)进行优化，这将是移动环境中最常见的。
将更复杂的场景(如批量编辑、权限管理、自定义和配置等)推迟到FreshBooks web应用程序，以保持移动应用程序的重点和简单性是可以接受的。
遵循这一原则，我们的第一个iPhone应用主屏幕设计包含了一组描述手机上重要任务的瓷砖，如创建发票、记录支出、跟踪时间等。点击其中一个贴图启动相应的任务。
这种方法是基于这样一种理念，即围绕快速创建进行优化对于移动环境中的用户来说非常重要(游戏邦注:例如，他们在出租车后座上只有30秒的时间去提交消费文件)。这是我们最初的主屏幕设计:
优化快速创建:在主屏幕上点击“新发票”导航用户到发票列表，并创建一个新的空白发票。这种导航方案偏离了典型的iOS设计模式，也偏离了我们自己的web应用程序。
通常，信息体系结构(IA)是基于集合(例如，发票、估计、费用等)而不是与其相关的任务/动词(创建发票，创建预算，记录费用等)。下面是基于集合组织内容的典型示例。
基于集合的传统导航方案。
我们的想法是，通过将应用程序的主屏幕定位于任务而不是集合，这将意味着只需要点击一次就可以创建发票，记录时间，记录费用等，使我们的应用程序从根本上以任务为中心的体验。
我们是怎么错的
我们的beta测试者普遍认为我们基于任务的主屏幕方向令人困惑。它与我们的web应用和许多其他iPhone应用建立的现有思维模式相差太远。以下是我们从一个在我们最初的基于任务的主屏幕设计中遇到麻烦的人那里捕捉到的可用性测试视频:破碎的心智模式:Beta测试者在基于任务的导向中挣扎。
观察测试人员与应用程序的互动还暴露了我们以任务为中心的设计原则的缺陷。我们认为对移动来说很重要的独立计费任务——创建发票、跟踪时间、记录费用等等——都是基本的创建．
我们忽略了其他任务类别的重要性，例如:
- 查看:检查发票或预算的状态，查看项目的历史，等等。
- 更新:重新报销费用，发送发票草稿等。
这类任务实际上比创作更常见——尤其是在手机上，用户对审查和编辑更感兴趣，而不是创作——然而我们的设计没有强调它们的重要性。
解决方案
在这种情况下，解决方案相当简单。采用与核心web应用程序相同的IA。换句话说，坚持做有效的事情。
这是更新后的主屏幕设计和你点击时看到的发票图标:
坚持做有效的事情。传统的信息体系结构更容易理解。
第一次跑步体验
我们创造了两个设计原则来指导我们的应用方法第一次运行经验(当你第一次启动我们的应用程序时所看到和体验到的)。这些设计原则是:手机第一而且无摩擦的开始．以下是两个更详细的设计原则:
手机第一我们不能再假设人们主要通过网络浏览器找到我们。
当他们刚刚开始使用移动设备时，新用户不应该被我们的web应用程序的复杂性所拖累——更不用说了解它的存在了。例如，帐户子域(例如，)是web应用程序中的一个核心概念，对于“移动优先”用户来说应该是不可见的，因为它们与移动设备几乎没有关联。当一项服务补充的价值最强时(例如，当保存一张发票时，可以自动备份到云端)，web应用程序将逐步向移动用户介绍。
无摩擦的开始新用户一旦启动移动应用程序就会看到价值——不需要配置或设置。这直接遵循了“移动第一”原则。
首先，我们采用了一个非常字面的应用无摩擦的开始我们设计应用程序首次运行体验的原则。
甚至在创建帐户或登录之前，用户会立即被带到主屏幕，在那里他们可以开始创建发票，跟踪时间，记录费用等等——所有这些都在启动应用程序的几秒钟内完成。不需要登录或创建帐户。这种设计推迟了帐户的创建和登录，直到它为用户提供了相关的好处。
例如，当保存发票/估算/费用时，会提示用户创建一个帐户或登录，以便将数据备份到云端——这是一个明显的好处。
利益驱动设置:在保存时，提示用户创建帐户或登录，以便将信息备份到云端。另一个例子:通过蜗牛邮件发送发票。
利益驱动设置:提示用户创建一个帐户或登录以通过蜗牛邮件发送发票。
我们是怎么错的
第一次运行体验遭遇了与主屏幕类似的可用性问题。考虑到这种模式的普遍性，Beta测试者希望在应用启动后立即创建一个帐户或登录。在只有主屏幕的情况下，测试者在使用这款应用时很犹豫，而且有很多问题没有得到回答。
他们的数据会被保存在哪里?转到新账户?如果他们已经有账户了呢?
以下视频展示了我们最初的首次体验设计所带来的困惑:未回答的问题:对普遍范式的彻底背离导致了犹豫和困惑。把创建或登录账户的时间推迟到与其利益最相关的时候，这很新颖，但最终还是太激进了。
解决方案
经过进一步探索，我们认为最好的方法是在第一次运行时立即向用户呈现三个明显的选项:
- 创建一个帐户
- 登录到已有的帐户
- 试试这个应用吧
准备创建帐户或登录的用户可以立即这样做。那些还没准备好注册的用户可以先浏览一下这款应用，他们完全有信心，当他们准备好了就可以创建或连接一个账户。
两全其美:用户可以创建一个账户，立即登录，或者先浏览应用程序。
移动应用程序和Web应用程序之间的特性差距
在深入研究设计之前，我们通过定义手机的功能范围来构建我们的方法最小可行产品．这一点很重要，原因如下:
- 有很大的风险如果范围定义松散，则特性渐变特别是在“版本1”产品中。最后，重要的是要知道产品的功能何时完成，以避免追逐移动目标。
- 明确的范围提供了信心，从研究中得到的顶级功能需求将被最终产品所满足。
- 市场上已经存在的web应用程序的范围可能意味着其相应的移动应用程序的范围。这是一个糟糕的假设。移动应用是针对不同的场景进行优化的，通常不能保证与web应用的功能对等(即复杂性对等)。
- 最后，提前建立移动范围可以消除web应用中任何依赖特性的相关开发障碍。(例如，我们将收据拍照确定为移动设备的一个关键场景，这需要在web应用程序中进行前期工作以支持收据图像。)
正如前面提到的，我们最初假设人们真正想要的是快速创建公共实体(发票、费用、时间条目)。因此，在定义项目范围时，我们将开发的内容限制在这些核心任务中。下面是两个web应用程序特性的例子，它们是针对移动设备的。
设置作为我们的联合创始人和用户体验大师迈克冗长、复杂的设置页面通常是糟糕设计的标志。web应用程序一直在稳步简化和删除设置，但我们还有很长的路要走。因为移动平台代表了一个全新的机会，我们决定采用极简的设置体验，即使是以删除web应用中的一些定制为代价。
报告会计报告(如损益、账龄等)是FreshBooks云会计核心价值主张的重要组成部分。然而，会计报告有一个定义良好的格式，不容易适应移动形式因素。
最终，我们决定最好将报表留给web应用程序，在web应用程序中查看报表将更加常见，并且可以得到更好的支持。
我们是怎么错的
将会计报告提交给FreshBooks web应用程序对于之前对该应用程序没有经验或知识的beta测试者(即“移动优先”用户)是有问题的。在移动端缺少Reports意味着我们没有达到他们对一个功能齐全的会计应用程序的期望。在现实场景中，这种明显的功能差距很容易让用户放弃使用，直到他们意识到Reports实际上是web应用程序中的一个免费功能。
解决方案
不过，在移动设备上呈现可读财务报告的问题并不容易解决。但这不是需要解决的问题。事实证明，beta测试者并不想在他们的手机上查看Reports，他们只是想在继续试验之前得到它们存在的保证。
于是，报告就成了另一个机会，用来传达创建帐户并连接到FreshBooks服务的好处。
内置明显的关键功能保证，如报告，即使它们不是一个关键的移动场景。
底线
FreshBooks之所以存在，是因为它的第一位用户兼联合创始人迈克·麦克德门特在2003年一个繁忙的下午遇到了麻烦，他不小心把一张发票存了起来，弄丢了工作。认识到潜在的失败和挫折是每个用户体验的一部分是创造更好产品的第一步。FreshBooks的每个设计项目都始于对客户的同理心;这是驱动我们所做一切的基本原则。
相关内容
- 为什么你应该以手机网页应用(而非原生应用)为主导?
- 移动网页设计:最佳实践
