什么是启发式评估？
启发式评估是专家评审法的一种，就是让几个评审人员根据一些通用的可用性原则和自己的经验来发现系统内潜在的可用性问题。每一个评审人员可以发现35%的可用性问题，而5个评审人员能找到大约75%的可用性问题。
启发式评估该选择由什么样的人来进行？
启发式评估是专家评审法的一种，选用具有可用性知识或选用具有和被测试系统相关专业知识的“专家”，具有以上两种知识的人是最合适人选，他能多发现约20%的可用性问题。
启发式评估如何进行？
每一个评审人员进行1-2小时的使用系统，之后提供一份独立的报告，在报告中应包括可用性问题的描述，问题的严重性以及改进的建议。
启发式评估的通用准则
?Visibility of system status.可视性原则
?Match between system and real world.系统应符合用户的真实世界 ?User control and freedom.用户有自由控制权
?Consistency.一致性原则
?Error strategy.有预防用户出错的措施
?Recognition rather than recall.要在第一时间让用户看到
?Flexibility and efficiency of use.使用起来灵活且高效
?Aesthetics and minialist design.易读性
?Help users recognize, diagnose, and recover from errors.给用户明确的错误信息，并协助用户方便的从错误中恢复工作
?Help and Documentation.必要的帮助提示与说明文档
附：普渡大学可用性测试检查表
使用说明：本调查表共有100题，回答每一个问题时按照以后三个步骤： （a）请评估每一个问题是否适用于所评审的系统。如果不适用，跳到下一题。如果适用，请继续回答。
（b）对于所评估的系统，请评价该问题的重要性（1是最不重要的，3是最重要的）
（c）评价系统在该问题上的表现（1是非常糟糕，7是非常好），如果不存在，请选择不存在项
1.兼容性
1）光标的控制是否符合光标的移动？
2）用户控制的结果是否符合用户的期望？
3）所提供的控制是否符合用户的技能水平？
4）界面的编码（例如，颜色、形状等）是否为用户所熟悉？
5）用词是否为用户所熟悉？
2.一致性
6）界面颜色的编码是否符合常规？
7）编码是否在不同的显示及菜单上都保持一致？
8）光标的位置是否一致？
9）显示的格式是否一致？
10）反馈信息是否一致？
11）数据字段的格式是否一致？
12）标号的格式是否一致？
13）标号的位置是否一致？
14）标号本身是否一致？
15）显示的方向是否一致？（漫游或卷动）
16）系统要求的用户动作是否一致？
17）在不同的显示中用词是否一致？
18）数据显示和数据输入的要求是否一致？
19）数据显示是否符合用户的常规？
20）图形数据的符号是否符合标准？
21）菜单的用词和命令语言是否一致？
22）用词是否符合用户指导的原则？
3. 灵活性
23）是否可以使用命令语言而绕过菜单的选择？
24）系统是否有直接操作的功能？
25）数据输入的设计是否灵活？
26）用户是否可以灵活地控制显示？
27）系统是否提供了灵活的流程控制？
28）系统是否提供了灵活的用户指导？
29）菜单选项是否前后相关？
30）用户是否可以根据他们的需要来命名显示和界面单元？
31）系统是否为不同的用户提供了好的训练？
32）用户是否可以自己改变视窗？
33）用户是否可以自己命名系统命令？
34）系统是否允许用户选择需要显示的数据？
35）系统是否可以提供用户指定的视窗？
36）为了扩展显示功能，系统是否提供放大的功能？
4. 可学习性
37）用词是否清晰？
38）数据是否有合理的分类，易于学习？
39）命令语言是否有层次？
40）菜单的分组是否合理？
41）菜单的顺利是否合理？
42）命令的名字是否有意义？
43）系统是否提供了无惩罚的学习？
5. 极少化的用户动作
44）系统是否为相关的数据提供了组合输入的功能？
45）必要的数据是否只需要输入一次？
46）系统是否提供了默认值？
47）视窗之间的切换是否容易？
48）系统是否为经常使用的控制提供了功能键？
49）系统是否有全局搜索和替代的功能？
50）菜单的选择是否可以使用点击的功能？（主要的流程控制方法）
51）菜单的选择是否可以使用键入的功能？（辅助的控制方法）
52）系统是否要求极少的光标定位？
53）在选择菜单时，系统是否要求极少的步骤？
54）系统是否要求极少的用户控制动作？
55）为了退到更高一级菜单中，系统是否只需要一个简单的键入动作？
56）为了退到一般的菜单中，系统是否只需要一个简单的键入动作？
6. 极小的记忆负担
57）系统是否使用了缩写？
58）系统是否为输入分层次的数据提供了帮助？
59）指导信息是否总是可以得到的？
60）系统是否为序列的选择提供了分层次的菜单？
61）被选的数据是否有突出显示？
62）系统是否为命令提供了索引？
63）系统是否为数据提供了索引？
64）系统是否提示在菜单结构中的当前位置？
65）数据是否保存简短？
66）为选择菜单使用的字母代码是否经过认真的设计？
67）是否将长的数据分成不同的部分？
68）先前的答案是否可以简便的再利用？
69）字母大小写是否等同？
70）系统是否使用短的代码而不使用长的代码？
71）图符是否有辅助性的字符标号？
7. 知觉的有限性
72）系统是否为不同的数据类别提供不同的编码？
73）缩写是否清晰而相互不同？
74）光标是否不同？
75）界面单元是否清晰？
76）用户指导的格式是否清晰？
77）命令是否有清晰的意义？
78）命令的拼写是否清晰？
79）系统是否使用了易于分辨的颜色？
80）目前活动的窗口是否有清楚的标识？
81）为了直接比较，数据是否成对的摆在一起？
82）是否限制语音信息使用的数量?
83）系统是否提供了一系列相关信息？
84）菜单是否和其他的显示信息有明显的区别?
85）颜色的编码是否多余？
86）系统是否提供了视觉上清晰可辨的数据字段？
87）不同组的信息是否明显分开？
88）屏幕的密度是否合理？
8. 用户指导
89）系统反馈的错误信息是否有用？
90）系统是否提供了“取消”的功能？
91）错误的输入是否被显示出来？
92）系统是否提供了明确的改正错误的方法？
93）系统是否为控件输入提供了反馈？
94）是否提供了“帮助”
95）一个过程的结束是否标志清楚？
96）是否对重复的错误有提示？
97）错误信息是否具有建设性并提供有用的信息？
98）系统是否提供了“重新开始”的功能？
99）系统是否提供了“撤销”的功能？
100）用户是否启动流程控制？
如何进行启发式评估
2007-09-21 15:29
原文作者：Jakob Nielsen
译者：初心不忘
原文链接：How to Conduct a Heuristic Evaluation
启发式评估（Nielsen and Molich, 1990; Nielsen 1994）是可用性工程的一种方法，目的是为了找出用户界面设计中的可用性问题，因此启发式评估能够被当成是反复设计过程（an iterative design process）中的一部分。启发式评估是指少数几个评估者检查界面，并判断界面是否符合公认的可用性原则（即“启发式”）。
大体上来说，仅让一个人来做启发式评估是困难的。因为单独一个人永远也不可能找出界面中的所有可用性问题。幸运的是，从许多不同的项目得出的经验来看，不同的人会发现不同的可用性问题。因此，通过多个评估者，可能大大提高启发式评估的效果。图1显示了启发式评估安全研究的一个实例，19个评估者发现了语音回复系统的16个可用性问题（Nielsen, 1992）。图1中每一个黑色的广场代表了一个评估者发现的一个可用性问题。该图清楚地显示出不同的评估者发现的问题有相当大的部分不是重叠的。很显然，有的可用性问题很容易被发现，几乎每个评估者都找出了这样的问题，但是，也有一些问题只被少数评估者所发现。并且，不能仅仅依靠评估者的发现来判断他们是否是好的评估者。首先，不能保证评估者在每一次评估中都是最好的评估者；其次，有一些很难被发现的可用性问题是那些没有发现许多可用性问题的评估者发现的（可见图1中最左边的一栏）。因此，没有必要在每次评估中都包括多个评估者（下文将会讨论评估者的最佳人数）。我的建议是使用3至5名评估者，因为不能够通过使用更多的
人数来获得更多额外的信息了。
图1
图1显示了每个评估者在评估银行系统中发现的可用性问题。横排表示19个评估者，竖列表示16个可用性问题。方框体代表可用性问题：黑色代表评估者发现了该问题，而白色则代表评估者没有发现该问题。发现可用性问题最多的评估者在最底一排而发现可用性问题最少的评估者在最上面一排；最容易发现的可用性问题显示在最右边的列而最难被发现的可用性问题显示在最左边的列。
在进行启发式评估时，每个评估者单独地检查界面。当所有的评估者都完成了他们的评估后，将他们聚集在一起进行讨论并整合他们的发现。这一程序是非常重要的，目的是确保每个评估者的独立性和无偏见地进行评估。评估结果可以通过评估者自己记录成手写的报告或者当他们在检查时，将评估结果口述给一旁的观察者。手写报告的优点是能够呈现评估较正式的评估结果，但是需要评估者花费更多地额外劳动。使用观察者增加了每一个评估的费用，但是减少了评估者的劳动量。另外，评估结果在最后一次评估之后很快就可用，因为观察者仅需要理解和整理他自己的个人笔记即可，不需要整理其他人写的报告。并且，当界面出现问题的时候，观察者可以帮助评估者，例如一个不稳定的原型，当评估者在专业领域里有所限制或者需要对界面做出解释时。
在用户测试的情景下，观察者（通常称变实验者）有责任解释用户的行为以推断这些行为如何与界面设计的可用性问题相关的。这就使得用户完全不知道用户界面设计的情景下，用户测试成为可能。相反，在启发式评估中，分析用户界面是评估者的职责，因此观察者只需要记录评估者关于界面的评论，而不需要去解释评估者的操作。
另外两个启发式评估与传统用户测试的不同是观察者回答评估者问题的意愿和评估者在操作界面时能够获得的提示的程度。对于传统用户测试来说，观察者通常想发现用户在使用界面时发生的错误；因此，除了绝对需要的东西之外，实验者不太愿意提供更多的帮助。同样，要求用户通过使用系统来发现他们问题的答案而不是从实验者那里获得答案。而对于一个领域特殊性应用的启发式评估，拒绝回答评估者关于此领域的问题是不现实的，尤其是评估者中没有领域专家。相反，回答评估者的问题能够让他们更好的评估用户界面的可用性问题。类
似的，当评估者在使用界面遇到问题时，实验者可以告诉他们如何进行下去以便不在与界面的机制进行斗争时浪费宝贵的评估时间。很重要的一点需要指出，不需要给评估者帮助除非他们明确其困难或者提出关于可用性问题的疑问。
通常，一次启发式评估需要持续1到2小时。对于较大和较复杂的界面来说，更长的评估是必要的，但是最后将评估分成若干次进行，在每个小评估中只关注界面的一部分问题。
在评估过程中，评估者数次仔细检查界面和不同的对话（dialogue element）并将其与公认的可用性原则比较。这些启发式原则是描述可用界面通用属性的一般规则。另外，评估者除了要参考通用的启发式原则外，他们也需要考虑其他的与特殊的对话相关的可用性原则或者结果。并且，有必要开发出类别特殊性的启发式原则以适应特殊的产品。一个建立补充的启发式原则的方法是进行竞争性分析并在已经存在的类别下进行用户测试以试图抽象出可以解释可用性问题的原则（Dykstra, 1993）。
原则上，评估者自己决定如何评估界面。然而，一般的建议是，他们至少检查界面两次。第一次的目的是获得交互流程的总体感觉和对系统的总体了解。第二次，评估者需要集中在详细的界面，以了解它们是如何适合更大的整体。
因为评估者不用系统完全真实的任务，所以，在纸面上来评估用户界面是可行的（Nielsen, 1990）。这使得启发式评估能够在可用性工程生命周期的初期就能够适用。
如果系统是为大部分人群设计的“走过来即用的” （walk-up-and-use）或者评估者是领域专家的话，在评估者使用系统的时候不提供进一步的帮助。如果系统是领域依赖性的或者评估者在系统所在的领域内完全是新手的话，向评估者提供帮助有利于帮助他们使用系统。一个有效的方法是向评估者提供一个典型的使用情景，列出用户在完成现实任务时会采用的不同步骤。这一情景可以在对实际用户的任务分析和他们工作的基础上建立。
使用启发式评估得到的结果是一个可用性问题的列表，与之相关的是评估者需要指出这些问题违背了哪些可用性原则。仅仅是简单地说他们不喜欢什么是不够的，他们需要参考启发式原则解决为什么他们不喜欢。评估者需要尽可能的详细并且单独列出每一条可用性问题。例如，如果在一个对话上有三个错误，这三个错误需要针对不同的可用性原则分别列出，并解释为什么每一个部分存在可用性问题。单独记录可用性问题有两个原因：其一，在一个对话上，存在重复问题的风险，即使完全重新设计界面，除非人们已经完全了解所有的问题；其二，在一个界面不可能解决所有的可用性问题或者通过全新的设计来替换这些问题，但是如果我们知道了所有的问题，解决其中的一些问题是可能的。
启发式评估不能产生一个系统的方法来解决可用性问题或者评估重新设计的大概质量。但是，因为启发式评估的目的是在参照可用性原则的基础上解释每个发现的可用性问题，所以产生一个修正的设计是相当容易的。另外，很多可用性问题只要被发现是很容易被解决的。例如，如果问题是用户不能将信息从一个
窗口复制到另一个窗口，那么解决方案很显然就是加入一个复制的功能。
扩展启发式评估以获得设计建议的一个方法是在最后的评估结束后，进行一个询问环节（ debriefing session）。参与者包括所有的评估者、观察者及设计者代表。询问环节主要以头脑风暴的方式进行，关注点在于讨论主要可用性问题和设计上的一般问题并给出修改建议。询问也是讨论设计积极方面的一个良好机会，尽管启发式评估并没有强调这一点。
启发式评估明确地被看作是一种“打折可用性工程”（discount usability ）的方法。独立研究（Jeffries et al., 1991）证实启发式评估是一种非常有效的可用性方法。我的一个案例研究发现，一个启发式项目的利益成本比率为48：使用该方法的成本为10，5000美元，而预期收益约为500，000美元（Nielsen, 1994）。作为一种打折可用性工程方法，启发式评估不能确保提供最完美的结果或者发现一个界面的所有可用性问题。
-
参考文献：
Dykstra, D. J. 1993. A Comparison of Heuristic Evaluation and Usability Testing: The Efficacy of a Domain-Specific Heuristic Checklist. Ph.D. diss., Department of Industrial Engineering, Texas A&M University, College Station, TX.
Jeffries, R., Miller, J. R., Wharton, C., and Uyeda, K. M. 1991. User interface evaluation in the real world: A comparison of four techniques. Proceedings ACM CHI'91 Conference (New Orleans, LA, April 28-May 2), 119-124.
Molich, R., and Nielsen, J. (1990). Improving a human-computer dialogue, Communications of the ACM 33, 3 (March), 338-348.
Nielsen, J. 1990. Paper versus computer implementations as mockup scenarios for heuristic evaluation. Proc. IFIP INTERACT90 Third Intl. Conf. Human-Computer Interaction (Cambridge, U.K., August 27-31), 315-320.
Nielsen, J., and Landauer, T. K. 1993. A mathematical model of the finding of usability problems. Proceedings ACM/IFIP INTERCHI'93 Conference (Amsterdam, The Netherlands, April 24-29), 206-213.
Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1-5 April), 249-256.
Nielsen, J. 1992. Finding usability problems through heuristic evaluation. Proceedings ACM CHI'92 Conference (Monterey, CA, May 3-7), 373-380.
Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.),
Usability Inspection Methods. John Wiley & Sons, New York, NY.