可用性工程阅读笔记 Nielsen 

看这本书和写下这些笔记总共用了快两个星期的时间，这段时间事情真的有点多。。

从这本书里，能够看到关于可用性测试中的绩效测试真的和我们心理学平常的实验设计很像。我觉得在看到那部分时最惊讶的是，关于作者提出来的若干个可以用在实验测试中的指标，我觉得如果不是平常比较擅长于这方面可能真的想不出那么精妙的指标。总体上来说，是对产品的可用性概念更加清晰了，应该对正在参加的这个比赛的整体设计有很大的帮助。

1.可用性及相关概念

可用性对于系统可接受性来说，是一个相对来说较小的概念。系统可接受性表示的是是否可以达到满足用户和其他可能的相关方（如用户的客户和经理）的所有需要和需求的程度。

可用性和系统可接受性的关系：

2.可用性的五个传统成分：

1)可学习性：系统应当容易学习，从而用户可以在短时间内开始用系统来做某些事情；

2)效率：系统的使用应当高效，因此，当用户学会使用系统后，可能具有更高的生产力水平；

度量使用效率的典型方法是，确定关于某技能水平的定义，寻找一些具有这种技能水平的有代表性的用户样本，然后度量这些用户执行某些典型人物测试所用的时间。

3)可记忆性：系统应当容易记忆，从而那些非频繁使用系统的用户，在中间有一段时间没有使用之后能够使用系统，而不用重新从头学起；

关于界面的可记忆性的测试，有两种主要的方法：一种方法是对于在特定长的一段时间内没有使用系统的用户，进行标准用户测试，度量这些用户在执行某些任务上花费的时间；另一种是在他们结束一个使用系统过程后，让其解释各种命令的作用，或者完整说出某种功能的命令（或画出对应的图标），最后得到用户界面的可记忆得分，就是用户给出正确答案的个数

4)出错：系统应该具有低的出错率，从而用户在使用系统过程中能够少出错，在出错之后也能够迅速恢复，而且能够防止灾难性错误的发生；

可以通过统计用户执行某个任务过程中出现错误的次数来作为度量指标。

5)满意度：系统应该使用起来令人愉快，从而让用户在使用时主观上感到满意。

从原理上说，可以采用脑电图、瞳孔扩散率等指标作为评判用户在使用过程中的压力和舒适程度，但测量这些生理指标会需要用户配合额外的仪器，可能会成为用户畏惧的条件。因此在满意度的这项属性中我们通常的方法是让用户在测试完成之后填一份主观满意度的问卷

2.为了在一组可用性度量的基础上确定系统的整体可用性水平，通常的做法是取每个可用属性度量的平均值没然后看他们是否比先前确定的某个低标准要好。

3.一个关于图标的可用性测试实例：

参见参考文献：

[Green and Barnard 1990; Hakiel and Easterby 1987; Magyar 1990; Nolan 1989; Salasoo 1990; Stammers and Hoffman 1991; Zwaga 1989]

关于可学习性：

为某个图形界面设计了四套不同烦人图标，每套17个。对每套图标都测试其易学习性、使用效率和主观满意度。

程序：

每次向被试呈现一个图标，让用户描述“你认为这是什么意思？”——测试每个图标的直觉性；

向被试展现一套图标，告诉用户一个图标的名字以及它是做什么的的简短描述，让用户把他们觉得最匹配的图标选出来------测可理解性；

告诉被试一套图标的名字，让被试把它们与所有图标相匹配——测可理解性；

以上学习测试中的得分就是这些被正确描述和命名的图标所占的比例。

关于可记忆性：

在第一个测试中，对于通过参加学习测试已经知道图标含义的用户，给他们一个图标的名字，告诉他们它可能会出现在计算机屏幕中，然后随机地显示图标，如果是用户要寻找的图标，用户就按下“是”，如果是其他图标，就按下“否”。

在第二个测试中，向用户同时显示最忌分布的若干图标没让用户点击相应的那个。这两个图标都是计时的，图标的得分就是用户的反应时间。

关于主观满意度：

第一种方法是，让用户就图标是否容易识别，挨个图标给打分。第二种方法是，针对17个概念中的每一个，给用户显示可能的四个图标，让用户选择他更加倾向哪一个。主观测试中的满意度得分，就是用户在第一个测试中给该图标的打分，以及在第二个测试中选择该图标的用户比例。

最好的图标可以既表现操作的具体对象，又抽象地表示所进行的操作对象。

4.可用性权衡的问题：

一个系统可以是容易学习的或者是，难学习到最后使用效率却是高的。

和人的记忆学习曲线一样，注重新手的使用效率或者考虑给熟手创造更高的使用效率其实是不能够同时满足两者的，但可以把两种学习曲线好的部分结合起来，提供具有多种交互风格的界面，使得用户可以在开始学习阶段先学习使用容易学习的交互风格，后来在装箱对于频繁操作更高效率的风格。实现这种优势互补的途径就是用“加速键”，可以让用户更快捷低执行频繁操作的任务，尽管同样的任务也可以通过更一般的、也许比较慢的范式执行。加速键的典型例子包括功能键、命令名缩写以及通过栓剂来激活某个对象。

5.关于用户分类和个体差异

对于在相关领域有广泛知识的用户，可以再假面上使用专用术语，屏幕设计中的信息密度也可以加大。

6.关于计算机和用户界面分带的情况总结：

7.可用性生命周期：

可用性工程晟敏周期模型中的阶段：

1)了解用户

a.个体用户特征

b.用户当前的任务和需要的任务

c.功能性分析

d.用户及其工作的演变

2)竞争性分析

3)确立可用性的目标

a.经济影响分析

4)并行设计

5)参与型设计

6)整体界面的协同设计

7)指南应用和经验性分析

8)原型

9)实验性测试

10)反复设计

a.捕捉设计原理

11)从现场使用中搜集反馈。

这个生命周期模型强调的是，不应当部分青红皂白地直接进入设计阶段，想要使可用性活动左右产品的设计，最省力的办法实在设计开展之前做可能多的可用性工作，这样就不必为了满足可用性方面的要求而更改设计。而且，在设计开展之前所开展的可用性活动，可能会避免开发那些不必要的功能。

了解用户：

个体特征和各种不同的任务，是对可用性影响最大的两个因素，应当对它们进行认真研究。通过了解用户的工作经历，教育程度， 年龄，计算机使用经验等情况，可以在某种程度上预测它们在学习上回遇到的困难，从而对用户界面的复杂程度作出恰当的控制。我们还应当了解用户的工作环境和社会环境。举一个简单的例子，声音提示“嘟”声或者更加复杂的声音效果，对于在开放式办公环境中的用户来说是不太合适的。在作者曾经做过的一个用户访谈中，有一位秘书强烈不满，她需要能关闭“嘟”声提示音的功能，因为她不想要因为她的计算机总是想个不停，而让其他人觉得她很笨。

任务分析：

任务分析是系统设计必需的早期输入，应当研究用户的最终目标，还要研究他们目前是怎样执行任务的，他们的信息需求，以及他们怎样处理异常或者紧急情况。此外，还应该识别用户的任务模型，因为可以利用它得到关于如何设计用户界面的隐喻和启发，而且，通过观察那些特别有效的用户及他们的策略和工作环境，可以对于新系统应当提供的支持得到某些特别的启示。最后，应该找到当前情况下存在的问题，既用户未能实现的目标，花费过多时间和感到不舒服的地方，这些弱点将为改进新产品提供了机会。

任务分析还可以暗战结构进行分解，大任务分成小任务。每当用户在说“然后我做这件事情的时候”,进行访谈的人员就可以问两个问题“你为什么做这件事情”（把这件事情与更多的目标联系起来）“你怎样去做这件事情”（把这件事情分解成小任务，以便进一步研究）。访谈的最后还应该让用户谈一下留下印象深刻的成功或者失败的事例，存在的问题，他们最喜欢什么东西和最不喜欢什么东西，希望有什么改变，对改进有什么建议，以及目前的什么东西让他们感到烦恼。

竞争性分析：

原型是可用性过程中的重要组成部分，而享有的产品或者同类竞争者的产品，则常常是可以得到我们自己产品最好的原型。可以对现有的产品根据成熟的可用性指南进行经验性分析，或者对这些产品进行实验性用户测试。针对于已经完全实现了的产品进行用户测试要比对其他原型的测试更现实一些。用户可以使用同类竞争系统来执行真实任务，这使得我们可以了解，其功能和交互技术能否很好地支持这些任务，而这些任务是已规划的产品根据对目标用户的初步研究所预计要支持的。

确立目标：

可用性并不是系统的单维属性。可用性包含若干彼此可能互相矛盾的成分。一般来说，在一个特定的项目中，并非可用性的所有方面都具有同样的权重，所以必须根据用户和任务中的分析来明确他们的优先级。例如，有不断的新雇员招进来的话，就应该将系统的可学习性放在重要的位置；而对于那些每3-4个月才会使用一次系统的重配置实用程序来说，非频繁型用户使用系统的能力就应该受到重视，

对于每一个感兴趣的可用性属性，在确立可用性目标的过程中可以定义若干不同的绩效水平，至少定义对于产品发布来说可接受的最低水平，更详细的目标定义还可以包括计划达到的绩效水平和目前的绩效水平。另外，还要对系统的可用性的经济影响进行分析以及他们使用系统的大致时间量。

并行设计：

在开始及时，有一个不错的方法就是进行并行设计，既有几个不同的设计人员来进行初步设计，并行设计的目的是在确定某个设计方案之前，先对几个不同的设计方案进行一番探索，然后再对确定的设计方案做进一步的开发，开展更细致的可用性活动。在进行并行设计的时候，重点是要让设计人员进行独立设计，因为其目标是为了产生可能大的多样性，因此，在产生各自的设计草图之前，不应该要设计人员讨论他们之间的方案。

并行设计的另一种变形是多样化并行设计。它是基于让不同的设计人员侧重于不同的设计问题。例如们可以让一个设计人员针对新手用户来设计界面，同时让另一个人来这对熟手用户来设计一个方案，再让第三个人来探索一个完全无需语言的界面。通过确定每个设计人员的设计方向，多样化并行设计的方法可以把每一种方案推向极致，从而得到在通用设计方案中很难出现的设计构思。当然，对于某些多样化的设计构思需要进行修改，才能用到一个统一和集成的设计方案中。

咋一看，并行设计的方法可能和经济上的可用性工程是相抵触的，因为大多数构思被抛弃了，然而实际上，并行设计是一种探索设计中非常经济的办法，这正是由于对大多数设计构思都不需要费力去实现，而如果不这样做的话 ，其中的某些构思则要等到晚一些时候进行反复设计才能够实现。

参与型设计：

尽管在设计开始之前，我们就对用户进行了相应的了解，但这样的了解是不足以解决设计过程中的所有问题。在设计过程中，设计人员不应当只凭猜测，而硬钢与一些用户代表保持沟通，用具体非呈现形式呈献给将要使用产品的领域专家，引导和启发他们谈出自己的想法。

随着用户参与系统的开发过程，他们会逐渐变得不具有普通用户的代表性，一个参与过太多设计会议烦人用户代表，将会受到开发人员的思维方式侵染，将会了解所提出的系统结构，并可能会倾向于接受那些有问题的设计部分所做的解释。而后来参与到项目中的新鲜用户，则更可能对这种潜在的问题提出质疑，因为他们并不了解历史。

整体界面的协调：

一致性是最重要的可用性特征之一。对于一致性的度量在时间上并不是一次性的，而应当应用于产品的后续更新的版本，也应该牡蛎在整个产品族中的一致性。

原型：

早期的可用性评估可以基于最终系统的原型进行， 可以用更快捷和更经济的方法来开发这种原型，因此在对用户界面设计上获得更好的认识之前，可以对它进行多次修改。

减少功能数的办法为垂直原型，因为这样产生的是一个狭窄的系统，它的确包含某些完整的功能，但只针对少数选择的功能。

降低功能水平的做法成为水平原型，这样产生的知识结果的一个表层，具有完整的整个用户界面，意味着用户可以执行所用的导航和搜索命令，却不能通过执行这些命令得到一个任何真实的消息。

剧情：

剧情是对事物的一种很笼统的描述，一般包含以下几种元素：用户个体，对一组特定功能计算机功能的使用，获取特定的结果，在特定的情况下会发生什么，经过特定的时间间隔（明确包含什么时间发生了什么事情）。执行用户测验之前，可以询问用户接下来他们认为会发生什么事情。

界面评估

对于一个界面，采用合理的可用性工程评估方法评估改进后的界面再进行发布，会比没有经过测试就直接发布的产品的产品好太多，同时会比不断递增的版本更加省时省力。

严重性评价

不论采用什么方法评估，所得到的主要结果都是这样一个清单，内容为界面存在的可用性问题，以及关于改进功能以及支持用户任务的建议。通常，想要解决所有问题都是不太现实的，因此需要对现有的问题进行优先级排序。一般在这个过程中，我们会邀请可用性专家进行一个评估，由于不同可用性专家之间存在个体差异，所以由不同可用性专家评判的严重性程度并非一直都是可靠的，所以应该综合多个可用性专家的意见，去他们评判的平均值能够得到一个较为准确的结果。

严重性评价的两种方法是，一种采用单一尺度，另一种是采用若干正交尺度组合的方式。

单一尺度：

0=这根本不是一个可用性问题；1=只是一个表面的可用性问题，除非项目有额外时间，否则不必进行纠正；2=轻微的可用性问题，纠正这一问题的优先级较低；3=重要的可用性问题，需要重视改问题的纠正，应当给以高优先级；4=可用性灾难，在产品发布之前必须予以纠正。

严重性程度还可以根据可用性问题最重要的两个因素来评价，预期用户会遇到这个问题，以及这些用户受该问题影响的程度。

捕捉设计道理：

可以吧各种用户界面设计决定背后的中药道理甲乙明确的记载，以便于设计参考。在反复设计和开发产品未来的版本的时候，对界面设计的道理回顾是非常重要的，因为经常需要对界面进行修改，所以最好能够了解设计方案的基本原理，从而不会为了微不足道的目标而损害最原始的设计原理。

可用性活动的优先顺序：

以下是通过对13位可用性专家的调查后得到关于可用性活动的重要性程度打分，得分最高的6种方法是：1-2名是反复设计和对当前用户的任务分析，得分为4.7。第3名第用真实用户进行的实验性测试，得分为4.5分。第4名是参与型设计，得分为4.4。第5和6名是在设计开始前访问顾客现场，在系统安装运行后进行现场研究，以了解系统的实际使用情况。 在实际项目中，各种可用性方法的使用频率呈现一种搞得相关性（r=0.71）。

8.可用性经验原则：

(1):简洁而自然的对话。在屏幕中每增加一个额外的功能，就以为着用户需要学习更多的东西，误解的可能性就会越大，查找所需要的功能就会越来越困难。理想的情况下是仅提供用户当前所需要的信息，并把他们放在所需要的地方。在页面的布局上应当利用人类认知领域中的完全形态法则，以增加用户对对话元素间相互关系的理解。可以通过用大写字母的办法来突出重点，但是不要过于频繁的使用，因为大小写混合文本会让用户的阅读速度降低10%。 同时也不要过度地使用颜色，颜色数量方案中最好不要超过5-7种，因为用户很难记忆和区分太多颜色，即使是经过专门训练的用户也只能够对付大约11种颜色。另外，还要确保界面再不用颜色的情况下也能使用，要记住，很多人是色盲（8%男性）。

少即是多：

通过恰当的任务分析，通常能偶把对用户真正重要的信息识别出来，用户利用这些信息可以完成绝大部分任务。在设计过程中，最好将重要的任务放在主要屏幕上，将不太重要的任务放在辅助屏幕上。

(2)使用用户的语言：开发人员或许对于产品的专业术语很熟悉，但是用户未必能够理解，如果能够将产品中用于和用户交流的语言换成用户的母语，将会使得用户的使用效率增加。

还可以使用映射和隐喻的方法:为了实现面向用户的对话，一种比较常见的办法是力争让计算机显示的信息和用户关于信息的概念相符。通常，会要求用户列出一组与应用领域相关的概念，并且依据用户的应用领域模型进行排组和分析。其中一些常用的技术包括顺序回想（让用户尽可能自由地联想他们所能够想到的概念，其中运用的原则是一同提到的想法和概念模型中是相关联的），卡片分类，相似性打分（提供问卷，其中包括各种可能成对的概念，让用户对他们的相似性进行打分），这些测试的结果可以拿来直接使用，已通过使用统计程序来用于多维度量或聚类分析。

(3)将用户的记忆负担减到最小：

可以通过预测用户输入的内容来采取相应措施，比如在输入日期的对话框中，就应该在附近提示输入内容的格式或者提供用户最近使用的文档，供用户直接选择，而不是要让用户器回想或者猜。

(4)一致性：如果用户知道同样的命令或者同样的操作会产生同样的效果，那么他们在使用的过程中就会更加自信，同时也能够鼓励他们进行探索性学习，因为他们已经具备了使用系统新部分应该有的基础知识。另外，还要考虑系统任务和功能结构上也要考虑一致性。比如，有人发现，用户在采用命令行的PC机和采用命令行的大型机之间切换，要比在采用命令行的PC机和采用图形界面的PC机之间的切换更困难。从屏幕设计的观点上来看，两个命令行的界面非常相似，但其底层的操作系统差别却很大，而两个不同类型的PC界面是建立在具有同样原理和功能的系统之上的。

(5)反馈：系统应该不断告诉用户目前他正在做什么，而不应该等到系统出错的时候才给用户反馈：在用户操作正确的时候，系统也应该提供部分的反馈，并且当产生部分信息时应当给出部分信息的反馈。

响应时间： 如果系统所进行的操作需要很长的响应时间，反馈就变得很重要了，鲫鱼响应时间的基本建议多少年来都基本变化不大：

0.1秒是让用户感觉到系统立即做出了响应的时间上限，此时除了显示结果外不需要其他反馈；1.0秒是让用户思维不被中断的上限，但用户会感觉到延迟。通常不需要对0.1-1.0秒的延迟专门给出信息反馈，但此时用户会失去数据直接操作的感觉。10秒是让用户注意力保持集中的上限。对于较长时间的延迟，由于用户想在完成等待的时间里去完成其他任务，因此应该在任务快要完成时应当用过反馈信息来提示用户。响应时间不确定的情况下反馈显得尤为重要，因为这时候用户不知道要发生什么事情。

(6)清楚地标识退出：

(7)快捷方式： 典型的快捷方式包括缩写，功能键，命令键等，其中命令键使用一个按键代表一个完整命令，双击对象会进行最常用的操作。利用交互历史提供访问的一个简单的例子是，一些程序会记录用户经常打开的文件，这些程序可以为用户提供一个特殊的文件菜单，列出下一个用户可能会打开的文件。

(8)好的出错信息：出错的信息应该用清晰的语言表达出来，而不要使用难懂的代码，出错信息也应该精炼准确，如应该显示“无法打开该文档，由于文档不再磁盘上”而不是仅仅显示“不能打开文档”，另外，出错信息应该友好，不要威胁或者责备用户，如经典错误：“非法用户操作，任务被终止”

(9)多层次消息：不要在小子中包含所有可能有用的消息，而应该使用简短的消息以方便用户快速阅读，只要用户能容易地访问更详细的信息就好。

(10)避免出错和避免使用用户模式

(11)帮助和文档：提供使用手册和在线帮助和在线文档。在线帮助的好处就是上下文相关。

(12)经验性评估：经验性评估的目标是要发现用户界面设计中的可用性问题，因此经验性评估可以成为反复设计中的一部分，其他可用性检查的方法海英摆阔认知步进评审和诉求分析。单人评估可能会漏掉假面评估中的大部分可用性问题，有研究[Molich and Nielsen 1990; Nielsen and Molich 1990; Nielsen 1992C 1994b]在对6个项目进行评估以后，发现单人评估人员往往能够发现35%的问题，但由于不同的人会发现不同的问题，因此综合了多个人（10人）的看法观点会得到一个更好的结果。注意，要评估人员进行独立评估，最后才对比其他评估人员的观点，这样能够避免这个评估是独立的，无偏向的。评估者发现问题的能力也是一个值得考虑的地方。

9.可用性测试

可用性测试要保证可靠性和有效性（信度和效度的问题）。

（1）测试目标和测试计划

在进行任何测试之前，都应该搞清楚测试目的，因为对要进行什么样的测试有重要的影响。测试的种类分为两类，一类是形成性评估，反复设计中的一部分，目的是为了改进界面，因此这类测试的目标就应该是了解界面细节方面的优劣，如何改进设计，典型方法是边说边做式；另一类是总结性评估的目的在于评定界面的整体质量，例如可以用它在两个备选方案中进行悬着，或者竞争性分析的整体质量，俩了解竞争对手的产品设计好在哪里。

测试计划里面应该包含的内容有：

测试目标、测试时间地点、测试时长预期、测试需要的装备、测试要用什么样的软件、测试时系统处于的状态、测试时系统的网络负载和响应时间、测试人员、测试的用户、测试用户的数量、测试用户需要完成的任务、怎么找到用户、用户完成测试的标准、测试用户可以使用的辅助手段、测试人员可以给测试用户提供怎样程度的帮助、测试要收集什么样的数据，数据怎么处理和分析、判断界面成功的标准是什么。

测试预算：应该包含两部分，一部分是固定费用和可变费用。固定费用是计划和组织测试做所需要的花费，而不考虑用户的多少，可变费用是付给用户的额外费用。

另外，最好还是要先进行试点测试，防止一些任务不被理解。

（2）招募测试用户

有关找测试用户的主要原则，就是所选择的用户越能代表预期使用系统的用户越好。还要明确的是，这是新手用户还是熟手用户，如果是新手用户，还应该给他进行一些简单的培训先；用户间测试还是用户内测试，这里要注意的是应该按照实验设计的方法来设计测试，平衡问题；实验人员的发现问题的能力也需要值得注重，好的实验人员和差的实验人员发现问题的数量可以差上好几倍，实验人员还应该具备大量有关程序和用户界面方面的知识；最后，还要注意用人来进行测试的伦理问题。

（3）测试任务的设计：

测试任务的基本原则是所选择的测试任务要尽可能地代表系统的最终使用，另外，测试任务应该大致覆盖用户界面上最重要的那些部分，测试任务的设计可以基于任务分析或者基于产品用途说明。测试任务应该设计的比较小，这样就能在有限的时间内完成，但是任务小也不能够小道微不足道的程度。测试任务应该详细精确地说明用户执行后产生什么样的后果，因为使用计算机来达到某一目标的过程与只是随便用用系统是很不一样的。测试任务设计不要轻佻、滑稽或者冒犯，例如在测试一个绘画程序的时候，让用户在总统扫描的照片上画上小胡子的做法是很不妥的。首先，不能够保证所有人对同样的事情都会觉得很好笑，其次，这种不严肃的热内会让系统的测试受到干扰，甚至贬低用户的身份。相反，所用的测试任务都应该是面向业务处理的。为了增肌用户对任务的理解和真正使用软件的感觉，应该把任务设计的和和整个事件相关联。测试任务的设计上还可以把刚开始的任务设计的比较简单，保证用户先得到成功的体验以鼓舞士气。

（4）测试的各个阶段：

准备→介绍→测试→事后交流

介绍过程值得注意的点：说明测试的目的是为了对软件进行评价，而不是对用户进行个人测试；测试结果将会用户改进用户界面，所以最终发布的界面和测试中看到的界面可能有所不同；提醒测试用户对所测试的系统保密，不要与别人谈论有关的内容，以免带给后面要进行测试的用户一些主观的影响。任何录音录像的设备要跟用户进行解释。

测试期间，实验人员通常不要与用户进行交谈，也不要有人和个人观点或关于用户操作好或者不好的表示。实验人员可以发出一些不代表任何态度的声音，如“嗯”“啊哈”来表示知道用户的评论，并让用户继续做下去，这里要小心说话的语音和语调，不要让用户听出他对了还是做了可笑的事情。即使用户已经陷入了相当严重的困境，实验人员也应该不要去提供帮助，不过这种不提供帮助的方法不适用于用户已经明显停滞并且对当前处境感到不快的时候。实验人员应该谨慎决定自己应该什么时候提供帮助。在测试之后，要询问用户，并要求用户填写一份主观满意度的问卷，为了避免实验人员的评论所带来的偏向，用户应当在有关系统的讨论之前填写问卷。在交谈中，请用户对系统的使用情况进行评论并提出改进建议。

（5）绩效度量方法：

在各个目标之间进行平衡，决定好哪个可用性目标比较重要，然后将其细分量化，例如，“使用效率”可以用用户完成一定数量的规定任务的平均时间来衡量。在解释度量时，我们应该时刻关注主要成分，既总体上的使用效率，与作为该成分替代物（测试任务）的特定量化指标之间的区别。一个明显的例子是，反复设计过程中不应该把目标䦺在仅仅针对所要求执行的5个任务，而不考虑其他方面来优化界面，以改进系统的使用效率。

量化指标后，应该定义一些方法来度量用户的绩效，通常可以量化的可用性度量指标包括：

*用户完成任务的所有时间；

*在限定时间内完成的任务数量；

*正确的交互操作与所发生错误之间的比率；

*从错误中恢复所用的时间；

*用户出错的数量；

*随后导致的出错操作数量；

*用户用到的命令或其他功能的数量；

*使用手册或者帮助系统的频数，以及使用时间；

*手册/帮助系统有多少次解决了用户的问题；

*用户在测试期间对系统肯定和批评的比率；

*用户表达明显的挫折或者喜欢的次数；

*表示喜欢用该系统而不喜欢用某个特定竞争产品的比例 ；

*用户不得不试图解决或者某个无法解决问题的次数；

*采用高效策略和使用低效策略的用户之间的比例（在有多种方法完成任务的情况下）；

*用户不与系统进行交互的“呆滞”时间，可以在系统中度量出两种呆滞时间，一种是用    户等待系统响应所造成的延迟，另一种是等待用户思考所造成的延迟，这两种呆滞时间显然可以用两种不同的方法研究；

*用户注意力从真实任务呗吸引到其他地方的次数。

（6）边说边做的办法：通过测试用户对自己想法的描述，我们能够了解他对计算机的想法，还能很容易地确定用户对系统主要有哪些误解。这种方法的缺点在于，它并不适用于大多类型的绩效度量。边说边做的方法还有的缺点就是，口述所做的事情将会减慢用户的操作的速度，使得这样得到的绩效度量缺少对用户正常工作速度的代表性。其次，用户在口述他们想法的同时必然影响到他们解决问题的行为。

实验人员常常需要不断提醒用户，向他们提出类似“你正在想什么”“你认为这条信息是什么意思”（当用户已经注意到这条信息并且在花时间查看和考虑的时候）这样的问题，让用户大声说出他们这样的想法。如果用户问：“我能够这么做吗？”，实验人员不应该回答，但可以用反问的方法来让用户继续说话，“如果你这么做了你认为会有什么结果？”如果系统的反应让用户感到惊讶却没有说什么，实验人员就应该这样来提示用户，“这是你预料中的事情吗？”当然，遵循在用户使用系统时不要干扰用户这一通用的原则，实验人员不能在用户没有注意到某个消息的时候这样提示用户“你认为在屏幕底部的消息是什么意思？”

协同交互的方法： 边说边做的方法的另一种变形，让两个测试用户同时使用一个系统。它的主要优点在于，测试形式比只用单一用户进行的标准边做边说测试显得更为自然一点，因为人们习惯于在共同解决问题的时候把自己的想法说出来。协同交互的方法尤其适合对于儿童使用的用户界面的可用性测试，因为让孩童遵循边说边做的方法有点困难。

回顾式测试，如果在测试期间录了像，就可以让用户回顾录像的内容来收集额外的信息。在看录像带的时候用户不会那么紧张，偶执行测试任务时的紧迫感，因此会说出更多意见。当然，这种方法的缺点在于每个测试至少要用双倍的时间，因此这个方法不适用于用户报酬很高的情况下。

辅导方法，多少和其他测试方法有些不同，它在测试用户和实验人员之间有清楚的交互过程。测试前，测试用户可以问任何与系统相关的问题。有一种变形的辅导方法是从熟练的用户中选择一个人来作为辅导人员。设立这样一个单独的辅导人员，可以让实验人员来研究辅导人员是如何回答问题的。这种变形方法可以用来分析熟练用户担任的辅导人员对界面所形成的模型。当然，辅导方法通常关注的是新手用户，目的是发现这些用户的信息需求，以便提供更好的培训和文档资料，同时还能够帮助重新设计界面来避免这些问题。

10.其他可用性评估方法

(1)观察法：是所有可用性方法中最简单的方法，因为只需要访问一个或者几个用户，让他们使用系统和产品和做笔记即可。在进行观察的时候，观察人员自始至终应该尽量保持安静，让用户操作时感觉旁边没有人会比较自在。对于在观察过程中看到的无法理解用户的操作，我们应该把这些 行为记录下来，事后询问用户为什么要这样做，听取他们的解释。

(2)问卷调查和访谈：从可用性的角度来看，问卷调查和访谈属于间接的方法，因为两者都不对用户界面本身进行研究，而只是研究用户对界面的看法。

附一个用户界面满意度的问卷：QUIS(Questionare for User Interface Satisfaction),方法[Chin et al., 1988]。通常建议是用稍短的问卷获得更多的信息，对于较忙的用户，如果问卷短一些的话，能够得到填写的机会远远大于长问卷。

(3)焦点小组：是一个非正式的方法，用来在界面设计之前和经过一段使用后评估用户的需要和感受。在焦点小组中，请大约6-9个用户在一起讨论新的概念，和摸清一些问题，时间一般为一两个小时。焦点小组中有一个主持人，负责是小组的讨论集中在焦点话题上。主持人事先提出问题，小组中的用户在交互过程中，常常会流露出用户的自然反应，焦点小组的最大优点是能够对小组的动态变化和组织问题进行考察。焦点小组在参与讨论的人数上有严格要求，因为既要保证讨论的流畅，又要体现用户的不同观点，所以不能少于6人。

(4)记录实际使用情况：

记录数据指的是计算机自动收集的关于系统使用情况的详细统计数据。这是非常有用的，因为这既体现了用户是如何完成真实任务的，也是的从工作的不同环境下的大量用户那里自动收集数据变得相当容易。典型的界面日志文件包括：每个月用户使用每个功能的频率和各类事件（如错误信息）发生的频率。举个例子，Brandford等人曾记录并分析了在命令行式操作系统下用户发出的6112条错误命令，30%是由于拼写造成的，表明需要一种拼写校对器来协助系统用户输入命令。

与后续访谈相结合：用日志记录数据的方法存在的主要问题是，它值能展示了用户做了什么，而无法知道用户为什么这样做，既所谓“知其然而不知其所以然”。应该在记录数据后再结合其他方法，如访谈，通过给用户显示他们使用系统时记录的信息，请用户详细描述里面任何可能引发可用性的地方。

（5）

用户反馈：优点：

由用户主动提供，因此能够直接反应用户最关注的地方；反馈是一个持续的过程，所以不需要进行额外的收集工作；能够迅速反映出用户在需求、环境和想法上的改变，因为无论何时发生这种改变，都可以通过最新的反馈显示出来。

另外，许多软件公司都采用beta测试，就是把即将问世的产品发行给一小部分挑选出来的客户，让他们做出评价。Beta测试方法能及时获得用户反馈，以改进产品的第一个正式发行版。

11.可用性方法汇总：

可用性方法的组合：一般来说，可用性人员首先要从界面入手进行经验性评估，排除显而易见的可用性问题。重新设计界面后，经由用户测试，来检查反复设计的效果，同时也发现经验性评估未发现的问题。在经验性评估和用户测试之间进行选择主要有两个理由。第一个原因是经验性评估不需要用户参与就能够发现并消除系统或产品中存在的可用性问题，实际上，找到一定数目的测试用户并进行有计划的安排，有时并不容易。第二个原因是这两大类可用性评估方法所发现的可用性问题有明显的不同，这意味着两种方法可以互补而不会重复。

12.界面的标准：

(1)界面的一致性和标准有益于用户，一致性通常能够提高用户把使用某个系统的技能运用到另一个系统去的可能性。

(2)界面的一致性得益于软件商,这不仅能增加界面的美感，更够是设计人员后来可以依靠这一基本规范进行设计，把工作重点放在设计产品的独特方面，而不需要在界面设计中重复设计每一种交互设计。

(3)标准带来的不利因素：尽管完善的标准将会大大节省产品的开发费用，但要使标准达到优秀本身就是一个费用昂贵的过程，在标准得以使用之前，必须投入时间和财力去开发标准，这样一来就可能导致基于这种标准的产品开发被拖延。

13.国际化用户界面：

(1)相似图标：描述图标所要表示的物理对象。例如用信封图片表示电子邮件文件就使用了相似图标

(2)引用图标：描述一些图标对象，通过参照和类推的方法表达图标想要表达的概念。例如，用弹簧夹图片表示压缩工具。

(3)指定图标：指定图标只有通过约定才具有特殊的含义，交通图标就是指定图标，由于交通图标已经非常标准化，这些图标可以构成一个很好的计算机来源。