【书摘】亲爱的界面:让用户乐于使用、爱不释手

观察生活越细致,挖掘出来的细节越有价值。


第2章 工作观察和情境访谈

工作观察(job shadowing)和情境访谈(contextual interview)这两种方法用于观察人们的行为,发现他们需要帮助的地方,并查明产品该如何给用户提供帮助。具体来说,就是在人们工作时进行观察,以及就他们的工作与之交谈。

2.1 观察目标人群

我们了解到大部分人都不是产品设计师。他们很难解释清楚究竟需要什么样的产品来实现自己的目标,并且通常无法准确地拿捏自己对产品的感觉。因此,我们不能仅靠询问人们想要什么来解决问题,而应该自己寻找答案。工作观察和情境访谈正是用来完成这一任务的两种方法。

2.2 工作观察

由于人们根本不知道自己想要什么,因此比较好的办法就是直接观察他们的行为。“工作观察”是指在目标人群使用我们产品的场所内观察用户,其目的是找出产品应该如何帮助用户实现目标。这有点像可用性测试,但我们不是邀请用户过来测试产品,并告诉他们做什么,而是走访现场去观察他们的行为。

2.3 情境访谈

在工作观察之后,花半个小时就用户所做的事情询问一些问题。你要做的是找出产品可以改进的地方。不要询问用户的观点,也不要把用户当作产品设计师,问一些太过专业的问题。

问题要紧密围绕用户所执行的任务,因此应该包括以下几个方面。

  • 除了我今天看到的之外,你是否还经常要做别的什么任务?
  • 你最常解决什么样的问题?
  • 你为什么用这种方式做这件事(即采访者所看到的事)?
  • 如果完成任务还需要一些别的信息,你会怎么做?
  • 你经常打交道的人都有谁?你们是如何做的?
  • 如果你需要的某个人没有上班,或者发生了其他问题,你需要做些什么?

需要注意的是,人们都是在没有经过深思熟虑的情况下回答以上问题的,因此你所得到的信息通常是不完整的,其中可能包含用户的个人感情色彩甚至是错误。尽管如此,情境访谈还是能为我们提供用户行为的概况,帮助我们找到还能从哪些方面改进产品。另外,通过访谈多个对象,我们还可以发现很多遗漏内容或是错误信息。

2.5 情境访谈的局限性

肯尼德·鲍尔斯和詹姆斯·鲍克斯合著的《潜移默化:用户体验设计行动指南》(Undercover User Experience Design)一书中有一章专门谈到了此类用户研究方法。罗伯特·霍克曼在《一目了然:Web和移动应用设计通识方法》(Designing the Obvious)一书阐述了工作观察和情境访谈的内容。

第4章 以行动为中心的设计

根据所设计产品的不同,把行动作为设计的焦点可能会更有意义。进行用户研究,找出你所要支撑的用户行为,但不要为了特定人群而制造出使用行为。严格评估用户反馈。有时,某些因素可能会让产品在某个特定用户群体中非常受欢迎,但也可能会让其他人不喜欢你的产品。谨记,用户有能力适应你的产品,你不必总是使产品适应用户。

唐纳德·诺曼在他颇受争议的文章《以人为中心的设计可能有害》(Human-Centered Design Considered Harmful)中对“以行动为中心的设计”进行了阐述。在《易用的软件》一书中,拉里·康斯坦丁和露西·洛克伍德提倡“以使用为中心的设计”(而不是“以行动为中心的设计”。罗伯特·霍克曼在《一目了然》一书中对“以行动为中心的设计”有所描述。当然,除了本章介绍的设计方法之外,还有一些其他的设计方法。例如,艾伦·库帕在《交互设计精髓》一书中介绍的“目标导向设计”。

5.5 讨论产品的任务

编写产品使用手册、博文,制作截屏视频都能迫使你向其他人解释你的设计。这能帮助你发现设计存在的问题:如果某些东西很难解释清楚,那么它可能就不好用。人们只有在遇到困难的时候才会阅读使用手册,因此使用手册一定要解决问题,而不是让用户更加郁闷。

发表新闻和博文能帮助你思考产品的设计目标,把重点放在所要解决的问题上。你能用一句话说清楚你的产品吗?如果不能,那么你要实现的功能可能太多了,或者根本没有解决什么具体的问题。

如果你正在编写用户使用手册,并且需要一些方法对其进行测试,你可以在梅诺·德容和彼得·范德波特合写的文章《技术文档的可用性测试过程》(Towards a usability test procedure for technical documents)中找到答案,在Google图书或者《高品质的技术文档写作》(Quality of Technical Documentation)一书中可以找到这篇文章。

第6章 文字的可用性

37signals团队对此也持相同观点。在《把握现实》一书中,他们写道:“有好文字,才有好设计。”因此,应当把文字当作界面设计的一部分。

6.3 少用一些文字

既然用户根本不想阅读,那么最好还是尽量不要让文字打扰到他们。例如,在用户将要做某些破坏性事件时不要发出警告,而是允许他们撤销自己的操作。

如果无可避免地要告知用户,那么就先假设用户根本不会阅读你的文字,再去设计用户界面。比如在按钮标签上使用动词,保证每个按钮都有特定的、排他的标签。不要把按钮的标签设为“Yes”和“No”,而应该设定为“删除文件”和“取消”。这样,用户不用阅读对话框中的文字,就知道每个按钮的作用。

6.4 使用可粗略浏览的文字

雅各布·尼尔森的研究表明,人们通常不会在网页上逐字逐句地阅读,而是粗略地浏览页面,寻找那些包含有用信息的文字片段。为了帮助人们实现这一目的,尼尔森给出了以下设计准则。 使用对用户有用的词汇;

每段只阐明一个主旨;

  • 将各段主旨置于首句,以便用户迅速做出决定是否阅读;
  • 使用能概括段落含义的标题;
  • 加亮关键词;
  • 使用项目符号列表;
  • 使用简短、日常化的文字;
  • 以结论性的语句开始段落,并对段落内容进行总结。

6.8 使用图片阐明要点

使用图片有助于阐明要点。恰到好处的屏幕截图能省去好几段文字,也更易于理解。对于有些用户,使用插图甚至可以为简单的说明增色不少。

6.11 使用易读的文字

使用大号字。虽然大部分人读书时都离书很近,但看电脑屏幕时距离要远一些。坐在电脑前审视你设计的网站或应用程序时,可以把书放在正常的阅读距离处,然后对比书中的文字和电脑上所显示文字的字体大小。

使用易读的字体。不同字体的易读性差别很大,甚至是同一字体族内的不同成员,相差也很大。选择一个好的字体非常重要。

  • 如果可以,不要使用文字。
  • 如果无法避免,使用精炼、含义明确且可以略读的文字。
  • 使用短小精悍的段落,每段文字阐述一个主题。
  • 保证文字具有吸引力和个性,而不是枯燥无味或过于专业。
  • 用插图阐明要点,让文字更加平易近人。
  • 使用大号字和易辨识的字体。

雅各布·尼尔森写了很多关于为网页撰写内容的好文章。如果你正在撰写产品使用手册,帕特里夏·怀特的《高品质的技术文档写作》一书中有很多有用的信息。乔尔·斯波斯基在《程序员的用户界面设计指南》(User Interface Design for Programmers)中谈到了有关阅读的内容。自然科学作家卡尔·兹莫尔也写了一篇关于如何撰写优秀科学论文的文章。蒂姆·拉德福特根据自己从事记者工作的经验提出了一系列撰写好文章的准则。如果你对如何写出优秀的文章感兴趣,我强烈建议你读一下史蒂芬·金的《论写作》。

第7章 用户界面设计中的层级结构

考虑如何布局产品元素的层级结构。使用层级结构向用户提示产品的工作方式。产品的各个界面应该向用户显示隐性或显性的层级结构。

设计师把那些大部分人称为“组织事物”的行为称为信息架构(information architecture)。关于这一主题有很多不错的书籍,如唐娜·斯宾塞写的《信息架构实用指南》(A Practical Guide to Information Architecture)。另外一本比较好的入门类书籍是皮特·摩威利和路易斯·罗森菲尔德合著的《Web信息架构》(Information Architecture for the World Wide Web)。

第8章 卡片分类

如果产品比较复杂,必须对其内容进行分类,那么可以考虑使用卡片分类技术。如果你正在设计一个网站,需要决定如何组织各个页面,或者你正在开发具有多种功能的应用程序,要以用户可以理解的方式对其功能进行组织分类,那么本章内容正是为你量身定做的。

第9章 心理模型

使用产品的用户并不是中立的、毫无偏见的。他们在使用产品之前对产品应该如何工作就已经有了自己的观点。但大部分产品都没有按照人们所期望的方式工作,人们不得不“学习”如何使用产品。与其强迫人们去学习如何使用产品,创建出按照人们的期望工作的产品不是更好吗?乔尔·斯波斯基在《程序员的用户界面设计指南》一书中说道:“只有某个程序完全按照人们所期望的方式工作,其用户界面才能称得上是优秀的设计。”

9.1 人的思维

此处有一个重要的问题:从技术层面讲,用户关于汽车工作原理的心理模型是错误的,但这一模型却有助于人们理解如何控制汽车,因为心理模型的交互逻辑与汽车的反应非常匹配(至少大部分时候是这样的)——踩下油门踏板,汽车会跑得更快。换句话说,用户的心理模型不一定必须正确,只要和产品的行为方式一致就行了。

9.2 三种不同的模型

我们的产品实际上反映出三种不同的模型。

  • 用户大脑中的产品工作原理,也就是用户关于产品的心理模型。
  • 产品在用户界面中呈现的方式,我称之为“UI模型”。
  • 产品实现功能的过程,我称之为“实现模型”。

在理想的产品中,以上三种模型应该是一致的。用户界面完美地表现产品实现功能的过程,用户能准确地理解他所看到的东西。

9.5 为心理模型而设计

玛丽·乔·戴维森、劳拉·德芙和朱丽叶·韦尔兹在他们的论文《心理模型与可用性》(Mental Models and Usability)中介绍了能够帮助用户形成有效心理模型的七个用户界面设计原则。

原则一:简单

心理模型是简化版的现实世界。如果你的产品遵从一些简单的原则,那么用户的心理模型很可能会与系统的实际工作原理相一致,用户也能更容易地掌握这些原则。

原则二:熟悉

用户在使用产品之前已经具备了大量的经验知识。你的产品应该与相似产品保持一致,与现实世界中产品的工作原理保持一致,这样,用户才有可能形成正确的心理模型。比如人们在当前大部分操作系统中删除文件的操作是这样的:把要删除的文件扔进垃圾箱,然后清空垃圾箱。你不需要向人们解释如何分辨空的垃圾箱和有文件的垃圾箱,他们的经验知识足以分辨出这两者的差别。

原则三:易于识别

不要让用户回忆如何做某些事情,而是要为他们提供一些有助于理解当前选项的提示或显而易见的选择。

原则四:灵活

如果可以,允许用户以任意的顺序、使用不同的技术执行操作。

原则五:反馈

要经常为用户的交互动作提供即时、有效的反馈。如果用户点击了某些东西,那么这些东西应该立刻以高亮效果显示。如果他们拖动了某些东西,那么这些东西应该随着鼠标或手指的运动轨迹移动,不应该存在任何延迟。如果他们启动了某个需要花一些时间才能完成的动作,就应该向用户显示一个动态指示器,比如用进度条来告知用户,电脑已经接收到了他发出的指令,正在处理(更多内容,参见第23章)。

原则六:安全

用户的操作应该是无害的,除非用户成心想做一些破坏性的事情。在关闭一个未保存更改的文档时,在损坏已更改的内容之前应该为用户提供反悔的机会,允许用户撤销他们的行为(参见第19章)。让用户可以毫无后顾之忧地自由探索,这样他们才能更加放心大胆地学习产品的使用方法,让自己的心理模型适应产品的工作原理。

原则七:功能可见性

用户界面元素的设计应该向用户提示界面元素的交互方式。传达可行交互方式的设计细节称为功能可见性(affordance)。

唐纳德·诺曼在《设计心理学》(The Design of Everyday Things)一书中写道:好的设计师会让用户看到适当的操作,而把不适当的操作隐藏起来。

人类对事物的工作原理有自己的观点。你的产品越接近这些观点,人们在使用产品时要学习的东西就越少。为了匹配用户的心理模型,你必须经常向用户隐藏产品的实现细节。要小心提防那些抽象漏洞。为心理模型而设计,要把产品设计得简单、熟悉、灵活并且安全。向用户提供反馈,并且在任何特定的时刻,都要明确地显示用户可选择的选项。

艾伦·库帕的《交互设计精髓》有一章中准确章节很好地阐述了心理模型。罗伯特·霍克曼在《一目了然》一书中也曾讨论过心理模型。乔尔·斯波尔斯基的《程序员的用户界面设计指南》从开发者的角度阐述了心理模型。

10.6 实体模型

线框图(Wireframe) 用户界面的一种静态表现形式,界面的各个元素都以设计尺寸显示在大致的位置

实体模型(Mock-up) 用户界面的一种表现形式(通常是静态的),其中加入了诸如阴影和颜色之类的修饰元素

原型(Prototype) 最终产品之前的所有产品的表现形式

10.7 工具

草绘和原型制作是软件开发团体中最常见的活动,以至于催生出了一个完整的产品开发生态系统。这个系统中的应用程序和服务存在的唯一价值就是帮助你绘制草图或创建产品原型。

Balsamiq和Mockingbird是两个在线工具,你可以用它们来创建并分享自己绘制的用户界面草图。

在Mac平台上,OmniGraffle可以满足绘制用户界面草图的许多需求。人们已经专门为OmniGraffle创建了一些用户界面模板。如果你是个iPhone开发者,还可以关注一下Briefs和Review。

一些人也用PowerPoint或Keynote之类的工具来创建实体模型和产品原型。这些工具甚至可以制作简单的动画和交互效果。Keynotopia和Keynote Kungfu类的网站为这些软件提供了用户界面模板,能帮助你利用平台上的标准用户界面元素创建出无可挑剔的产品实体模型。

使用你感到最容易的工具。如果你擅长在纸上画草图,那么就用在纸上绘制草图;如果你更倾向于使用专门为用户界面设计师创建的软件,那么就用软件;如果你想用一款图像处理软件,那也无妨;或者,根据你当前要完成的任务结合使用所有这些工具。

首先创建产品的粗略图,然后逐步添加细节。先绘制流程图,再是故事板,然后是简单的草图,接下来是线框图,最终制作详细的实体模型。尽早解决问题。你越早发现设计中的问题,处理起来所要付出的代价就越小。

流程图可以帮助你让用户以尽可能简单的方式实现他们的目标。故事板可以帮助你为产品加入交互设计的细节,并就其进行沟通交流。简单的草图能帮助你想出各个屏内所要显示的内容。线框图可以帮助你决定在各个屏内的什么位置布局设计元素。实体模型能让你进行快速的视觉设计迭代。

流程图、故事板、线框图和实体模型是我最常用的四项技术,它们可以帮助我从产品的粗略图开始,逐步进入细节设计。然而,有些设计师家更偏向于使用其他技术。肯尼德·鲍尔斯和詹姆斯·鲍克斯的著作《潜移默化:用户体验设计行动指南》中有相关论述,该书还介绍了一些其他技术。

比尔·巴克斯顿的《用户体验草图设计:正确地设计,设计得正确》(Sketching User Experiences)也是这方面非常好的书籍。罗伯特·霍克曼在《一目了然:Web和移动应用设计通识方法》中也谈到了这些技术。

第11章 纸质原型测试

草绘图是产品最基本、最原始的形态——原型(如果你喜欢这样称呼的话)。因此,你可以用它来进行可用性测试,看看设计方案是否像你设想的那样有效。最简单的办法就是把产品原型拿给用户,看看他们是否理解这些原型。

11.2 完整的可用性测试

如果想知道如何改进草图和实体模型,就要找真人进行测试。测试没有必要很复杂。向参与测试的人展示草图,然后问一些简单的问题。在更广泛的测试中,针对产品的关键部分定义测试任务。至少准备五六项任务,每一项任务的执行时间为二至十分钟。不能指定任务的完成方式。把各项任务分别打印出来。

招募三到五个测试者,分别为每个人规划两小时的测试任务。你可以自己执行整个测试,但最好还是由你来模拟“电脑”,再找一个人作为协助者。准备测试者在完成任务的过程中可能用到的所有屏幕显示内容,这些内容不能太粗糙,确保不熟悉产品的人也能读得懂。在需要的时候,添加一些运行环境的用户界面元素(比如网站草图周围的浏览器窗口)。制作可能会用到的弹出元素。

对每一项任务进行测试,确保已经准备好了所有可能用到的屏幕显示内容和弹出元素。在测试开始时,向测试者解释整个测试流程。强调你所测试的是设计方案,不是测试者本人。

将所有要介绍的内容列一个清单,在介绍的过程中核对这些内容。不要忘了让测试者签署同意录像的表格。向测试者解释如何与“电脑”交互。允许测试者在原型上写写画画。在测试过程中,不要影响测试者,不要让测试者感到不安。在测试者变得沮丧时介入其中。完成测试后,做个简短的总结,感谢测试者的帮助。

卡洛琳·施耐德曾写过一本关于纸质原型的权威著作——《纸质原型:快捷简便地定义和完善用户界面》。如果真的对纸质原型感兴趣,你应该读一下这本书。

12.2 实物的虚拟版本

在设计师谈论写实风格的用户界面时,他们有时会将这种界面称为skeuomorph——只保留原始物体纯粹装饰性细节的新物体。例如,某些鞋的组成部分是粘在一起的,但仍然用线缝了一下,这些线没有实际功能,纯粹为了装饰。

12.3 模拟自然约束

找到现实世界的复制品和产品可用性之间的平衡点非常重要。实物通常有其特定的运作方式,并有其道理,我们应该保留这些方式。但大多数时候,实物以其特定方式运行是因为受到物理、技术、经济或实际用途等方面的限制,没有更多选择。

  • 为设计方案添加写实细节,这样可以向用户传达可行的操作方式或功能可见性。
  • 图标的设计不能太过写实,否则会失去其意义。
  • 复制真实物体能帮助用户迅速形成正确的心理模型。
  • 基于真实物体的写实风格图形和交互设计应该齐头并进。
  • 某些时候,你不必复制真实物体的约束条件,因为屏幕上的物体根本不受自然法则的约束。
  • 可以将现实世界的产品不具备的高级功能与有助于用户使用的写实元素相结合,但你要让写实的程度显而易见,这样用户才能形成正确的心理模型。

斯科特·迈克劳德的《理解漫画》深入剖析了人们如何“阅读”图像。如果你想学习更多的图标设计知识,我向你推荐艾德里·安弗鲁泰格的《标志和符号的设计及含义》(Signs and Symbols:Their Design and Meaning)。麦克斯·斯滕贝亨在其文章《UI设计中的赏心悦目和简单实用》(Eye Candy vs.Bare-Bones in UI Design)中谈到了界面设计的吸引性与功能性之间的权衡关系。

第13章 自然用户界面

自然用户界面(natural user interface,NUI)是指那些摒弃传统GUI界面的设计原则,支持基于自然世界创建交互设计的人机界面。自然用户界面中没有窗口、按钮和菜单,而是基于真实的物体和手势实现交互过程。它不再需要鼠标和键盘,而是依赖于多点触摸屏、摄像头、麦克风、笔和其他支持人类通过手和手指、声音或身体的移动直接与界面进行交互的设备。

13.1 避免使用魔法手势

如果选择使用手势实现交互,就一定要确保它能以来自于真实世界、用户能够理解的方式直接、立即作用到屏幕上显示的物体。当用户与系统进行交互时,只有系统立即给予反馈,基于手势的交互方式才会起到非常好的效果。在《设计手势界面》(Designing Gestural Interfaces)中,丹·塞弗指出:我们已经习惯了在操纵实际物体时收到即时的反馈。(……)在与手势界面进行交互时,用户想要知道系统是否已经听到并理解了给予它的所有命令,这就需要反馈机制。对于人类直接对手势界面做出的每一个动作,无论多么轻,系统都要给出一些反馈,无论在任何时候,都要尽可能地快。

13.2 手势的识别

没有重要线索表明手势是人机交互设计成功的必要条件。因为操作手势的延续时间非常短暂,也没有任何路径记录。这意味着,如果某人执行了一个操作手势,无论是设备没有反应还是出现了错误反应,几乎都没有有效的信息能帮助用户理解为什么出现了这样的状况。此类问题的解决方法有时是不明确的,但通常都归结为要让用户知道电脑何时已经识别了操作行为。

创建一个简单的手势用户界面也并非易事,但一些指导原则或许会对你有所帮助。立即给出反馈信息,告诉用户系统何时识别了操作手势;如果还没有识别,为什么。简单、能容错的手势最有效。最好采用直线路径的操作,简短的操作手势优于冗长的操作。如果用户需要在某个特定的区域开始或结束操作,把这一区域设定得更大一些。向用户提供简单的方法来撤销操作,以防电脑没有正确识别某个操作手势。

13.3 偶发性输入

在设计自然用户界面时,重要的一点的是你应该花些时间考虑一下:如何才能避免偶发性的输入;当出现问题时,如何告诉用户问题出在哪里;即便用户没有立刻发现错误,该如何让用户撤销那些无意的操作。

13.4 惯例

假如你想给予用户安全感,让他们自由地探索你的应用程序,就得为用户提供简便的方法来撤销他们的操作。

如果可能,复制现实世界中的行为。让电脑以用户能够识别、能够理解的方式立即做出响应。这样,用户就可以把现实世界的知识应用到虚拟系统之中。参考流行应用程序的做法。有可能你的用户见过这些应用程序,并且也已经熟悉了它们的交互方式。制作出不同设计想法的交互原型,然后进行可用性测试,看看人们对它们的反应。

  • 尽可能允许用户直接操纵产品。
  • 对所有的用户操作给出即时、生动的反馈信息。
  • 把那些并不操纵对象,而是激发命令的用户手势仅仅作为快捷方式,而非主要的交互方式。
  • 确保用户不需要学习复杂的手势。
  • 确保用户不需要做出精确的手势,给予用户输入的自由,但要允许他们撤销错误的输入。
  • 运行自然用户界面的硬件特别容易把用户的无意操作理解为信息输入。尽可能阻止偶发性输入;如果发生了偶发性输入,提供应变方案。
  • 道法自然。
  • 参考流行软件的做法。
  • 定期让实际用户对用户界面的交互原型进行测试。

丹·塞弗的《设计手势界面》中也涵盖了本章的部分内容和很多其他话题。乔希·克拉克在他的杰出著作Tapworthy中谈到了手势(和很多其他内容)。

第14章 菲茨定律

在可用性方面,只有少数人们广为接纳的法则。菲茨定律(Fitts’s law)就是其中之一,它描述道:(在桌面系统中)用户能快速点击到那些较大或比较接近于鼠标指针的目标。此类目标可能是用户想用鼠标点击的屏幕上显示的图标,或者是用户想要敲击的触摸屏上的按钮。

动作的方向也是影响因素之一。目标的形状应该与动作方向一致

由于难度系数ID是通过对数计算的,因此,如果目标初始尺寸较小,很小的变化就能引起任务难度的巨大变化;但对于较大的目标而言,细微的变化产生的影响很小。

14.1 屏幕边缘具有无限大的尺寸

如果细想一下,屏幕边缘处的界面元素的尺寸实际上是无限大的,因为无论你朝着屏幕边缘方向把鼠标移动多远,它永远不会超出屏幕边界,总能停留在此处的点击目标上。因此,把重要的界面元素放在屏幕的边缘处具有一定的道理。点击这些元素更加容易,因为人们只要把鼠标甩到屏幕的边缘,它就会自动停在要点击的目标上。

在大部分情况下,类似的做法并不适用于触摸屏,触摸屏幕边缘处的界面元素并不比触摸其他地方的元素更容易。用户最容易达到的区域取决于持握设备的方式。

当然,在用户拖拽界面元素时,触摸屏的边缘就是一个非常好的目的地了,因为不可能把某个东西拖到屏幕之外的区域。

14.2 放射式环境菜单会减小平均移动距离

如前所述,屏幕的角落位置很容易点击,因为那里有两条边界。但还有一处更容易点击:指针所处的位置。你完全不必移动指针就可以点中,环境菜单(context menu)就利用了这一点。如果鼠标指针所在位置处有菜单弹出,在指针周围布局各个菜单可以有效减小到达每个选项的平均距离。实现这种效果的做法之一是使用放射式环境菜单(radial context menu)。

“人类对主子午线附近较窄范围内的方向敏感度好于其他区域。”长话短说,研究表明:相对于斜线和圆,人类能迅速且正确地感知水平线和垂直线。

14.3 较小目标需要设置外边界

较小的目标难以点击,因此在较小的目标之间设置边界就显得非常重要。否则,用户很可能会错过正确的目标,从而引发错误操作

14.4 有时,界面元素越小越好

把屏幕显示元素设计得大一些会方便用户点击,而把破坏性操作的界面元素设计得小一些能有效降低用户在无意之中点击到的概率。

  • 如果你想让某些东西很容易点击,就把它们设计得大一些;如果你想让它们不容易被点击到,就把它们设计得小一些。
  • 屏幕边缘处的元素更容易点击,屏幕角落处的元素更是如此。
  • 指针的运动轨迹应该与所要点击的目标形状一致,也就是说,如果用户水平移动鼠标来点击目标,把目标水平放置会让它更容易被点击到。
  • 用户能更快地到达那些接近指针的元素。
  • 在不同的可点击元素间保留一些间距。

对菲茨定律的完美阐述,参见凯文·希尔的文章《菲茨定律可视化》(Visualizing Fitts’s Law)。

第15章 动画

如果使用得当,动画能够帮助用户理解他们的电脑正在发生着什么样的变化。动画还有助于解释屏幕两种不同视觉状态的因果关系,能吸引用户的注意力,让他们注意到那些原本会忽略的东西。动画还能帮助用户形成关于产品工作原理的正确心理模型。

15.3 避免使用不重要的动画

只有当你真正想打断用户,强迫他们关注某些东西,用动画来传递相关信息时,才使用动画,否则就不要用!

15.5 向卡通漫画学习

为了让物体具有实体感,动画中不应该有人类能够觉察到的延迟,界面元素的移动一定要流畅。Pixar的首席创意官约翰·拉塞特(John Lasseter)在他的论文Principles of traditional animation applied to 3D computer animation中提道:随着动作速度的提升,位置间的距离会变大。当距离变得足够大时,两动画帧之间的物体就不会再重叠,人眼也开始能感知到独立的图像。

真实物体不会在动作开始时就具有一定的速度,肯定存在加速阶段。因此,有必要在动画起始处让动作慢一些,然后加速,最后在停止前再让速度逐渐减慢[有时称为缓入(ease-in)、缓出(ease-out)]。这一逻辑同样适用于增长和收缩动画。

  • 用动画把用户的注意力吸引到细微的或不被注意的界面变化上。
  • 通过动画让用户理解大幅度的界面状态变化。
  • 动画,特别是视野边缘处的动画具有极大的吸引力。不要滥用,它会让人崩溃的。
  • 你可以通过动画强化用户正确的产品心理模型。
  • 卡通动画有我们可以借鉴的视觉语言:物体应该具有实体感,通过加速和减速营造真实感,有时应该夸大运动效果。

科林·威尔的《信息可视化》介绍了一些关于动画的信息。张倍伟和大卫·昂加尔在的论文Animation: From Cartoons to the User Interface也介绍了大量类似的信息。马库斯·韦伯在他的博客中谈到了在用户界面设计中使用动画的事宜。凯斯·朗撰写了关于在用户界面中使用动画的文章。麦克斯·斯滕贝亨在他的博客中也谈到了这个问题。最后,约翰·拉塞特的论文Principles of traditional animation applied to 3D computer animation里包含有一些关于如何使用动画的极为重要的内容。

16.2 行为一致性

人们擅长于识别用户界面元素,所以界面元素没有必要都一模一样。同类界面元素一定要有相似的外观,相同的行为方式,因为人们会尝试把已有的心理模型应用于相似的界面元素。如果你必须创建出与常用界面元素行为不一样的设计,一定要确保视觉上存在差异,这样人们才不会形成错误的预期。你一定不想用一个与常见、相似的用户界面元素不一致的方案来让用户在使用时沮丧不已吧。

在37signals的《把握现实》一书中,作者用精炼的语言描述道:“如果界面的不一致能让你的设计更有价值,那么打破一致性是OK的。”乔尔·斯波斯基在《程序员用户界面设计》中谈到了一致性问题。

第17章 可发现性

设计师所说的“可发现性”(Discoverability)是指用户是否能发现并使用产品的某些功能。可发现性非常重要,对于用户来说,产品中那些无从发现或无法使用的功能形同虚设,毫无意义。

17.1 哪些功能要易于发现

让我重申一下要点,如果存在以下情况,你可以让某个常用的功能不那么容易被发现。

  • 虽然人们不知道该功能的存在,但这毫无影响。
  • 虽然该功能没有直接显现在用户面前,但用户自己能找出它。
  • 该功能十分诱人、简单且经常被使用,人们知道了之后就会记住它。

17.3 如何让用户发现

你可以利用诸如大小、位置、形状和颜色之类的属性,让程序中的某些元素更容易(或更不容易)被发现。尺寸越大,就越容易被发现。把某些东西放在屏幕或窗口的左上角或左下角更容易被发现。某些颜色(大部分明显的红色)能让事物显得更加重要。如果你认为某些东西稍微不那么重要,但仍然要让用户能够发现,你可以用相反的手法让它变得不那么明显。

如果用户不能很快找到某些东西,他们可能会求助于产品的搜索功能,只要他们能找到这个功能。为了帮助用户使用搜索功能,你需要做到以下三件事。

  • 提供搜索功能。
  • 保证用户能很容易地找到搜索功能。
  • 确保搜索功能可以返回有用的结果。

通常,最后一点是最难做到的。

动画是吸引用户注意力最强大的工具。一定要巧妙、谨慎地使用它,对那些长时间显示的内容坚决不要使用动画。

首先决定哪些内容应该让用户易于发现,哪些内容需要被隐藏在某些地方。然后为前者分配重要程度,并根据重要程度进行设计。谨记,并不是产品的所有功能在同一时间内都可用。不同的内容需要在不同的时间被用户发现。使用视觉布局、出色的搜索功能和动画(在少数情况下)来确保内容易于发现。

第18章 不要打扰用户

打扰用户的代价是非常高的。用户不仅要花时间来处理自己所受到的影响,还要花时间回到自己受打扰之前的状态——如果可能回去的话。微软最近的研究表明,微软员工在受到新邮件或即时信息的打扰后,平均需要花费15分钟才能回到受打扰之前的状态,继续执行任务。人们很容易走神,且常常要花费较长的时间才能从走神的状态下恢复。因此,打扰用户会浪费他们的时间。用户也会很生气,甚至有时会因此变得粗鲁。毕竟,干扰是外界影响因素,它会打扰到用户,使他们停止当前正在进行的工作。在任何可能的情况下都不要打扰用户,以下是做到这一点的方法。

18.1 帮助用户作决定

如果你可以帮助用户做出某个决定,那就去做吧。不要仅仅为了让用户确认某个操作而打扰用户。

18.2 提前作决定

某些情况下,你不得不让用户自己来作决定。此时,最好让用户提前一次做完所有的决定,然后不再被打扰。例如,你最好让用户在开始安装软件时就输入软件的许可证信息,而不是在安装过程中间停下,让用户来输入软件许可数据。

18.3 只在做出紧急决定时才打扰用户

永远不要仅仅为了告知用户发生了某些事情而打扰用户

  • 不要打扰用户。打扰用户会让他们不高兴,降低其工作效率,这本身也是不礼貌的行为。
  • 帮助用户作决定,而不是向他们提问题。
  • 如果不能帮助用户作决定,一次问完所有需要的问题,而不是每次遇到新问题时都打扰用户。
  • 如果你必须告诉用户某些事情,保证尽量不打扰用户,这样他们才能按照自己的时间安排来处理这些事情。

米哈里·契克森米哈赖的著作《幸福的真意》解释了人们在关注于某项任务时不受打扰的重要性。

19.1 允许用户撤销自己的行为

“撤销”操作不用强迫用户处理不断出现的警告,而是提供了一种简单易懂的解决方法。除非用户偶然做出了某些自己不想做出的操作,否则,撤销是不可见的。一旦发生意外,用户可以很容易地返回到之前的状态。

关键在于,人们要能够信任“撤销”的作用。这意味着,你必须记录尽可能多的操作行为,提供多层次、“有一定深度”的撤销操作,能够允许用户撤销更多操作,而不仅仅是最近执行的。如果“撤销”操作不能提供可靠的结果,或返回以前状态的程度不够,你的应用程序将失去用户的信任。用户会犹豫是否要去探索产品的新功能,在使用已知功能时也会畏首畏尾,最终会在使用程序时变得不高兴。

19.2 临时撤销

  • 在用户做出某些具有潜在危险的事情之前提出警告并不会奏效,因为用户会忽略这些警告信息。
  • 允许用户撤销他们的操作,这样才能避免发生意外。
  • 如果技术不支持“撤销”操作,至少要延迟具有潜在危险的操作,这样即便用户发出了命令,也仍然能够阻止事故的发生。

20.1 隐性模式

如果人们不知道自己处于何种模式,也就是说,如果模式是隐性的,那么模式就会令人迷惑。例如,Caps Lock键开启时一个小灯会亮,但这很容易被用户忽略。

20.4 模式并非一无是处

模式会引发许多问题,难怪它会臭名昭著。但实际上,它本不应落得如此下场。把用户界面设计得完全非模式化会增加其复杂性。在需要的时候,模式可以用来表明产品的功能,而非模式化的界面在任何时候都必须提供大量可能的用户操作。

只有那些隐性的、意外的、难以退出的模式才是不好的设计。如果用户是有意转换界面的模式,并且模式在处于激活状态时是明显易见,同时可以让用户时刻知道该如何退出某一模式,那么在界面设计中使用模式并没有任何过错。

记住这些基本原则,模式才能改进用户界面,而不是让界面更具迷惑性。

20.5 准模式

  • 如果设计不当,模式会使用户迷惑不解。
  • 模式非常有用,它能避免让产品充满用户界面元素。
  • 为了让模式良好地发挥作用,它应该是显性的、可预期的、能够轻易退出的。
  • 在可能的时候使用准模式,而不是完整模式。

很多用户界面设计相关的书中都会提到模式。例如,《交互设计精髓》就在多处提到过模式。杰夫·拉斯金的《人本界面》中有一章介绍模式。

第21章 用你的观点代替偏好设定

如果你不确定该选哪个设计方案,最好让用户来做决定。对于Mac窗口缩小到Dock这一过程,某些人想让窗口优雅地飘进去,而其他人则更喜欢让窗口只是快速地线性缩小。为什么不同时实现这两种效果呢?

21.1 为什么偏好设定不好

偏好设定会以各种方式为你的产品带来完全没有必要的复杂性。首先,人们会进入到产品的设定界面,寻找他们需要更改的东西,任何你提供的不必要的选项都会让他们更难找到自己想要找的东西。他们不得不一一浏览每一个偏好设定,这让所要找的目标更加难以发现,也会让整个寻找过程更加令人沮丧。

21.2 如何避免偏好设定

对用户说“不”(参见第24章)。有些人真的很喜欢较小的字,他们甚至会给你发邮件,要求改变文字的大小。但这并不意味着为产品增加调整字体大小的偏好设定是最好的选择。你可能会讨好某些用户,但却会让其他所有人都感到不方便,你还必须为此让窗口支持各种大小的字体。

对自己说“不”。偏好设定听上去可能是个不错的选择,通常这是最快捷的方法。为某些东西进行偏好设定,你就不必亲自做选择了,但这对用户来说却是在帮倒忙。

与同类产品保持一致。如果你无法在两个选项中做出抉择,而用户可能使用过类似的产品,那么请参考这些产品,这样用户就能把自己已有的知识应用于你的产品。

进行可用性测试。如果某个问题有两个解决方案,你不知道该选哪一个,那么创建纸质原型,对这两个方案进行测试(参见第11章)。或者同时采用这两个方案,然后执行A/B测试(参见第33章)。从这些测试中得到的反馈和数据甚至能帮助你找出新的、比你最初的想法更好的方案。

持有主见。如果你面前有两条路可以走,那么选择你更喜欢的那条路吧。你更喜欢用哪个方案?自己持有主见是不错的。如果你想要讨好所有人,那么将会没有一个人感到高兴。

给出隐性的偏好设定。不要让用户专门设定产品行为,而是要记住用户上一次的操作;不要让用户设定窗口的默认尺寸,而是使用用户上一次缩放后的尺寸作为默认窗口尺寸;不要让用户在文件共享程序中设定自己喜欢的通信协议,而是把他们上次使用的协议作为默认设定,在需要的时候允许他们进行更改;在用户打开某个程序时,不要让他们设定自己想要看到“新建文档”或“打开文档”之类的对话框,而是再次打开他们上一次用这个程序打开的文件。

21.3 如果无法避免偏好设定

如果你真的无法避免偏好设定,一定要确保大部分用户认可每个偏好设定的默认选择。大部分人都会使用默认值,从不进行更改。

很多以前的研究,包括我自己的研究都表明,搜索结果中少数前几项的点击率占比最高。其中,第一项的点击率极大地超过了其他几项。(……)在用户界面设计中的很多地方,用户都依赖默认设定。例如,他们很少会使用能实现华丽效果的功能,因此一定要重点优化默认的用户体验,因为这是大部分用户的选择。

产品的设定可分为配置(产品正常工作所需的设定)、个性化设定(纯粹的视觉变化,并不是必需的设定,但它能让用户感觉到产品是属于他的)和偏好设定(功能性的改变,并不影响产品的正常工作)。 避免使用偏好设定,因为它会引入不必要的模式。不要支持偏好设定,而是实现最恰当的默认产品行为。

第22章 层级结构、空间、时间以及我们对世界的看法

如果以明显的、常规的层级结构组织事物,人们通常就能够理解并利用这种层级结构。如果要求人们对任意事物创建并维持层级结构,那就会出现问题。

22.2 空间

一定要记住,现实世界中的东西不会自己移动。在空间系统中,人们期望在自己设定的位置找到某个东西。一定不能背着用户改变某些东西的位置。

当用户对大量内容进行管理时,空间系统显得有些乏力。为数十项或数百项内容创建空间布局,并跟踪其每一项的位置是比较容易实现的。但如果有上千项内容,就很难做到这一点。当系统要处理成千上万的数据时,几乎无法用空间结构来对其进行管理。

22.4 更好的层级结构

如果只给用户一截绳头,他们很难用它把自己吊死。如果只能让用户创建较浅的层级结构,他们不太可能会迷失其中。照片分享网站Picasa就是这样的一个系统,它允许用户把自己的照片整理到影集中,但不能把一个影集放到另一个影集中。一个影集只能存放很多照片,别无他用。这样,用户就不太可能会丢失自己的影集,因为他们根本就不能把某个影集放到另一个影集中。

仅允许用户把项目组织成层级结构还不够。层级结构通常只能表达项目某个方面的性质。例如,对动物进行层级结构分类使用了常见的降级原则。如果你对各个生物种类之间的关系非常有兴趣,这样的分类方法会很有用。但如果要编写一个对人类有毒的动物列表,或是所有水生动物的列表,这样的分类就不能起到太大的作用。允许用户在层级结构中对各个项目的元数据进行操作,这样他们就可以组织管理那些无法通过层级结构表达的数据。

即便主要用层级结构组织内容,你也要允许用户以非层级结构的方式访问数据。比如,允许用户搜索数据。同样,如果需要追踪各个内容项的变化,应允许用户以时态视图访问层级化结构的数据。你要考虑一下用户可能会用何种方式搜索或浏览数据。

有时,层级结构很有效,但结构一定要清晰,能被大众用户所接受。如果每个人都要自己设定层级结构,那么它的作用会降低,尤其是多个人共用一个层级结构时。人类非常擅长于处理时间和空间信息。试着利用这两个因素,而不仅仅是层级结构来组织用户数据。如果必须使用层级结构,应尽可能使用浅显的结构,允许同一项目出现在多个地方,支持对元数据的操作,允许用户以其他方式访问数据。

第23章 速度

速度比功能更重要。速度本身就是最重要的一项功能。如果你的应用程序慢慢吞吞,人们不会使用它。这种现象在主流用户中比在有较强能力的用户中更为常见。我认为有较强能力的用户有时会用同情的眼光看待创建快速网络应用程序所要面临的挑战,他们或许能忍受产品缓慢的反应速度。

23.1 响应度

我们首先要关注的是,产品如何响应用户。很多研究在这方面都得出一致结论。如果某一项操作能在0.1秒内完成,用户就认为它是瞬间完成的。如果完成时间多于0.1秒,少于1秒,用户不再认为操作是在瞬间完成的,但并不会忘记当前正在发生着什么样的事情。如果某一操作的完成时间超过1秒,用户很有可能会在等待的时间内走神。在可能的情况下,最好还是保证操作能在0.1秒内完成。

23.2 进度反馈

如果某个操作的完成时间超过了0.1秒,你就要提供一些反馈信息。该提供什么样的反馈取决于两点:目前进行的是什么类型的操作?要持续多长时间?如果操作只需要1秒或2秒就能完成,把光标变成沙漏状,或添加一个小小的指示器,表明“我正在处理”就行了,这类做法不会明确告诉用户操作的处理进度。此时,我们的目的不是告诉用户操作要持续多长时间,而是要明确地告知用户,电脑已经接收到了他们发出的命令,正在进行处理。一定要“明确地告知”,这一点非常重要。

如果某项任务持续时间较长,用户很有可能会把关注焦点转移到其他地方,最后甚至可能会完全忘记电脑正在执行任务。你可以用声音反馈向用户暗示任务已经完成,这样,即便用户走神,也能得知这一情况。

23.3 对速度的感知

速度本身就是用户的一种感知。用户不会用秒表来测量产品的反应时间,重要的不是操作需要持续几秒或几毫秒才能完成,而是用户对产品速度的感知。改进速度感知的一种方法是先尽快显示部分结果。如果你正在为搜索系统设计用户界面,不要等到搜索完成时才向用户显示结果,只要找到了结果就马上显示出来。

另一种方法是确保持续时间较长的操作不会卡住产品的用户界面。如果用户可以在此过程中做其他事情,而不是傻等着操作完成,他们可能不会注意到操作持续了很长时间。最后一种方法是在进度条上显示一些与进度成反方向运动的条纹,如下页图所示,这样会让进度看上去更快一些。

23.4 慢一点

缓慢的产品惹人讨厌,但是,非常快的产品也一样。某些时候,你的产品可能太快了。滚动操作就是个典型的例子,如果程序滚屏太快,用户会错过要找的目标。刻意让产品慢一些通常具有一定的意义,这样用户才能跟上节奏。

  • 反应度和速度是产品非常重要的特征。可用性测试通常无法暴露出这两方面的问题。
  • 为了让用户感觉操作是在瞬间内完成的,时间不能超过0.1秒。
  • 对于超过1秒的操作,需要在用户的视觉焦点处显示一些指示,表明程序正在工作。
  • 用户所感知的速度比产品的实际速度更为重要。有时候可以通过一些技巧让用户感觉产品更快一些。
  • 产品的某些东西可能太快了。某些时候,人为降低产品某些功能的执行速度能改进用户体验。

布鲁斯·托格纳兹尼在他撰写的《交互设计的基本原理》(First Principles of Interaction Design)谈到了产品的延迟问题。

第24章 避免不断加入新功能

产品设计是一场没有终点的比赛。为了避免被其他竞争者取代,你要永不停歇地奔跑——或者,对我们来说就是:设计,设计,再设计。这场竞赛没有明显的终点,产品永远不可能做到完美无瑕。大多数情况下,我们最大的期待也只是,产品在每一次发布新版本的时候能更接近于完美一些。

24.1 谨记用户的目标

考虑一下,用户想用你的产品完成什么样的目标?新功能是否能提供更好的结果?是否能让用户实现新的目标?是否能让产品更加易用?正如凯斯·塞拉说的那样:“人们并不关心你提供什么样的工具,只关心工具能做什么。”

24.3 提升已有功能的可用性

如果大量新要求都能通过产品当前的功能集满足,那么你应该花些时间改进产品已有的功能,而不是创建新功能。同样,如果没有人能理解或使用产品的某项功能,你最好研究一下该如何改进这项功能。

实际上,你的目标不是增加全新的功能,而是让已有功能更加可用。这样做实际上是把产品变得更加简单,而不是更加复杂。同时,这样做也等同于为所有不知道产品存在这项功能或是不知道如何使用这项功能的人提供了新功能。

24.4 一举多得

不要单独地加入新功能,把相似(或者看上去毫无关系的)功能当作一类问题来解决更有意义。

24.6 隐形的功能

如果能在增加一项有用的功能的同时不加重用户的“认知负担”,那最好不过了。隐形的功能是最佳选择,因为它们可以让产品变得更优秀,但却不增加其复杂性。你是否能改进文本渲染功能,让产品创建的文档看上去比竞争对手的产品创建的文档更好看?如果为网络应用程序增加支持HTTPS访问的功能,是否能直接把用户转到HTTPS访问并保证数据更加安全,而不让用户手动启用新功能?这些功能都能让你的产品更加出色,但用户根本不需要知道它们的存在。

24.7 提供API和插件架构

没有必要自己实施所有的功能。通常,你可以让其他人介入进来提供帮助。例如,Twitter在开始的时候只提供了极其简单的服务,但它的API可以让其他开发者介入进来,围绕Twitter创建完整的软件产品生态系统。Photoshop是另一个典型的例子。虽然Adobe已经在Photoshop中添加了无数功能,几乎没有什么可添加的其他功能了,但Adobe仍然允许第三方开发者为其创建插件,这样可以不花自己一分钱,就能拓宽产品的市场,也没有让Photoshop变得更加复杂。通过增加API和插件架构,你就可以避免实施那些仅对部分用户有用的功能了,而将这一工作留给其他开发者。当然,你也可以用插件架构自己创建新功能。

24.8 倾听用户的心声

一定要记住,你并不是产品的用户。最多你也只是其中一个用户,是所有用户的少数典型个例。你可能认为某个新功能非常有用,但大部分用户却持反对意见。这种情况有时被称为“内部用户问题”:设计和实施解决方案的人把类似自己的人而不是产品的实际用户作为目标用户。

24.10 不必让所有人都成为用户

最后一定要记住,你的产品不可能占有100%的市场。为产品加入更多功能确实能够笼络更多的用户,但这样也会增加开发成本。如果没有提供那些具体的功能,产品对那些不具备使用能力的人将具有更大的吸引力。但是,这样做也会让产品对那些将会用到这项特定功能的人的吸引力降低。让某些人转向你的竞争者,让竞争产品满足他们的需求吧!你的产品不可能是万能的。

  • 增加更多的功能可以让产品对那些需要这些功能的人更具吸引力,但却会让那些不使用这些功能的人对产品更没兴趣。通常,对于任何既定的功能,第二种人更多一些。
  • 用“五个为什么”来评估用户的反馈,找到问题的根源。
  • 不要增加新功能,而是改进现有功能。
  • 添加那些能解决数个问题、能取代现有功能的功能。
  • 统筹考虑实现一项新功能所需的成本和该功能所能带来的益处。
  • 着重关注那些能提升产品质量却不增加用户界面复杂度的功能。
  • 提供API和插件架构。把一些专用功能做成插件,或者留给第三方开发者。
  • 在加入新功能之前进行适当的用户研究,找出用户真正想要的功能以及使用该功能的目的。
  • 如果你满足了所有“我只需要这一个功能”之类的请求,最终的产品会充斥着大量不常用的功能。
  • 不可能让所有人都成为你的用户,请接受这一现实。

25.1 研究

  • 较低的使用率并不一定说明你应该去掉某项功能。例如,备份程序的大部分用户就很少使用恢复功能。很明显,这并不表明你可以去掉这项功能。
  • 使用率低只是产品可能存在问题的指标之一。使用调查数据可以帮你得出结论,但你要根据设计知识和经验决定要去掉哪一项功能,改进哪一项功能,保留哪一项功能。

25.2 告知用户

不要让用户“投票”决定该去掉哪项功能(投票结果完全无法解释为什么用户会这样选择,而且如果你决定无视投票结果,无异于鼓励用户“造反”),但一定要考虑他们的观点和所反馈的信息。正是这些人使用你的产品,因此,他们能提出关于产品使用的有效见解,而这些见解是你可能会忽略的。

25.3 提供备选方案

或许只有一部分用户会使用某项特殊的功能,但他们确实非常需要这项功能。因此,提供一些备选方案是比较好的做法。其他人创建的产品或许可以替代你去掉的那些功能,你可以联系这些人,为用户争取一些使用他们产品的折扣。

25.4 开发产品的人是你

一定要记住,对产品负责的人是你自己,这非常重要。如果你的产品不再适用于用户,他们可以转向其他产品,而你却不能这样做。用户不知道某项功能的受欢迎程度,但你了解这一点。用户不知道维持某项功能,为其提供支持的成本是多少,但你很清楚。受制于产品的人是你,因此要确保它仍然是你值得付出、引以为傲的东西。

  • 有时候,你应该去掉产品某些已有的功能。这从来都不是一个轻松的决定。
  • 收集使用数据,找出用户使用产品的方式。
  • 如果决定要去掉某项功能,在执行决策之前从用户处取得一些反馈信息。
  • 提供一些备选方案。

26.1 乐趣是什么

让我们快速重复一下要点。当人们经历到以下三种情况时会体验到乐趣。

  • 面临富有意义的挑战或任务。
  • 有一种方法来衡量自己是否更接近于完成挑战。
  • 拥有克服挑战的能力。

作为真正的挑战,任务不能让用户感觉太简单,那样会让他们觉得很无聊;同时,任务也不能太难,否则用户会感到很沮丧。只有当技能水平和挑战相匹配的时候,人们才能体验到乐趣。

26.3 我们能从游戏中学到什么

度量某件事情的进度并提供反馈信息,能让一项活动更加有趣。

游戏设计中的技能成长或学习系统是另一个可用于产品设计的元素。游戏会随着玩家技能的成长变得更难。如果能做到的话,产品的用户会向更难的问题发出挑战。把用户保持在“流畅区域”之内,挑战的难度应该与用户的技能相匹配,产品需要随着用户技能的成长而成长。

图像编辑软件Pixelmator就是个很好的例子(见下页图)。最初,它的界面看上去很简单。但随着自身技能的成长,用户会发现并学习到那些最初没有注意到的新东西。

为了让用户提升技能,产品要有一定的深度。既要便于新用户学习,但还要为高级用户提供高级功能,让他们进行探索。托马斯·W.马龙建议把这一过程明确设计成产品的一部分:

例如,我们可以对多层文本编辑器进行设计,让初级用户只需要知道少数简单的命令就可以使用,高级的用户则可以使用那些更复杂、更强大的功能。关键在于,多层系统不仅有助于解决简单易用和强大功能之间的权衡关系,还能改进使用系统所要面临的挑战。用户能够从陆续掌握更多的高级技能中获得自信与乐趣,如果把层设计成系统的一部分,用户就能更频繁地获得这种乐趣。

26.4 趣味性与可用性

  • 仅仅拥有可用性并不能保证产品使用的趣味性。但是,如果产品不具备可用性,就无法带来趣味性。
  • 如果拥有一个有意义的挑战目标、一种衡量这一目标完成程度的方法、克服这一挑战的技能,人们就会体验到乐趣。
  • 不要提供挑战,用户会自行寻找挑战。
  • 你不一定要设定难度。用户会自己寻找适合的难度来挑战自己。
  • 为用户进度提供反馈,并允许用户随着克服挑战而成长,这能为用户带来更多的乐趣。
  • 找到一种方法,奖励用户对产品的探索和正确的操作行为。

米哈里·契克森米哈赖的《幸福的真意》和拉尔夫·考斯特的《游戏设计快乐之道》都深入介绍了什么样的东西能带来乐趣。凯特·萨兰和埃里克·兹莫曼合著的《游戏规则:游戏设计基础》以及托马斯·W.马龙的论文Heuristics for Designing Enjoyable User Interfaces也值得一读。

27.6 测试结果

可用性测试可以非常简单,但一样能产生有用的、可行的结果。如果要对用户界面的变更进行测试,你可以执行非正式的、游击队式的可用性测试。

测试的准备工作包括:把产品安装到便携设备上,保证产品可以运行,设计出一些简单的测试方案。到附近的咖啡馆找一些人,或者在你所工作的办公大楼里找那些有空闲时间的人,询问他们是否愿意花5分钟帮助你进行测试。

如果找到了测试者,向他解释测试过程和产品的前期知识,并给他一项简单的任务。不要打扰测试者,除非你觉得测试者正变得沮丧或卡住了。做测试记录。在进行数次测试之后,你会找出用户界面仍然存在的问题。修正这些问题,再次进行测试。

28.2 测试频率

可用性测试就像慢跑:你做得越多,事情就越容易,你也就越擅长做此类事情。专家们通常建议每个月花几天时间来执行测试,但专门划出几天时间来执行可用性测试很难。另外,如果每个月只执行一次测试,你不可能会熟悉它的。你很难留出时间来执行测试,自己对测试也不熟悉,最终会停止进行测试。因此,我的提议简单得多:每周抽出半天时间来进行测试。

28.8 执行测试

  • 如果想知道某个用户界面是否有效,你需要让实际用户对其进行测试。
  • 可用性测试的成本不一定都很高,也不一定都很耗时。
  • 你需要定期开展测试。测试次数越多,效果越好,迭代周期越短,就越容易测试出用户界面是否有效。
  • 最好经常开展小型测试,而不是偶尔开展很多人参与的测试。每周让一个人(不同的人)执行一次可用性测试,这一点非常容易做到。
  • 让新手用户参与测试,同样也邀请已经知道如何使用产品的人参与测试,因为这两种不同的人很有可能会发现不同的问题。
  • 挑选拥有不同文化背景的人参与测试。同时不要忘记开展可访问性测试。
  • 可用性测试有很多不同的类型,包括有主持的测试和无主持的测试,既可以是基于任务的测试,也可以是自由测试。通常,你需要综合开展不同类型的测试,首先让用户自己对产品进行探索,然后再开展预先定义好的任务测试。

如果正在开展基于任务的测试,你先要准备好测试任务。任务不能有固定的完成方式,描述出任务场景,让用户自己思考解决方案。

第29章 现场测试

  • 每周邀请一个人(不同的人!)执行一次测试。这样很容易安排测试者,也能迅速迭代测试修正问题的过程。
  • 开展本章介绍的某种类型的测试,或者综合开展多种测试。让用户自己摆弄产品通常是个不错的办法,你可以观察他们如何与产品进行交互,然后再开展基于任务的测试。
  • 以乐观的态度对测试做出总结。
  • 用常规方法对测试结果进行评估。找出最紧迫的问题并修正它,然后再次测试。
  • 如果不确定某个问题是否广泛存在于用户之中,不要急着解决它。如果该问题比较严重,它会再次出现于后续执行的测试中。

如果想要了解更多关于现场测试的内容,我建议你读一下史蒂夫·克鲁格的《妙手回春》(Rocket Surgery Made Easy)。

30.2 无主持的远程测试

  • 如果还没有执行任何可用性测试,你首先应该开展几次传统的现场可用性测试。你可以先邀请朋友担当测试者,直到熟悉了测试流程。
  • 只要熟悉了可用性测试的流程,你就可以开始执行远程测试了。
  • 每周至少执行一次远程测试。
  • 除了其他渠道(比如邮件列表、讨论小组甚至是报纸),你也可以利用网站招募测试者。利用网站招募测试者极其方便,也不需要任何费用,但如果只通过这种方式招募,你的测试结果可能会向那些有产品使用经历的人倾斜,因为他们很可能访问过你的网站。
  • 剔除那些纯粹奔着奖品来的测试者。
  • 在联系潜在的测试者时,一定要让他知道你在测试中能看到他的屏幕,并征求他同意对测试进行录像。
  • 在执行远程测试时,你通常无法看到测试者的面部表情和他们所关注的东西。注意测试者变得沮丧或不安的情况,如果发生了此类情况,请停止测试。
  • 在测试的最后,感谢测试者为此付出的时间,向他说明你再也看不到他的屏幕了,并赠送奖品(如果承诺了的话)。用乐观的态度结束测试过程。

内特·宝特和托尼·图拉希缪特的《远程研究》中包含有大量关于远程测试的有用信息。如果打算执行远程测试,你应该看一下这本书。

31.1 不要使用用户界面中的词

在设计测试任务和与测试者交谈时,一定不能使用应用程序中的术语,这一点非常重要。你想要知道的是用户是否能使用产品,而不是他们是否能在用户界面中找到某个特定的词。

第32章 用户错误即是设计错误

因产品的错误而责备用户,根本无益于修正这些错误。如果有上万的用户使用你的产品,其中好几百人,甚至是好几千人都会遇到所有在可用性测试中发现的问题。不要责备用户,你应该修复问题。唐纳德·诺曼在《设计心理学》一书中说道:

不要认为是用户犯了错误,而要把用户的行为当做向目标的靠进。用户没有出错,出错的是你的产品,因为它不能正确地解读用户的操作行为。

32.1 不要在错误信息中责备用户

不要责备用户,我们应该因为问题向用户致歉。这才是良好的可用性,因为它能让用户冷静下来,处理问题。在《你会对你的电脑说谎吗》一书中,作者克里夫特·纳斯谈到了一个实验。在该实验中,电脑在用户玩游戏时提供“情感支持”。他总结道:“主动识别并处理用户的情感状态,能缓解挫败带来的强烈负面情绪和刺激。也就是说,当你告知用户已经听到他们的声音、理解他们的感受并表示同情时,他们会稍微好受一些。”

32.2 没有错误就没有责备

  • 对错误负责。“用户错误”实际上是用户界面设计的失败,是设计师的错误。认为用户应该对错误负责并不能消除问题。
  • 不要在用户界面中责怪用户,否则用户会很难受,而且问题可能是由你的设计引起的。
  • 提供有效的错误信息。如果某些东西出错了,解释出错的原因,但更为重要的是告诉用户该如何解决问题。
  • 避免出现问题。最好完全避免出现错误。如果用户遇到了错误,考虑一下该如何改进产品以避免再次出现错误。
  • 避免使用模式,或清晰地说明产品当前所处的模式,这样能防止模式错误。
  • 清晰地说明希望用户做什么,或者永久性地阻止错误输入,这样能避免输入错误。

33.6 需要记住的要点

  • A/B测试能让你对比多个不同的设计方案,找出最有效的那个。
  • “有效”的定义取决于用户的目标。
  • 收集网站的使用数据很简单,但收集桌面或移动应用程序的使用数据要难一些。记住,要征得用户的同意,并清楚地告诉他们你在做什么。
  • 在基于数据制定决策之前,一定要确保结果具有统计意义。
  • 在对比高度优化的旧有设计方案和新方案时一定要知道,即便新设计方案在直接对比中稍差一些,但如果你能像对旧方案一样倾注同样多的心血,新方案最终会有更好的表现。

34.4 用户行为

  • 一旦用户开始使用你的产品,就要开始估量产品的性能表现。
  • 速度是一项很重要的性能,因为你一般很难知道产品在用户手中的实际性能,直到产品为用户所用。
  • 记录用户退出产品的行为,因为这表明产品存在一些问题。
  • 估量产品的失败表现,如已损坏的链接、空的搜索结果,或是网络冲突之类的现象。
  • 观察用户行为,抓住改进产品的最佳时机,需要增加哪些功能,应该去掉哪些功能。
  • 用户已经开始使用产品,但这并不是设计的终点。现在正是个大好时机,你需要观察用户实际使用产品的行为,并利用相关信息改进产品。

35.2 负面反馈

用户可能会以你预料不到的方式使用产品。这可能是把产品设计导向新方向的大好时机。不要因为负面反馈而心灰意冷。你应该利用这些反馈把愤怒的顾客变成产品的粉丝。