当前位置:首页 > 经验学习 > 设计思想

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

所属栏目:设计思想 时间:2013-12-26 来源: 作者:admin 点击:

本文是由FreshBooks的产品经理和创意总监所写的开发实例,译者@C7210 。FreshBook是一款在线的发票服务软件,其服务的用户群体,决定了他们提供的功能必须在操作上简单、快速、高效。
因此,他们的产品界面和功能体验上有着很高的要求。本文就是他们在具体实践方面的经验之谈。
以下正文,以作者为第一人称编译:
今年,我们(英文原文作者及团队)发布了FreshBooks的第一款iPhone应用。从前我们的产品一直是通过Web端应用的方式为客户们服务的。这次,我们把iPhone应用的设计开发过程看作一张空白的花布,尽力在其中实现一些新的功能概念和设计想法。在这个过程中,我们着实学到不少东西。
不要害怕犯错
对于移动应用这样的产品,在设计开发过程中必然会面对不少较为复杂的用户体验设计方面的挑战与问题,尤其是对于新手来说更是如此。
无论你的线框稿在逻辑上有多缜密,UI稿在视觉上有多漂亮,当它们落实成为原型或最终产品时,总会有问题呈现出来。这并不完全是坏事;我们在设计FreshBooks的iPhone应用时甚至将犯错这件事也纳入到了流程规划当中,这就意味着:
坦承没有完美的设计,无论稿件和原型多么优秀。
真正的成功或失败都是由用户的反馈来定义的。
对于在设计过程中看到的问题要迅速做出反应,根据从实际用户身上得来的验证结果进行迭代。
接下来,我将向各位描述一下我们在项目中犯过的三个错误,以及我们是怎样解决这些问题的。
应用的主界面
在项目开始的时候,我们对FreshBooks的一些现有用户进行了访谈,了解他们在生活和工作中是怎样使用移动设备的,包括他们面对的实际问题,以及他们对移动应用版本的FreshBooks的期望。
根据这些访谈,我们归纳出了一些基本的设计原则,例如下面这条:
以任务为中心的用户体验:
移动应用版本的产品应该围绕着一系列互不相关的帐单任务进行优化,包括时间追踪、为收据拍照存档、开票等等,这些是移动应用所处的使用场景当中最常见的任务。
而其他方面的复杂任务,包括批量编辑、权限管理、定制化等,则留给传统的Web端应用来承担,以此来保证移动版本在功能上的简约与集中。
基于这条原则,我们设计了应用的主界面。它由一系列最重要的任务组成,视觉上采用图标加文字标题的形式,点击进入相应的任务流程。例如,用户点击了其中的“New Invoice”之后会进入发票列表界面,然后创建新发票的界面会自动滑入视图。



这种以典型任务为中心的设计思路在意图上是好的,但接下来我们发现了一些问题。
为什么会出问题
经过可用性测试,我们发现被测者普遍会在主界面中产生困惑,因为这种设计方案与他们通过使用Web端的FreshBooks所建立起的心智模型不符,而且和很多其他的iPhone应用也存在模式上的差异。
同时我们还发现,之前归纳出的一些典型任务,包括创建发票、跟踪时间、记录开支等,对于用户来说,本质上都属于一种“创造”行为。从这个角度看,其实我们忽略了这个纬度上的其他一些重要任务类型,包括:
查看:例如查看发票状态、查看历史记录等。
更新:例如更改发票状态等。
这类任务需求其实比“创造”更加普遍,尤其是在移动设备上,用户更加倾向于在短时间内以最简单高效的方式查看和更新内容,而不是创造内容。我们之前所聚焦的重点则恰恰相反。
解决方案
很简单,我们改变了之前方案当中的信息结构,使内容和功能的组织结构更加符合用户在移动应用上下文环境中的预期。在新的设计方案中,用户点击主界面中的“发票”(之前是“创建新发票”),进入发票列表界面进行查看;如果他确实需要创建新发票,那么可以点击右上角的加号按钮。



相关阅读:产品早期的原型设计与用户测试
初次使用的体验
我们特别为应用初体验(用户安装应用后第一次打开)制订了两条设计原则:“移动优先”与“顺畅进入任务流程”。具体来看:
移动优先:
如今,我们不能再假设用户是通过桌面设备上的Web浏览器找到我们的,他们很有可能是在移动设备上与我们发生第一次接触的,我们不能让这类新用户产生复杂的认知负担。举个例子,我们的Web端应用可以为用户提供定制化的子域名(youraccountsubdomain.freshbooks.com),这显然是专属于Web端的概念,完全不需要在移动端体现出来。

请站长喝杯咖啡?

站长一直坚持白天工作、晚上熬夜更新素材,付出了巨大的精力和时间,其中的辛酸难以言述。

坚持免积分、免登录、无任何限制下载!如果本站素材对你有用,不妨考虑请站长喝杯咖啡鼓励一下!

标签:

你应该也喜欢这些吧

共有 0 条评论

给个评价吧

验证码: