（是的！这只是一个读书摘录，里面没有一句话是我自己的！）

第一部分  研究

第一章  用户研究

问题：如何才能发现人们想要实现的目标？如何帮助用户实现这些目标？

概念：

焦点小组：一种用户研究方法。研究人员把某一品牌的产品，一项服务，一个新设计方案，一台设备或一个相似的产品展示给一群人然后记录下来这些人的主观反应和意见，以此来预测普通公众对产品的反应。

难题：用户也不知道自己想要的真正是什么。

第二章 工作观察和情境访问

概念：

工作观察和情境访问这两种方法用于观察人们的行为，发现他们需要帮助的地方，并查明产品该如何给用户提供帮助。

流程：

观察目标人群

工作观察：直接观察用户的行为，在目标人群使用我们产品的场所内观察用户，目的是为了找出产品应该如何帮助用户实现目标。提出以下问题：用户是否在某项任务上花费了大量时间？用户是否在重复做某件事情？用户是否在用权宜之计完成某件事情？用户在做的某些事情是否很无聊，或者让他感到很厌烦？用户是否被迫记住某项任务的操作步骤，技术事项或其他可以用电脑来完成的事情？用户使用电脑时是否使用其他工具？

情境访谈：工作观察之后，就用户所做的事情询问一些问题。包括以下几个方面：除了我今天看到的之外，你是否还经常要做别的什么任务？你最常解决什么样的问题？你为什么用这种方式做这件事情？如果完成任务还需要一些别的信息你会怎么做？你经常打交道的人都有谁？你们是如何做的？如果你需要的某个人没有上班或者发生了其他问题，你需要做些什么？

远处观察

情境访问的局限性：用户可以想象自己处于某种假想状态。

第三章 用户模型

概念：

用户模型：用户模型是虚构的人，代表了特定的目标用户群体。创建用户模型之前必须进行用户研究。用户模型提供了一种方法，把从用户研究中获取的信息，合成为有限数量的假想人群。

用户模型的优点：

迫使你聚焦产品所要解决的问题。通过创建少量用户模型，你就可以清晰的定义出产品的用户。

使得对用户的讨论更加容易，通过深入考虑目标用户，能帮助你改善设计流程。

用户模型的缺陷：

用户模型的弹性太大。用户模型实际上是假想的人，不能为自己进行辩护。因此它有时会强化预先定下的结论。

用户模型使设计师免于所有艰辛的工作，比如和实际用户接触，测试设计决策的有效性等，从而走向“以人为中心“的反面。

创建用户模型是一件非常耗时的事情。

讨论假想的人会让人感觉不自在。

对于比较小的设计团队来说，用户模型益处不大。

创建用户模型

情境访谈：创建简化的用户模型，覆盖大部分目标用户群体的使用目标。

每个用户模型都必须有明确的目标。为什么这类人会使用你的产品？他们想通过产品实现什么样的目标？

为用户加入一些相关设计细节。如每个用户模型技能水平如何？年龄，性别？是否比其他用户重要一些？是否要首先满足他的目标即使会对其他用户造成负面影响？用户使用什么样的设备？

加入一些设计之外的用户模型的个人信息。

为用户模型设定一副肖像，取个名字。

注意：用户模型无法代替用户研究

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

根据所设计产品的不同，把行动作为设计的焦点可能更有意义。

进行用户研究，找出你所要支撑的用户行为，但不要为了特定人群而制造出使用行为。

严格评估用户反馈。有时，某些因素可能会让产品在某个特定用户群体受欢迎，但也会让其他人不喜欢你的产品。

以行动为中心的设计考虑的是用户行为，针对这些行为设计产品，而不考虑特定的用户或用户模型。它不是让产品去适应用户，而是以用户能够适应的方式设计产品。

第五章 文档编制

概念：

文档编制：使用手册     博文      截屏视频   新闻稿等，在开发之初就制作这些东西，被称作“逆向作业”。

使用手册：编制使用手册可以迫使设计师思考设计的细节，如果某些东西很难解释清楚，那么它可能会很难用需要重新考虑它的设计。把使用手册当成是产品的一部分，像对待产品的其他功能一样对待产品手册。

博文：博文是另一种介绍产品功能的重要工具。帮助人们了解产品，帮助设计师发现产品潜在的问题。你能毫不费力的解释清楚人们关注改功能的原因吗？你能描述出该功能有多简便吗？如果没有，改变设计方案。

截屏视频：可用来介绍新产品或现有产品的新功能。

新闻稿：在发布产品之前就发布新闻，这样能弄清楚公众对产品的态度，而不是我们自己内部的观点。

讨论产品的任务

第六章  文字的可用性

如果可以，不要使用文字

如果无法避免，使用精炼含义明确且可以略读的文字

使用短小精悍的段落，每段文字阐述一个主题

保证文字具有吸引力和个性，而不是枯燥无味或过于专业

用插图阐明要点，让文字更加平易近人

使用大号字和易于辨识的字体

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

考虑如何布局产品元素的层级结构。

使用层级结构向用户提示产品的工作方式，产品的各个界面应该向用户显示隐性或显性的层级结构。

第八章 卡片分类

概念：

卡片分类：人们认为产品的某些部分应该出现在某些特定的位置，卡片分类可以帮助我们搜集这些信息。如果产品比较复杂需要对其内容进行分类，如果你正在设计一个网站，需要决定如何组织各个页面或者正在开发具有多种功能的应用程序要用用户可以理解的方式对其功能进行组织分类，可以考虑使用卡片分类技术。

卡片分类的方法：

准备工作：准备一些带有编号的卡片，在卡片上写下要进行分类的内容。不要把相差很远的层级内的东西混在一起，可以为不同层级的信息进行多次卡片分类。卡片上词语的含义要显而易见易于理解。卡片总数要控制在20~80张，还有准备一些空白卡片。

参与人员：可以让一个参与者进行也可以让多个参与者同时进行。多个参与者的情况比较难以协调进度，一个人的话不存在这种情况。但多个参与者可以互相交流，激发出很多有价值的见解。每次执行卡片分类的参与者不能超过3~4人。每次用户研究最好进行15次。

执行卡片分类：用户把想在同一屏幕看到的功能放在一起，有些词语无法理解是可以删去自行填写。确保参与者能理解每个卡片的含义。记录参与者提出的想法和问题，如果参与者提出了一些新词汇，可以为其制作额外的卡片。如果参与者分出的组中只有很少的卡片，鼓励他们把相似的组合并到一起，如果分出的组内有很多卡片，鼓励他们进行更细的划分。也可以进行“封闭式”卡片分类：事先定义好分组。让参与者把他们认为放在哪里都不合适的卡片放弃。分完组后为每个卡片组进行命名。分组够多时，对分组进行排列把认为有联系的组放在一起。最后，收集数据。

远程卡片分类：

评估结果：如果在卡片分类之前已经预先定了一些分组 ，那么计算出某个卡片在每个组内出现的频率，就能得到大部分人希望这个卡片所表示的内容出现在什么地方。如果分组是由参与者定义，那么首先要重新定义这些分组，有时不同的人会用不同词汇描述同一分组，要把这些分组合并起来。确定好分组后，再次计算每个卡片在所有组内出现的频率。然后可以构建出产品界面的层级结构，应用到产品的视觉布局和信息架构上。

可用层级结构的创建准则：

允许同一内容在多处出现：创建一个宽松的层级结构

深和浅的问题（点击次数的多少）必须控制呈现给用户的选择数量，不要超过七个。

关于分组：良好的分组便于用户浏览大量可用的选项。

第九章 心理模型

1.用户的心理模型不一定必须正确，只要和产品的行为方式一致就行了。

2.三种不同的模型：

用户大脑中的产品工作原理，也就是用户关于产品的心理模型

产品在用户界面中呈现的方式，称之为“UI模型”

产品实现功能的过程，称之为实现模型

在理想产品中，这三种模型应该是一致的

3.隐藏产品功能的实现细节

在 UI模型应该向用户隐藏实现模型的复杂性 和 UI模型应该与实现模型保持一致 之间权衡。简化用户界面才能使大部分用户拥有美好的体验过程，但这意味着UI模型可能无法与实现模型完全一致。

4.抽象漏洞

当出现抽象漏洞时，即隐藏的实现细节被泄露给用户时，用户会发现自己的心理模型无法与产品的行为方式相匹配

5.为心理模型而设计

首先，需要找出人们对事物工作原理的认知：通过与用户进行交谈找出他们大脑中预先存在的心理模型。然后进行卡片分类，找出用户对相匹配事物的认知。再利用纸质原型进行可用性测试。向用户展示你的设计方案，描述一个交互过程，询问他们有何期待。

随后，设计出与之相匹配的用户界面，一定要保证用户需要学习的东西少而简单。如果你发现用户在使用产品时的心理模型总是错的，那么可以尝试改变产品的外在表现。

帮助用户形成有效心理模型的七个用户界面设计原则（《心理模型与可用性》）：

原则一  简单

原则二  熟悉 ：你的产品应与相似产品保持一致，与现实世界中产品的工作原理保持一致，这样，用户才有可能形成正确的心理模型。

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

原则四  灵活 ：如果可以，允许用户以任意的顺序使用不同的技术执行操作。

原则五  反馈 ：要经常为用户的交互动作提供即时有效的反馈。但如果加入的反馈机制过度或不清晰，会让人们更加迷惑。

原则六  安全 ：用户的操作应该是无害的。如在关闭一个未保存更改的文档时，在损坏已更改的内容之前应该给用户提供反悔的机会。

原则七  功能可见性 ：用户界面元素的设计应该向用户提示界面元素的交互方式。传达可行交互方式的设计细节称为功能可见性。好的设计师会让用户看到适当的操作，隐藏不适当的操作。

第二部分  设计

第十章 草绘与原型

在清楚想要设计的产品后，进入详细设计阶段。首先草绘出产品的结构，然后设计出各个屏内所要显示的内容。前提是，你需要对产品的最终模样有明确的想法。

产品结构设计 ：流程图和故事板只关注产品的整体结构，与细节无关。

流程图：解决以下问题：用户要如何操作才能得到自己想要的东西？要按什么样的流程执行操作？选择最为重要的用户目标，然后考虑这些目标所需的步骤。

故事版 :通过绘制故事版把用户路径分解成一系列的快照图片。故事版通常会忽略分支，而仅关注交互细节。用户究竟在每一屏内看到了些什么东西？你想让用户做什么？你需要在什么地方使用动画或图像来帮助用户理解他将要做的事情？

草绘 :完成产品的结构设计之后，就要开始设计各个屏幕显示的内容。通过流程图和故事板已经明确了设计的产品需要哪些界面，每个界面需要提供什么样的功能。现在要确定各个屏幕中要显示的内容。用简单的草绘图说明各个屏幕显示内容的基本效果。

线框图 :用来展示屏幕所显内容的结构，但没有任何修饰。考虑线框图中应该包括哪些文本，这些文本应该放在哪些地方。

实体模型：在线框图的基础上加入修饰或是视觉细节，实现“功能可见性”。制作产品原型的目的是探索最终系统的具体特征。

工具：Balsamiq和Mockingbird用来创建并分享自己绘制的用户界面草图。Google Drawings绘图模块支持多人协同设计。

第十一章 纸质原型测试

概念：

纸质原型测试：在绘制了产品草图的情况下进行可用性测试

打游击式纸质原型测试：在这个阶段你已经有了产品的静态原型。要展开纸质原型测试，需要准备产品某个界面的草图，线框图或实体模型，并且要足够详细。然后找个愿意花5分钟测试的人，向他们展示这些产品界面，问他们一些常规问题或一些简单的与任务有关的问题。这种测试能让你大概了解用户是否理解你的设计，以及哪部分用户不能理解。

完整的可用性测试：典型的产品原型展示的只是最终产品的一小部分，一般无法包括最终产品的所有界面内容。因此，产品原型的可用性测试总是基于某些特定任务进行的。进行完整可用性测试的流程：首先，确定测试任务。选择那些对产品来说非常重要，你觉得可能会比较难用或者可能会存在问题的功能进行测试。然后，制定出使用产品这些功能的任务。如果需要的话，你还可以利用早期进行用户研究得到的信息来制定测试任务。记住测试的目的是观察测试者与设计方案进行交互的过程，从而找出交互设计存在的缺陷，所以一定要选一些能够让测试者真正使用产品的任务。其次，创建纸质原型。准备用户将在测试任务中遇到的所有屏幕显示内容，不能太过粗糙。在需要的地方添加一些产品运行环境的用户界面元素（如为网页界面设计草图加上浏览器）。创建测试所需的弹出元素。为测试者准备一些在产品原型上修改数据的方法。在独立的纸张上打印出测试任务。对每个任务进行测试运行，确保你已经准备好了所有可能用到的屏幕显示内容和弹出元素。

测试的准备工作：还需要一个执行测试任务的人。一般来说，用自己公司之外的人来进行测试。最好的做法是邀请3~4个人，每个人进行两三小时的测试，这样你就有时间在测试中仔细检查已发现的问题，相应的对纸质原型做出一些改变。设立一名“协助者”向测试者介绍测试流程，给出任务，回答测试者提出的问题。让测试者签署一份同意录像的表格。

准备测试者:

执行测试：协助者一定不能影响测试者。产品原型中一定要杜绝出现术语，提问测试者的用词越常规越好。协助者要避免做出任何让测试者感到不安的举动。“电脑”的任务是根据测试者的输入更新产品原型。在测试者完成第一项任务后，协助者和“电脑”可以花几分钟询问那些不能在测试中问的问题。询问测试者对整个测试过程的感受。

分析测试结果：不要对测试结果做任何统计学或形式化的评估。可用性测试提供的是定性数据，不是定量数据，对这类测试的结果进行形式化分析会产生误导作用。

何时停止测试？测试是不会停止的。它是开发过程中一个持续不断的部分。

第十二章  写实主义

赋予应用程序或网站一种实物的外观和行为是一种非常好的做法。这种一致性有助于人们理解产品的工作原理还能帮助人们理解用户界面所能提供的交互方式。

符号：当前用户界面中的大部分视觉元素都代表某些概念或行为。如“小铅笔”代表“编辑”，“停止”标志代表“发出警告”。为图像加入细节会减少其普适性，而缺乏细节的按钮设计只是一个原型。

实物的虚拟版本：视觉写实--复制现实世界中的某个物体，创建其虚拟版本--能帮助用户形成与产品进行交互的心理模型。然而，让用户迅速形成固定的心理模型并不总是件好事，这会让用户在使用产品前就对产品的工作方式产生某种特定的预期。即，采用的写实主义的视觉元素设计，那么交互方式的设计也应该写实。

模拟自然约束：找到现实世界的复制品和产品可用性之间的平衡点。在很多情况下，不要试图在电脑屏幕上模拟现实世界的物体及其约束条件，而是最好找一个利用电脑技术优势创建的用户界面。

第十三章  自然用户界面

CLI（命令行界面）  ：预先定义的一系列文本命令的交互==》GUI（图形化用户界面）：基于隐喻的交互，用图标表示数据和命令==》NUI（自然用户界面）：基于对真实物体进行直接自然的操作的交互

尽可能允许用户直接操作产品

对所以的用户操作给出即时生动的回馈

把那些并不操作对象，而是激发命令的用户手势仅仅作为快捷方式，而非主要的交互方式

确保用户不需要学习复杂的手势

确保用户不需要做出精确的手势，给予用户输入的自由，但要允许他们撤销错误的输入

运行自然用户界面的硬件特别容易把用户的无意操作理解为信息输入。尽可能阻止偶发性输入；如果发生偶发性输入，提供应变方案

如果可能，复制现实生活中的行为。让电脑以用户能够识别能够理解的方式立即做出响应。

参考流行软件的做法

定期让实际用户对用户界面的交互原型进行测试

第十四章 菲次定律

菲次定律：在桌面系统中，用户能快速点击到那些较大或比较接近于鼠标指针的目标。动作的方向也是影响因素之一，目标的形状应该与动作方向一致。

任务的难度系数（ID）=log2（目标距设备指针的距离/目标在运动方向上的宽度  +1）

屏幕边缘具有无限大的尺寸：屏幕的角落位置很容易点击，因为那里有两条边界。

放射式环境菜单会减小平均移动距离：如果鼠标指针所在位置处有菜单弹出，在指针周围布局各个菜单可以有效减小到达每个选项的平均距离。

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

有时，屏幕元素越小越好。如破坏性元素设计的小一些能有效降低用户在无意之中点击到的概率。

在不同的可点击元素间保留一点间距

第十五章 动画

解释状态的变化：模拟两种状态之间变化过程的动画能让状态的改变和两种状态的关系显而易见。

引导用户的注意力：制作动画的目的是夸大状态的改变，让用户无法忽略正在发生的事情。最有效的提醒应该是映入视野内，消失，然后每隔一段时间再次出现的事物。

避免使用不重要的动画：只有当你真正想打断用户，强迫他们关注某些东西，用动画来传递相关信息时，才使用动画！

帮助用户形成恰当的心理模型：动画所传递的信息应该与用户界面的其他部分保持一致

向卡通漫画学习：实体感：在动画中重现物体的实际形态更有利于让用户明白当前正在发生的事情。让用户与动画中的物体进行交互，而不要呈现给他们物体的轮廓或其他占位符。

夸张：没有先兆的动作会显得突然，僵硬而且不自然。你可以利用所有现实中可能有的效果，让屏幕上发生的事情变得更加明显。

加速与减速：模拟实物的缓入缓出。

用户界面并非卡通漫画：动画会分散人的注意力。为了增加产品的趣味性而牺牲可用性是得不偿失的。

第十六章 一致性

人们擅长于识别用户界面元素，所以界面元素没有必要都一模一样

同类界面元素一定要有相似的外观，相同的行为方式，因为人们会尝试把已有的心理模型应用于相似的界面元素

如果你必须创建出与常用界面元素行为不一样的设计，一定要确保视觉上存在差异，这样人们才不会形成错误的预期。

第十七章 可发现性

“可发现性”是指用户是否能够发现并使用产品的某些功能。

哪些功能要易于发现？

首先，要确定的是应该使哪些功能更易于让用户发现，哪些功能不易于被用户发现。有时，甚至可以隐藏某些功能，但前提是要知道那些需要该功能的人能够发现如何使用该功能。

然后，确定重要功能的重要程度，不能把所有功能都设计的同样明显。

在以下情况，可以让某个常用功能不那么容易被发现：

虽然人们不知道产品的功能，但这毫无影响。

虽然该功能没有直接显示在用户面前，但用户自己能找到它。

该功能十分诱人简单且经常被使用，人们知道之后就会记住它。

何时让用户发现？

做法一，使用环境化或模态化用户界面

做法二，只有用户选择了支持这些属性的对象时才将其显示出来

如何让用户发现？

空间属性：可以利用诸如大小，位置，形状和颜色之类的属性，让程序中的某些元素更容易或更不容易被发现。

用户期望：界面设计要保持一致，每一屏采用相同的布局方式。如果用户已经建立了产品工作原型的心理模型，通常你可以利用这种预期来让某些内容更容易或更不容易被发现。

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

动画：谨慎巧妙的使用。对于长时间显示的内容坚决不要使用动画。

第十八章  不要打扰用户

不要打扰用户。打扰用户会让他们不高兴，降低其工作效率，其本身也是不礼貌的行为。

帮助用户做决定而不是向他们提问题。

如果不能帮助用户做决定，一次问完所有需要的问题，而不是每次遇到新问题时都打扰用户。

如果你必须告诉用户某些事情，保证尽量不打扰用户，这样他们才能按照自己的时间安排处理这些事情。

第十九章 用“撤销”取代对用户的干扰

在用户做出某些具有潜在威胁的事情之前提出警告并不会奏效，因为用户会忽略这些警告信息。

允许用户撤销他们的操作，这样才能避免发生意外。

如果“技术”不支持撤销操作，至少要延迟具有潜在危险的操作，这样即便用户发出了命令，也仍然能够阻止事故的发生。

第二十章 模式

模式是应用程序中用户必须正规的进入或退出的一部分，在起作用时，它限定了可执行的操作行为。--卡罗琳罗斯

人们在现实生活中通常不以模式的方式工作，因而面对计算机软件中的模式问题时，这更强化了他们对电脑非自然不友好的印象。--卡罗琳罗斯

隐性模式

模式是界面中引发错误迷惑不必要的约束和复杂性的重要根源所在。

让模式显性化的一种方法是提供视觉反馈，暗示某一模式处于激活状态。若静态视觉反馈无效也可以使用动画。还可以使用动觉反馈或音频提示。最好尝试解决这一问题的各种方法，然后进行可用性测试，看哪一种方法更有效。

意外模式

对话框是一种特殊的模式。对话框常常出乎用户意料之外，因此它会引发与隐性模式一样的问题：用户界面没有实现用户想要的结果，因为它不在用户期望的模式之下。而且对话框还会让用户的输入误以为是针对模式化对话框的，而不是针对先前处于激活状态的窗口的，这种情况被称为“偷换焦点”，这样会导致一些不希望出现的操作。

难以退出的模式

用户通常不能明显看到该如何退出被激活的模式，这就会引发可用性问题。如果要使用模式，一定要让用户明确知道如何退出模式。

模式并非一无是处

在需要的时候，模式可以用来表面产品的功能，而非模式化的界面在任何时候都必须提供大量无能的用户操作。只有那些隐性的意外的难以退出的模式才是不好的设计。

准模式

“准模式”是指那些只要用户明确的保持激活就能存在的短暂模式。如shift键，按住鼠标拖动等。如果要使用模式，考虑一下准模式能否解决。

第二十一章 用你的观点代替偏好设置

产品的设定方式：

设置：用户对你的产品功能或行为所能做出的全局性更改。

配置：产品正常工作所需的设定，比如屏幕分辨率或网络设定。

偏好设定：改变产品行为的设定，通常不是严格必须的，但某些人或许会比较喜欢这些选项。

个性化设定：纯粹实现某种视觉效果的设定，不会改变产品的实际行为，比如桌面背景。

为什么偏好设定不好？

偏好设定会以各种方式给你的产品带来完全没有必要的复杂度。

现实中总有一种对大多数人都有效的方案，你要做的就是找出这个解决方案。

给出隐性的偏好设定：不要让用户专门设定产品行为，而是要记住用户上一次的操作。如：不要让用户设定窗口的默认尺寸，而是使用用户上一次缩放后的尺寸作为默认窗口尺寸。

第二十二章  层级结构，空间，时间以及我们对世界的看法

层级结构

有时，层级结构很有效，但结构一定要清晰，能被大众用户所接受。

如果每个人都要自己设定层级结构，那么它的作用会降低，尤其是多个人共用一个层级结构时。

空间

如果你的产品能利用人类这种对空间的感知能力，能让用户对他们的数据在空间中进行布局，那就去做吧。

用户期望在自己设定的位置找到某个东西，一定不能背着用户改变某些东西的位置。

当用户对大量内容进行管理时，空间系统显得有些乏力。

时间

根据产品的不同，可以让用户以某种时态视图来访问数据可能会比较有效。

更好的层级结构

限制深度：如果只能让用户创建较浅的层级结构，他们不太可能会迷失其中。

空间中的层级结构：比如，只要一个文件夹里放置的应用程序不超过9个，就可以通过文件夹的图标看到里面的程序。

允许用户在多个地方放置内容：通常各个项目并没有十分明确的归属，层级化的文件系统应该允许用户把相同的文件放在多个地方。

支持标记和其他元数据：允许用户在层级结构中对各个项目的元数据进行操作，这样他们就可以组织管理那些无法通过层级结构表达的数据。

支持以其他方式访问数据：要允许用户以非层级结构的方式访问数据。比如，允许用户搜索数据。你要考虑用户可能会用何种方式搜索或浏览数据。

第二十三章  速度

速度比功能更重要，速度不仅仅是一项功能，也是一项用户需求。而可用性测试无法暴露出产品在速度或是反应度方面的不足。

响应度：在可能的情况下，最好能保证操作能在0.1秒内完成。

进度反馈：如果某个操作的完成时间超过0.1秒，你就要提供一些反馈信息，明确的告知用户，电脑已经接收到他们发出的信息，正在处理。

对速度的感知：改进速度感知的一种方法是先尽快显示结果，只要找到结果就马上显示出来。另一种方法是，确保持续时间较长的操作不会卡住产品的用户界面，使用户可以在此过程中做其他事情。最后一种方法是，在进度条上显示一条与进度成反方向运动的条纹，这样会让进度看上去快一些。

慢一点：非常快的产品也惹人讨厌。如滚动操作。如word软件手动保存按钮，保存太快没有给用户明显的反馈

第二十四章  避免不断加入新功能

谨记用户的目标：人们并不关心你提供什么样的工具，只关心工具能做什么。

五个为什么：在收到用户反馈信息时，多问为什么来找出他们真正想要实现什么。通常，不必要为产品加入新功能就能找到用户问题的解决方案。用户真正想要的是什么？他们想用添加的新功能解决什么样的实际问题？

提升已有功能的可用性：如果大量新要求都能通过产品当前的功能集满足，那么你应该花些时间改进产品已有的功能。只有当虽然新功能与现有功能相同或相似，但其使用方法更好更易用时，可以考虑用新功能代替就功能。

一举多得：不要单独地加入新功能，把相似的功能当做一类问题解决更有意义。

成本：除了考虑新功能所能带来的收益之外，还要考虑实施该功能所要付出的代价。

隐形的功能：增加一项有用的功能的同时不加重用户的“认知负担”。如改进文本渲染功能，使产品创建的文档更好看。为网络应用程序增加支持HTTPS访问功能。

提供API和插件架构：让其他开发者介入进来，就可以避免实施那些仅对部分用户有用的功能，而将这一工作留给其他开发者。

倾听用户的心声：在加入新功能前要进行适当的用户研究，找出用户真正想要的功能以及使用该功能的目的。

不能太听信用户：如果你满足了所有“我只需要这一个功能”之类的请求，最终的产品会充斥着大量不常用的功能。

不必让所有人都成为用户：“少即是多”。

第二十五章  去掉某些功能

问以下问题：

如果只有一部分用户使用这项功能，是因为产品的设计目的就是如此吗？还是说这项功能非常重要，使用率不高是因为功能本身就有问题？

究竟是因为用户界面难以理解，还是功能被隐藏了起来，或是名字没有取好导致只有很少人使用这项功能？如果用户知道如何使用，该功能的使用频率会不会增加？

这项功能被忽略的原因是不是仅仅因为它毫无必要？

使用率低只是产品可能存在问题的指标之一，不一定说明你应该去掉某项功能。如备份程序的大部分用户很少使用恢复功能，但不能去掉。

如果决定要去掉某项功能，告知用户，在执行决策之前从用户处取得一些反馈信息。

提供一些备选方案，如为要去掉的功能独立开发一款较小的附加产品，将产品的旧版本维持一段时间等。

第二十六章  向电子游戏学习

乐趣是什么？面临富有意义的挑战和任务；有一种方法来衡量自己是否更接近于完成挑战；拥有克服挑战的能力。

产品与游戏的区别：

游戏要提供任务，而产品不需要。你的产品不是游戏，用户会自己找任务，如创建一个演示文档或找到某个特定的信息片段。

游戏要控制难度而产品不需要。把挑战设计的看上去很难，同时保证人们能够完成它。

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

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

技能成长：游戏会随着玩家技能的成长变得更难。如果能做到的话，产品的用户会向更难的问题发出挑战。把用户保持在“流畅区域”内，挑战的难度应该与用户的技能相匹配，产品需要随着用户技能的成长而成长。

探索与奖励：用户发现了产品的新功能或作出了某些正确的操作，系统给予用户奖励。

竞争：用比赛和成绩来吸引用户更多的使用它们的产品。

搜集物品：

一致性规则：规则应该是完整且非常明确的。如果主宰产品的规则是模拟两可或不可重复的，那么用户将无法形成关于产品工作原理的正确心理模型。

趣味性和可用性

虽然不是所有可用的产品都能让用户获得乐趣，但所有有趣的产品必须具备可用性--否则，它只能让用户觉得沮丧。

让产品充满乐趣是非常不错的目标，但永远不能以失去可用性为代价。

第三部分     实施

第二十七章 游击队式的可用性测试

概念：

游击队式可用性测试：可用性测试通常都需要邀请别人到你跟前，这会带来很多问题。因此，到用户那里去，而不是让他们到你这里来。

在可用性测试之前，你应该已经开始编写代码，至少有一部分用户界面已经可以工作了。且产品能在便捷设备上运行。

测试频率：不需要做任何准备，随时可以展开。

测试的准备工作包括：把产品安装到便捷设备上，保证产品可以运行，设计出一些简单的测试方案。

到附近的咖啡馆找一些人，或者在你所工作的办公大楼里找那些有空闲的人，询问他们有没有时间花5分钟做测试。

如果找到测试者，向他解释测试过程和产品的前期知识，并给他一项简单的任务。

不要打扰测试者，除非你觉得测试者正在变得沮丧或卡住了。做测试记录。

在进行数次测试之后，你会找到用户界面仍然存在的问题。修正这些问题，再次进行测试。

第二十八章  可用性测试

可用性测试的成本并不一定很高。以尽可能低的测试成本获得好的测试结果，即便是差劲的可用性测试也能得出一些有用的结果。

测试频率：每周抽出半天来进行测试。尽早看到新设计方案的效果能让你更兴奋，无论它能否解决问题，是否会引发新的问题。

测试者的数量：观点--仅仅五个用户基本上就能找出一个较大团队所能发现的所有可用性问题。只邀请一个用户进行测试是有缺陷的。如，没有其他任何东西与所得测试结果对比。费劲准备的测试只产生了一个结果。但也有一些明显的优点，如，可以很容易的找到人测试；不需要调整多个人的日程安排；可以很容易的自己开展整个测试，不需要额外的人来接待照顾那些等待的人。

产品测试对象：不要浪费太多的时间在某个特定群体中招募测试者。大部分时候，无论背景如何，人们总能发现相同的可用性问题。

不同类型的测试：

有主持的任务测试：由协助者主持测试，并向测试者介绍不同的产品行为或测试任务。主持人在测试者执行任务时观察其行为。在测试过程中，协助者和测试者呆在一起，并与他们进行交流。

无主持的任务测试：协助者向用户介绍可用性测试，并解释所有界面元素的工作原理。协助者在纸张上写下一系列工作原理，交由用户完成，然后离开测试房间。在这种测试中，测试者和协助者之间没有交流，排除了协助者可能会对测试者产生的影响。

自由测试：协助者不给测试者分配任务额，而是鼓励测试者自己探索产品，做自己想做的事情。如果你找到的测试者已经对产品产生了兴趣，这种做法获益最大。

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

第二十九章   现场测试

现场测试是指你邀请一些用户，观察他们使用产品时的情形，并利用所得信息改进产品的过程。

有主持的任务测试：

1.测试者是否能识别出产品是什么？如果测试者识别不出，你就发现了第一个可用性问题。

2.要知道测试者是否知道如何使用产品?准备一些测试任务，把每一项任务单独列在纸上。递给测试者写有任务的纸张，保持沉默，观察测试者行为。

3.问完所有问题后，请测试者对测试过程进行评价。

无主持的任务测试：

离开测试现场。事先说明当测试者遇到某类困难时应该怎么办。

自由测试：没有测试任务，目标是观察测试者在不知道下一步应该做什么的情况下的反映。只要向测试者介绍一下测试，然后让他自由摆弄产品。

以乐观的态度对测试做出总结。

用常规方法对测试结果进行评估。找出最紧迫的问题并修正它，然后再次测试。

如果不确定某个问题是否广泛存在于用户之中，不要急着解决它，如果该问题比较严重，它会再次出现于后续执行的测试中。

第三十章   远程测试

有主持的远程测试：可以利用诸如skype，iChat或copilot之类的屏幕共享软件来完成测试。

无主持的远程测试：完全不与测试者进行交流的情况下开展远程测试。可以让测试者在使用产品时或者执行某项预先设定的任务时自己录制屏幕录像。

如果还没有执行任何可用性测试，你首先应该开展几次传统的现场可用性测试，你可以先邀请朋友担当测试者，直到熟悉了测试流程。

只有熟悉了可用性测试的流程，你就可以开始执行远程测试了。

每周至少执行一次远程测试。

除了其他渠道（比如，邮件列表，讨论小组甚至报纸），你也可以利用网站招募测试者。利用网站招募测试者极其方便，也不需要任何费用，但如果只通过这种方式进行招募，测试结果可能会向那些有产品使用经历的人倾斜，因为他们很可能访问过你的网站。

剔除那些纯粹奔着奖品来的测试者。

在联系潜在的测试者时，一定要让他知道你在测试中能看到他的屏幕，并征求他的同意对测试进行录像。

在执行远程测试时，你通常无法看到测试者的面部表情和他们所关注的东西。注意测试者变得沮丧或不安的情况，如果发生了此类情况，请停止测试。

在测试的最后，感谢测试者为此付出的时间，向他说明你再也看不到他的屏幕了，并赠送奖品。用乐观的态度结束测试过程。

第三十一章  如何避免测试中的常见错误

不要使用用户界面中的词：在设计测试任务和与测试者交谈时，一定不能使用应用程序中的术语。任务描述时不要描述任务本身，而是描述任务目标。

不要影响测试者：如果测试者寻求你的指导，一定要小心，这表明产品出现了可用性问题。

避免营造紧张的氛围：

不要经常要求测试者大声说出自己的想法。

如果测试者看上去焦虑不安或是感到厌烦，就停止测试。

第三十二章  用户错误即使设计错误

用户没有出错。出错的是你的产品，因为它不能正确的解读用户的操作行为。

不要在错误信息中责备用户：不要责备用户，我们应该因为问题向用户道歉。这才是良好的可用性，因为它能让用户冷静下来，处理问题。为用户提供“情感支持”。主动识别并处理用户的情感状况，能缓解挫败带来的强烈的负面情绪和刺激。

没有错误就没有责备：在错误信息中给出帮助用户解决问题的方法。但最好的做法还是根本就不让错误出现。

只需改变用户界面，你就可以防止很多常见错误出现：

模式错误：归咎于产品没有明确显示出当前所处的状态，或没有明确告诉用户该执行什么样的操作。

输入错误：产品没有明显提示的数据有效格式。应用程序或网站应该清晰地表明期待用户做什么或者允许用户以自由的格式输入内容。  另一种解决方法是不要让用户决定该在界面中输入什么样格式的数据。比如不要让用户在文本字段内输入日期数据，而是提供一个日历供用户选择。

第三十三章  A/B测试

A/B测试能用来对比两个不同的设计方案，而且还可以对比一个设计方案的数个不同版本。

A/B测试可以让你用精确的数据改进设计，没有任何推断和猜测的成分。

使用A/B测试的前提条件是：你应该准备好能运行的产品版本，还需要早足够多的人来使用它。

何时执行A/B测试？

通常来说，使用于以下两种情况：你已重新设计或重新撰写了某些东西，想知道新方案或新内容是否比旧方案更有效；某一问题有数个可行的解决方法，你想找出哪个方法最有效。

什么是“成功地使用产品”？

定义“成功”的一种方法是回到设计过程的最初阶段，考虑用户的目标是什么。如果更多的用户能实现他们的目标，那么产品就更有效。

测试的准备工作工作：

执行测试：在执行A/B测试时，要确保用户不会在两个不同的设计方案间来回转换。应该把用户分成不同的组，确保他们能持续关注某个方案；在执行测试的过程中，你要有搜集测试结果的方法；你还要告知用户，你正在收集产品使用数据，并具体说明你要收集些什么。

解释测试结果：要记住一点--统计显著性，你需要知道正在关注的测试结果出现的随机概率有多大。如果A/B测试中有两个以上的设计方案，你可以对比各个设计方案，看看差异性是否明显。

需要记住的要点：

如果你用A/B测试来对比设计方案较小的，递增式的变化，一定要记住，A/B测试只能为你带来局部的最大可用性。

在对比高度优化的旧有方案和新方案时一定要知道，即便新设计方案在直接对比中稍差一些，但如果你能像对待旧方案一样倾注同样多的心血，新方案最终会有更好的表现。

第三十四章  收集产品使用数据

产品发布后，用户会以你没有想过的方式使用它。你要知道用户在做什么，这样才知道该如何改进产品。

速度：速度是一项很重要的性能，因为你一般很难知道产品在用户手中的实际性能，直到产品为用户所用。

退出产品：任务执行过程中的退出行为是产品存在可用性问题的指标。为了找到产品潜在的问题，就要追踪这些行为。

定义“失败”：估计产品的失败表现，如已损坏的链接，空的搜索结果，或是网络冲突之类的现象。从这些地方可以很容易收集到一些改进产品的有效数据。

用户行为：观察用户行为，抓住改进产品的最佳时机，需要增加哪些功能，应该去掉哪些功能；用户已经开始使用产品，但这并不是设计的终点。现在正是个大好机会，你需要观察用户实际使用产品的行为，并利用相关信息改进产品。

第三十五章  处理用户反馈

用户可能会以你没有预料到的方式使用产品。这可能是把产品设计导向新方向的大好时机。

不要因为负面反馈而心灰意冷。应该利用这些反馈把愤怒的顾客变成产品的粉丝。