HE1: Match Between System and the Real World
1. 现实生活理念的模拟。使用显示生活中的文件夹，垃圾箱等概念到计算机系统中。
2. 现实生活中使用的语言：例：使用“abort”来提示用户是否要停止某项活动。
3. Common conventions。 惯性的使用。比如使用大号的字体来表示更为重要的东西。打印事件发生的时候，顺序也和现实生活中的习惯一样，读取时是从上到下，从左到右的顺序。
4. 由于文化的原因，不同的语言在打印的时候顺序也不一定全是一样的。
HE2: Visibility of System Status
1. Provide Feedback- Keep the User Informed About the Stages of a Process .在程序运行过程中，时常提醒用户程序已经进行到什么程度了。比如，当从程序中打开一个文件，在用户选择了File-Open 后，会弹出一个对话框。复制粘贴的时候也有一个蓝色的条条告诉我们已完成的进度。
2. Don‘t Make the User Guess。比如，在我们一次性打开很多文件的时候，每个文件的上边都会有这个文件的名字，因此我们就不会混淆。
HE3: Consistency and Standards.
1. Don’t Frustrate the User.对于人们已经习惯的事物入股出现与他的预想不一样的情况则会让用户不愉快
2. Maintain Platform Consistency.格式上的沿用。比如，File的位置总是在程序的最左的一项。
3. Maintain Application Consistency.警告或者是弹出的消息提示的位置应该总是在用户预想的位置，它的外表和显示的内容都应该是用户所熟悉的。
HE4：User Control and Freedom
1. Let the user be in control. 使用户具有控制权，而且要注意使用Message 时的预期，应该暗示计算机已经就绪或者是申请而不是命令或者是威胁。
2. Provide an Undo Mechanism .用户应该是可以回到程序的某一个步骤并且回到当时的状态。比如说有的程序只许回到上一步，有的允许回溯很多步。“Reset “或者”Factory Settings“都是这
一点的体现。
3. Require Confirmation.需要确定，当一个不可回溯的操作要执行的时候，应该要先警告用户。
4. Provide an escape route. 提供一个紧急出口。典型的办法就是提供一个“Cancel“按钮。
HE5: Flexibility and Efficiency of Use
1. Provide Keyboard Shortcuts.很多时候，使用快捷方式要比鼠标操作快的多。
2. Allow for Customization.给予有特殊需要的用户以适合
的运行环境，比如说对于左手使用有困难的用户允许他们把快捷键移到键盘的右边。
3. Not Every Facet of Every Heuristic Applies to Every Interface.不用吧HE中的每个方面都应用到每个界面上去。
HE6: Error Prevention
1. Prevent Errors.不允许不合法的操作。比如在windows 操作时在某些时刻有些功能呈灰色。不允许用户操作。或者是采用下拉列表代替用户输入。
2. Warn Users about Potentially Destructive Actions and Require Confirmation. 必须使用用户使用的语言来写warning message。并且提供给用户取消命令的选项。避免使用双重否定的句子，特别是在警告中。
HE7: Aesthetics and Minimalist Design.
1. Minimalist Design.最小化冗余信息。注意留白。限制用户一次需要注意的东西的数量，减少用户每次需要操作的空间数量。把相关的任务放在一起。
HE8: Recognition Rather than Recall.显示左右可供用户使用的操作和对象，不要期望用户去记住一个页面的东西，当他转向另一个页面的时候。
1. Show All Objects and Actions that are Available. 比如人们可能不会记得去某个小镇时路上的里程碑上写的什么，但是可能自己开车就过去了。人们并不喜欢记忆。
2. Reduce Demands on Memory.不要期待用户转向另一个界面是仍记得原界面的信息，不要让用户去回忆，而是显示给他所有他能
进行的合法操作。在任何时候，只给用户一定两需要他做出反应的事物。使用用户长时间以来习惯的东西如“file“，”open“，少使用新词如”chunck“
HE9: Help and Documentation
1. Help vs. Documentation .Documentation 是对系统的整体的描述，help 经常是当用户遇到问题时给出建议。
2. Always Available. 把help和documentation放在一般程序放他们的位置。比如在windows 中，help总是最右边一个按钮。
3. Easily Searchable.最好有按字母顺序的索引。当然，也可以有其他的方法。
4. Relevant to the Task.提供的信息必须与现在用户所处的状态是相关的。
HE10: Help Users Recognize , Diagnose, and Recover from Errors.
1. Keep the User Informed About Errors and How to Recover From them.无论何时，让用户了解错误的信息，并且知道如何恢复运行。例如用户打不开一个文件的时候，应该有错误信息提示用户是为什么打不开，这时候要怎么做。
一个UAR的格式：
1. UAR Identifier：必须是独一无二的标号（可以用鉴定人来命名，也可以用鉴定种类来命名 eg : HE6 or TA89，CS1 or JK75），在标号后面接Problem或是Good Feature。
2. Succinct Description of the Usability Aspect：UAR的名字，这个名字应该简短，但应该能反映问题（不是解决方案----因为问题可以通过集中解决的方式来解决）并且具有可区分性。（EG: Press-Me label too small）
3. Evidence for the Aspect: 有用户能够理解这份报告含义的实例。对于一份HE报告，这个可以是一段屏幕截图和他所违反或遵守的启发式原则。对一份think-aloud study，这个通常是屏幕上显示什么，用户作了什么，屏幕反馈了什么，用户如何评价。
4. Explanation of the Aspect：问题发生的原因，记得从分析的角度，而非评估的角度（对于he，则说什么现象遵循了什么原则，对于TA来说则说明某个现象为什么会发生）。（the system was in editing mode, but the user thought it was in run mode
because there isn't a noticeable difference between the modes on the screen）
5. Severity of the Problem or Benefit of the Good Feature：解决问题或是保留某一方面的意义（这些特点用户有多频繁的使用，这些特点会不会影响新手的使用）
6. Possible Solutions and Potential Trade-offs：如果this aspect是一个问题的话，这块就用来解决问题，不必问题一提出就试图去解决它。另外之一应该列出潜在的design trade-offs。（For instance, the problem might be that there are no keyboard shortcuts for items on a menu in a mail system and you propose CTRL-S for SEND. A design trade-off you should record is that CTRL-S might already be used for another menu item (e.g., SAVE), so all shortcut keys need to be examined before any design changes are made.）
7. Relationship to Other Usability Aspects：用户界面的各个aspect都是相关联的，这个部分就是用来表明和其他部分的联系的，注意写全UARs point，比如说#1和#30相关联，则要在双方的文件里都提到。
课程主要内容（其中三个部分）
1。面向用户设计概论
面向用户编程和测试的基础：
迭代设计，基本迭代设计观点，基本认知心理学
构造界面的工具：
VB编程环境，用VB编写，调试代码
评估界面可用性方法：
基本的HE,TA观点，如何编写UAR
2。用VB构造界面
LABEL,BUTTON,CHECKBOX,RADIOBUTTON,LISTBOX,COMBOBOX,UPDOWN AND SCROLLBAR,TEXTBOX,GROUPBOX,TABBED PAGE,MENU CONTROLS；3。THINK-ALOUD可用性测试
vb编程不多做叙述，都是些控件的具体属性及用法，查查MSDN就都了解了
启发式的评估方法
1. Heuristic evaluation(HE)是在开发阶段的早期分析用户
界面可用性的工具。现在他已经发展成为一门学科。
（HE’sheuristics, or usability principles）理解
heuristics概念。Heuristics是从过去30年的用户界面设计和评估的实际经验中发展起来的，虽然可以从认知心理学的角度来了解它，但它不起源于认知心理学。本章节就是扼要讲述这些原则。
2. Overview of Procedure for Using Heuristics，启发式
的评估方法的执行过程就是several people用Heuristics来检查用户界面设计（设计可以使任意阶段的设计，草图，原型和最后结果都是设计，在越早阶段用Heuristics评估，损失越小）是否都符合要求。通常情况下，界面越复杂，需要评估的人数越多。
3. Heuristics最有用的是在设计的时候用到它的观念，从早
预防。
Heuristic Evaluation的几个原则
1. Visibility of System Status “电脑所处的状态的可见
性，电脑在做什么，电脑的输入，电脑如何处理”，声音，图像等方式提醒用户。
2. Match Between System and the Real World。”现实世
界的惯例，用户完成任务的方式，环境以及通用规则的使用” 这些使用利用了用户long-term memory，使他们能够很快的熟悉系统。
3. User Control and Freedom用户要有足够的“自主权”，
及时的恢复错误和进行其他处理。
4. Consistency and Standards：相同的信息应该以相同的
方式表示，不同的信息以不同的方式表示。
5. Error Prevention，最典型的错误防止是“用可选动作列
表来代替用户自行输入操作命令”，这个错误特别容易发生。6. Recognition Rather Than Recall：诸如页面切换等问题
时，应该提供给用户尽量全面的信息让用户选择，而不是期望用户去记忆某些信息。
7. Flexibility and Efficiency of Use：对于高级用户，快
捷健的设置和特定的界面设置很有必要，这些可以加速人机交互。
8. Aesthetics and Minimalist Design
9. Help Users Recognize, Diagnose, and Recover from
Errors，当发生错误的时候应该准确告知用户错误之处以及如何恢复错误误。
10. Help and Documentation，用户能够明白如何使用某一功
能。
将这些原则牢记在脑海中，并且用这些原则去检验你的设计。
Basic Think-Aloud可用性测试方案
1. Think-aloud usability testing（让恰当的用户以任意方
式使用你的界面原型，说出那里有问题，你静静的听或用录像带，记录下这些问题，然后解决。原型通常指建立好的动态界面原型，而非稿纸上的原型）是通过实践经验发展而来的，它是用户界面评估最有效的方法。
2. HE是设计者在设计时使用的预防措施，但是设计者毕竟是设计者，不能完完全全站在用户角度，所以这里还需要和THINK-ALOUD 结合使用。
Heuristic Evaluation
启发式评估（Heuristic Evaluation）是让一小批评估人员评估用户界面以及判断这些界面是否符合已经确立的可用性（Usability）规则，以发现界面设计中的可用性问题，并把它们作为界面再设计过程中所重视问题的可用性方法。
一般而言，启发式评估法是由多个评估人员对界面进行评估以提高效率，也避免单个评估人员的局限性。在评估过程中，评估人员多次查看界面，检测各类界面，并把他们与一系列已经认可的可用性原则进行比较。这些原则包括用来描述易用界面通常具备的共同特点的通用原则和对某特定产品的特殊可用性原则。启发式评估法过程中，每个评估人员分别单独检查界面。只有当所有的评估都结束之后，评估人员才可以交流并将他们的发现整合在一起。这是为了确保每个评估人员独立的无偏见地进行评估。
评估的结果可以通过两种方式记录：1、让每个评估人员做书面报告；2、让所有评估人员边仔细查看界面边口述他们的意见给一个指定的评估观察员。
启发式评估后输出的结果是一系列在评估人员眼里违背了可用性原则的用户界面上的可用性问题。评估人员不能简单地说他们不喜欢什么，他们必须依据可用性原则解释为什么不喜欢。评估人员应该尽可能地做到详细明确，并将每个可用性问题单独列出来。启发式评估虽然无法提供系统的方法去找到解决可用性问题的方法，也不能提供一个途径去检测任何再设计的质量。但是，因为启发式评估过程中利用已确立的原则解释了每个发现的可用性问题，而且这些可用性准则
是良好的交互系统中所提取出来的，所以制定一个修正的设计方案变得相当容易。
启发式评估与传统用户测试的差异体现在两个方面：1、观察者在评估过程中回答来自评估人员的问题的自动自发性；2、评估人员在使用用户界面的时候获得的提示和线索的程度。在传统用户测试中，人们一般想要发现用户在使用界面时所犯的错误，用户需要通过使用系统来找到回答他们问题的答案，因此，测试人员只愿意提供绝对必要的帮助。启发式评估则相反，评估过程中需要观察者回答评估人员的问题以使他们更好地评定用户界面在关于这一领域方面的可用性，当评估人员在使用界面时遇到问题的时候，他们可以获得提示去继续操作从而充分利用评估时间。
启发式评估被明确地成作是一种“廉价可用性工程方
法”（Discount Usability Engineering Methodology）方法。研究（Jefries et al. 1991）已经明确证实，启发式评估是一种非常有效的可用性工程方法。
评估结果记录方式：
1.每个评估人员做书面报告；
2.所有评估人员边仔细查看界面边口述他们的意见给一个指定的评估观察员。
输出结果：一系列在评估人员眼里违背了可用性原则的用户界面上的可用性问题，并依据可用性原则解释为什么。（虽然1. 无法提供系统的方法去找到解决可用性问题的方法； 2. 不能提供一个途径去检测任何再设计的质量；3. 因为利用已确立的原则解释了每个发现的可用性问题，使制定一个修正的设计方案变得相当容易）。
启发式评估的通用准则
?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.必要的帮助提示与说明文档
启发式评估
启发式评估（专家评审）这种诊断法，是由专家来扮演经验不足的用户，提出用户使用系统或界面时，可能出现遇见的问题。评审会基于遵守一系列的准则(heuristics)。作为一种“打折”的方法，启发式评估是为了快速修改、让交付物作为迭代设计的过程中的一部分。References
参考资料
"启发式评估"，可用性检查方法 ，J. Nielsen 和 R. Mack，John Wiley and Sons, Inc，1994，第25至62页
Getting Ready (Project Lead activities)
准备(项目负责人)
· 选定和确定评估时使用的可用性准则 (heuristics)
· 选择你的评估团队。由三到五个可用性专家各自检查系统
· 计划地点、日期和每个可用性专家评定的时间
· 准备或收集材料，让评估员熟悉系统的目的和用户。材料应包括：受众分析、系统规格、用户任务、用例场景等等。把这些材料分发给评估员
· 设计评估和记录的策略。是基于个人，还是小组来评估系统？指派一个共同的记录员还是每个人记录自己的？
Evaluating the system (Evaluator activities)
评估系统(评估人员)
· 尝试并建立对系统范围的感知
· 回顾所提供的材料，熟悉系统设计。执行你认为完成用户任务时会被执行到的用户操作。
· 发现并列出系统中任一你觉得违背准则的地方。列出所有你记录的问题，包括可能重复的。一定要清楚描述你发现了什么、在哪里发现的。
Analyzing the results (group activity)
分析结果(评估团队)
· 回顾每个评估员记录的每个问题。确保每个问题能让所有评估员清楚明白。
· 建立一个清楚的图表，把相似的问题分组
· 根据定义的准则评估并判定每个问题
· 基于对用户的影响，判定每组问题的严重程度（参考严重性评级部分）
· 确定解决问题的建议。 确保每个建议基于评估的准则和设计原则Reporting the results (Team Leader activity)
汇报结果(团队负责人)
· 汇总评估员团队会议的结果。每个问题应该有一个严重性级数，可用性观点的解释和修改建议
· 用一个容易阅读和理解的格式，在报告中组织所有出处、目标、技术、过程，和发现的结果。你可以根据评估原则(heuristics)来组织你的发现的问题。记得一定要记录系统或界面的正面特性
· 确保报告包括了让项目团队负责人反馈的机制，以了解开发团队是如何使用这些信息的
· 让你团队的另一个人复审的报告，并由团队领导认可
Debriefing (Team Leader activity)
汇报(团队负责人)
· 若客户要求，安排一个时间和地点做口头报告演示
· 聚焦于主要的可用性问题，以及可能的解决方案
· 突出设计的正面特性
· 若需要，让项目团队负责人补充
Severity Rating Scales
严重性评级尺度
你可以决定使用以下这些严重性评级尺度的任一种，或者建立自己的尺度以适合项目的需要
Five-point rating scale
五分制
1 辅助的，不会影响系统的可用性，可能的话修正它
2 次要的，用户能轻易处理问题，较低的优先级
3 中等，用户在这问题上遇到阻碍，不过能迅速适应，中等优先级
4 重要，用户遇到困难，不过能够找到解决方法，可强制在系统发布
前修正。如果问题无法在发布前修正，确保帮助中清楚向用户表明了解决方法
5 灾难性的，用户无法进行他们的工作，需强制修正
Three-point scale
三分制
· 辅助的或次要的，造成较小的困难
· 造成使用的一些问题或使用户受挫，不过能够解决
· 严重影响用户使用，用户会失败或遇到很大的困难
普渡大学可用性测试检查表
使用说明：本调查表共有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）用户是否启动流程控制？