其实启发式评估（Heuristic Evaluation）在用户体验方法论中久负盛名，但是在中文圈目前还缺少足够的关注。虽然启发式评估听上去很高大上，但是其实所谓的“启发式 Heuristic”指的就是来源于经验的，试探性的，用大白话说就是靠感觉，
当然，设计师的感觉会比普通用户更准确更全面，有行业经验的专家也能替提供额外的视角。
启发式评估是一套 UX 设计师可以从入门用到资深的实用法则，甚至可以称之为万金油法则。这种方法用起来简单快速，成本低廉，对于评估者要求也不高，最关键的是还很有效。当然缺点也显而易见：只靠 10 条笼统的法则，又受制于评估者自身的经验和知识，很难全面地洞察，并且有时可能会提出不相关甚至错误的建议。
然而瑕不掩瑜，我还是推荐每个 UX 设计师/用研都去学习掌握这个方法，因为当临近截稿日/没钱做测试/找不到测试用户/需要快速迭代的时候，你会发现有这么一个方便的工具能救你于水火之中。
— -
启发式评估最早由雅各布·尼尔森和 Rolf Molich 在 1990 年提出雏形，后来经过大量用户测试佐证，在 1994 年发表了后来业界有名的[用户界面设计的 10 条可用性法则](https://www.nngroup.com/articles/ten-usability-heuristics/)。
我在应用这一方法的时候，受到了 Hsin-Jou Lin 的启发，做了一套简易版的模版，因为团队规模比较小，所以去掉了一些元数据（meta data）的部分，然后将 10 条法则翻译成大白话，便于不擅长英语的设计师理解，毕竟 heuristic 本身就代表一种经验的总结，应当是越通俗易懂越好。
由于这 10 条法则过于笼统，因此我加入了 Gomez et al. 的扩充版清单，新增了156 条子法则，可以一一对照。虽然 Gomez 清单中有部分针对网页而不是 app 的法则，但是也可以用来参考，各取所需。
还有很重要的一点，法则是灵活的，规则是可以打破的。这套方法论适合用来做评估，但是并不适合在发散思维的阶段当作设计标准。
首先是 10 条法则：
1. 显而易见的系统状态
系统通过及时的反馈来解答用户“我是谁、我在哪、我在干什么？”这 3 个问题。
系统状态反馈：
（1）每个操作是否都有某种形式的系统反馈？
（2）如果使用弹出窗口显示错误消息，窗口是否遮挡了原错误位置？
（3）对于连续多页的数据录入页面，每个页面是否标记了与其他页面的关系？
（4）概括、总结性（high）的内容是否放置在较高层级（一级、二级等）的位置？
地点信息：
（5）Logo是否有意义，可识别且足够明显？
（6）是否提供了查看详细信息的链接（例如企业信息，网站信息，网站管理员等等）？
（7）也没有联系方式？
（8）在文章，新闻，报告中……也没有写清楚“作者”、“来源”、“日期”、“评论”等信息？
响应时间：
（9）响应时间是否适合用户的认知处理速度？
（10）响应时间是否适合该任务？
（11）如果系统的响应时间存在明显的延迟（大于15秒），那么用户是否能够随时了解系统进度？
（12）减少等待时间/延迟；
选择/输入数据：
（13）菜单或对话框中是否存在关于可选项的视觉反馈？下同：
— GUI菜单可以使选择的项目显而易见吗？
— GUI菜单是否明显表明是否可以取消选择？
— 菜单或对话框中是否存在关于光标当前处于哪个选择的视觉反馈？
— 如果可以在菜单或对话框中选择多个选项，是否存在关于已选择了哪些选项的视觉反馈？
（14）图标的当前状态是否清楚？
（15）选择或移动对象时是否存在视觉反馈？
（16）链接可识别吗？根据状态（已访问、可点击）有任何区分吗？
2. “入乡随俗”
“入乡随俗”指系统要以一种用户熟悉的姿态展现，使用熟悉的语言、表达、概念等，避免术语和生造词。遵守约定俗成的规则，避免违和感。
隐喻象征/心理模型：
（17）使用隐喻象征（metaphor）；
（18）图标是否具体且熟悉？
（19）如果将形状用作视觉线索，是否符合文化习俗？
（20）所选颜色是否与对该颜色代码的普遍期望相对应？
导航结构：
（21）如果站点使用分层（hierarchical）结构，深度和高度是否平衡？
（22）是否有导航图，也称为站点地图或目录；
菜单：
（23）在确定用户，菜单选项名称和任务变量的情况下，菜单选项是否以最合理的方式排序？
（24）菜单选项是否进行了易于理解的分组？
（25）菜单标题是否在语法上平行？
（26）在导航菜单中，是否控制了选项的数量以避免内存过载？
容易性：
（27）相关和相互依赖的字段是否出现在同一页面上？
（28）对于 Q&A 界面，问题是否用清晰，简单的语言陈述？
（29）使用的语言是否与目标用户说的相同？或者，用来命名菜单的术语是否与用户的任务范围一致？
（30）语言简洁明了吗？或者，语言是否避免使用计算机术语？
（31）网站是否遵循“ 1 段文字 = 1 个想法”的规则？
数字信息输出：
（32）系统是否自动输入前导（leading）或尾随（trailing）空格以对齐小数点？
（33）系统是否自动为货币加入货币符号和小数点（角分位）？
（34）系统是否自动为大于 9999 的数字添加千分位逗号？
（35）整数是右对齐，实数是十进制的吗？
3. 给用户探索和犯错的自由
用户会不断摸索你的产品，摸索时难免犯错，因此当错误发生时应该提供简单的恢复途径。通过提供可逆的操作，比如“撤销”和“恢复上一次操作”，让用户可以自由探索。
可探索的界面：
（36）用户可以在字段或对话框选项之间前后移动吗？
（37）如果系统具有多个数据输入页面，用户可以在每个页面之间来回移动吗？
（38）如果系统有 Q&A 界面，用户可以返回上一个问题或者跳到下一个问题吗？
（39）清楚标示的出口；
（40）整体网站结构是以用户为导向的吗？
（41）有没有告知用户自己位置的方法，以及撤销跳转或导航的操作？
部分个性化：
（42）用户可以设置自己的系统，会话，文件和屏幕默认设置吗？
流程确认：
（43）用户的任务完成后，系统是否在开始下一步之前等待用户的确认？
（44）是否提示用户确认具有严重破坏性后果的操作？
撤消/取消：
（45）用户可以轻松地撤销其操作吗？
- 可能导致严重后果的功能键具有撤消功能吗？
- “撤消”操作的对象是单个操作、单次输入、还是一组完整的操作？
（46）用户可以取消正在进行的操作吗？
菜单控件：
（47）如果系统具有多级菜单，是否存在允许用户返回到上一级菜单的机制？
（48）菜单是较宽的（菜单上的许多同级项目）而不是较深的（许多菜单级别）？
（49）如果用户可以返回上一级菜单，是否可以更改其之前的菜单选择？
4. 一致性，连贯性，标准化
使用标准且一致的表达，避免歧义。不要让用户猜测类似的词语、条件、操作是不是在讲同一件事情。注意不同系统有不同的习惯。
设计一致性：
（50）是否有节制的吸引用户注意力？
（51）强度：仅两个级别；
（52）颜色：最多 4 种（仅偶尔使用的其他颜色）；
（53）是否只有不超过 4 到 7 种颜色，并且它们在可见光谱中是否相距较远？
（54）声音：普通的正反馈使用柔和的音效、不常见的或关键的情况下使用刺耳的音效；
（55）如果系统具有多页数据输入屏幕，那么所有页面都具有相同的标题吗？
（56）帮助与说明在各个屏幕上的显示位置是否一致？
（57）菜单是否遵循了行业或公司标准，并且它们是否在系统中的所有菜单中保持一致？
（58）图标类型不超过 12 到 20 吗？
（59）是否避免过分使用屏幕上所有大写字母？
（60）系统中是否有一致的图标设计方案和风格处理？
菜单：
（61）菜单选择列表是否垂直显示？
（62）如果“ 退出菜单”是一个菜单选项，它是否总是出现在列表的底部？
（63）菜单标题是居中还是左对齐？
输入栏：
（64）字段标签在各个页面是否一致？
（65）字段标签是否出现在单个字段的左侧和列表字段的上方？
（66）字段标签和字段是否在排版上有所区别？
命名规范一致性：
（67）各个屏幕的数据输入值的结构是否一致？
（68）某个对象在系统中的任何提示中的名称是否一致？
（69）某个用户动作在系统中的任何提示中的名称是否一致？
菜单/任务一致性：
（70）菜单选项是否在整个系统中保持一致？包括语法和术语是否也保持一致？
（71）菜单选项的结构是否匹配相应的菜单标题？
（72）菜单结构是否匹配任务结构？
（73）当消息指向必要的操作时，消息中描述的操作是否与实际操作一致？
功能目标一致性：
（74）网站目标在哪里？有明确定义吗？实际提供的内容和服务符合这些目标吗？
（75）网站观感是否与网站的目标，特征，内容和服务相对应？
（76）网站是否经常更新？
系统响应一致性：
（77）单击链接后的系统响应是否可以预测？
（78）是否无处避免链接？
（79）是否避免使用孤立页面？
5. 预防错误
预防胜于补救，因此要么消除容易导致误操作的因素，要么在用户操作前二次确认。
预防
（80）菜单选项是否合理、有区别性、且互斥？
（81）数据输入是否尽可能不区分大小写？
（82）如果用户将要导致潜在的严重错误，系统是否会警告用户？
（83）数据输入页面和对话框是否指示已用/可用字数？
（84）有必要时，数据输入页面和对话框中的字段是否包含默认值（非占位符）？
6. 要疯狂暗示，不要背诵全文
操作和选项一定要清晰且鲜明，减少用户的记忆负担。避免让用户在下一画面中回忆上一画面的内容。指南和说明应该足够明显，或者很容易唤出。
减少记忆负担：
（85）让用户不需要高度集中注意力，也不需要牢记信息：2到15秒；
（86）每个步骤都显示了用户需要的全部数据吗？
（87）如果用户必须在多个屏幕之间导航，系统是否使用上下文标签，菜单导航图和位置标记作为导航辅助工具？
（88）用户完成一个动作（或一组动作）后，反馈是否指示可以开始下一组动作？
（89）是否清楚标记了某些字段是非必填项？
（90）输入页面和对话框是否告知用户什么情况下是非必填？
（91）页面长度是否受控制？
通用视觉线索（Visual Cue）：
（92）对于 Q&A 界面，是否使用视觉线索和空白区分开问题、提示、说明和用户输入？
（93）数据显示是否从屏幕的左上角开始？
（94）是否使用空格，对齐方式和视觉线索来优化提示信息，以便于快速浏览？
（95）文本区域周围是否有“呼吸空间”？
（96）信息对象之间是否存在“留白”区域以使视觉放松？
（97）系统是否提供可见性；也就是说，仅通过查看，用户可以了解系统当前的状态、以及替代操作吗？
（98）是否使用大小，粗体，下划线，颜色，阴影或版式来显示不同屏幕项目的相对数量或重要性？
（99）颜色线索是否与其他冗余线索一起使用？
（100）图像和背景之间是否存在合适的色彩对比和明度对比？
（101）是否使用浅色，明亮，饱和色来强调数据；同时使用深色，暗淡、不饱和色来淡化数据？
（102）视觉页面空间是否使用得当？
输入/输出数据：
（103）在数据输入屏幕和对话框中，是否仅在必要时显示从属字段？
（104）字段标签是否靠近字段，但至少隔开一个空格？
菜单
（105）每个菜单选择的第一个词是最重要的吗？
（106）非活动菜单项是否变灰或被隐藏？
（107）菜单有默认选项吗？
（108）在“单选”菜单和“多选”菜单之间有明显的视觉区别吗？
7. 让小白和高手都能高效使用
实现一个目标的操作不是唯一的，既为高手准备快捷操作，也为小白用户预留进步空间。允许用户自定义常用功能。
搜索：
（109）搜索框是否易于使用？
（110）搜索框容易识别吗？
（111）有高级搜索选项吗？
（112）以完全详尽的方式呈现搜索结果吗？
（113）搜索框的宽度合适吗？
（114）如果无法提供搜索结果，是否为用户提供了帮助？
8. 视觉极简设计原则
极简并非指扁平化或者颜色单一，而是要减少不必要或次要信息对用户的干扰。信息之间会竞争用户的注意力，所以每次增加信息都是在稀释主要信息的能见度。
（115）菲特定律：获取目标的时间取决于目标的距离和大小；
（116）屏幕上仅显示决策必需的信息吗？
（117）字段标签是否是简短，熟悉和纯叙述性的？
（118）提示是肯定的，并且使用主动语态吗？
（119）布局设计是否清晰，避免了视觉干扰吗？
多媒体内容：
（120）使用图像和多媒体内容是否会增加价值？
（121）图像尺寸合适吗？容易理解吗？分辨率合适吗？
（122）是否避免循环动画？
图标：
（123）是否避免了图标设计中过多的细节？
（124）个体图标是否同属于一个图标库？
（125）每个图标是否从背景中突出？
（126）每套中的各个图标在视觉和概念上是否能够区分？
菜单：
（127）每个较低级别的菜单选项是否仅与一个较高级别的菜单相关联？
（128）菜单标题是否简短，但方便交流？
9. 帮助用户识别错误、进行疑难解答、恢复常态
错误提示要通俗易懂（尤其不要给用户看源代码，可以用错误代码）、准确描述问题、并提供有帮助的解决方案。如果可能，解决方案最好是可以无需跳转、立即采用的操作。
（无）
10. 帮助文档与说明文档
虽然说“不必说明就是最好的说明”，但是大多数时候用户还是需要帮助的。帮助与说明要触手可及，并且与用户当前操作相关，既要列出详细的操作步骤，还不能太啰嗦。
（129）说明在视觉上由区分度吗？
（130）说明指令是否遵循用户操作的顺序？
（131）如果部分菜单选项模棱两可，选择某些选项时系统是否提供其他说明信息？
（132）如果某个菜单选项含糊不清，选择该选项时系统是否提供其他说明信息？
（133）帮助功能可见吗，例如标有“帮助”的键或特殊菜单？
（134）帮助系统界面（导航，演示和对话）是否与其支持的应用程序的导航，演示和对话界面一致？
（135）导航：信息容易找到吗？
（136）演示：视觉布局设计合理吗？
（137）对话：信息是否准确，完整和可理解？
（138）信息是否相关？ （帮助和文档）在以下几个方面应该相关：面向目标（该程序可以做什么？）、描述性（这是做什么用的？）、程序性（我如何执行此任务？）、解释性（为什么会这样？）、和导航性（我在哪里？）；
（139）是否有上下文相关帮助？
（140）用户可以更改详细程度吗？
（141）用户可以轻松地在帮助和工作之间切换吗？
（142）是否易于访问帮助系统并从帮助系统返回？
（143）用户可以在获得帮助后从上次中断的地方继续工作吗？
（144）如果存在“常见问题解答（FAQ）”部分，问题和答案的选择和修订是否正确？
Gomez et al. 还提供了额外的 3 条法则及其子法则：
技能：
（145）请勿在应用程序或服务中使用“默认”一词；将其替换为“标准”，“使用惯用设置”，“还原初始设置”或其他一些更具体的术语，描述实际情况[41]；
（146）如果系统同时支持新手和专家用户，是否有多个级别的错误消息可用？
（147）如果系统同时支持新手和专家用户，是否有多个级别的细节信息可用？
（148）用户是否是行动的发起者，而不是响应者？
（149）所选输入设备是否与用户功能匹配？
（150）重要按键（例如回车，换行）是否比其他键大？
（151）系统是否正确预计并提示用户下一个可能的活动？
适意而尊重的互动：
（152）保护用户的工作，也就是“用户是否可以保存未完成的草稿？”
（153）所选输入设备是否符合环境限制？
（154）Q&A 界面是否仅要求最低限度的输入即可搜索？
（155）系统是否会在输入字段时自动完成已明确部分的输入？
隐私：
（156）受保护的区域是完全无法进入的吗？
（157）是否可以使用密码访问受保护的区域或机密区域？
（158）是否有关于“如何保护个人数据”和“内容版权”的信息？
模版
“高”，“中”，“低”为优先级顺序。
作者注：BDD（behaviour driven documentation，行为驱动文档）是设计团队内部根据“行为驱动开发（behaviour driven development”）命名的一套交互文档写作格式。跟交互说明中的一些概念类似，都是以用户行为为核心，详细并且按逻辑描述在某个状态下的某个行为应该产生的结果。
例如：
已知 用户打开导航栏
当 用户点选帮助
那么 用户会跳转到 FAQ 页面
同时 系统记录跳转前的页面
同时 系统提示如果未找到需要的信息，请联系用户支持
参考：
Nielsen, J., 1995. 10 usability heuristics for user interface design. Nielsen Norman Group, 1(1).
