nielsen-usability-heuristics

Nielsen 的 10 条可用性启发式原则

评估和设计易用界面的基础原则。从一开始就将这些原则用作评审清单和设计约束，而不仅仅是事后审查工具。

---

1. 系统状态的可见性

设计应始终通过适当的反馈，在合理的时间内让用户了解当前情况。

不了解系统当前状态，用户就无法做出明智的决定。清晰、及时的反馈能够建立信任。

实际应用：

• 显示加载状态、进度指示器和完成确认
• 指明用户在多步骤流程中所处的位置
• 立即反映状态变化（乐观 UI 或加载动画）
• 绝不让用户疑惑操作是否已生效

**评审问题：**用户执行任何操作后，能否在 1 秒内看到结果？

---

2. 系统与现实世界的匹配

设计应使用用户的语言——用户熟悉的词语、短语和概念，而非内部行话或系统术语。

遵循现实世界的惯例和自然映射，让界面直观易懂，无需用户费力理解。

实际应用：

• 使用目标受众惯用的术语，而非工程团队使用的术语
• 图标应对应现实世界中的物品或广泛认可的 Web 惯例
• 空间隐喻应符合现实世界的预期（例如，用“垃圾桶”表示删除）
• 避免向最终用户暴露内部系统概念（ID、错误代码、进程名称）

**评审问题：**不熟悉本产品的用户能否理解每个标签和术语？

---

3. 用户控制权与自由

用户常常会误操作。他们需要一个醒目明确的紧急出口，以便无需经历冗长流程就能离开不想要的状态。

便捷的撤销和退出途径有助于建立信心，避免用户感到无路可退。

实际应用：

• 对破坏性或不可逆操作始终提供撤销功能
• 模态框和对话框需要醒目的关闭或取消操作
• 多步骤流程需要提供返回方式
• 破坏性操作（删除、发布、发送）应尽可能支持撤销，或要求用户明确确认

**评审问题：**用户能否在不丢失工作或联系支持人员的情况下退出任何状态？

---

4. 一致性与标准

用户不应疑惑不同的词语、情境或操作是否表达相同的意思。应遵循平台和行业惯例。

一致性能够满足用户从其他产品中形成的预期，从而减少认知负担。

实际应用：

• 在整个产品中，同一操作始终使用相同的标签
• 遵循平台惯例（例如，在移动设备上向左滑动以删除，使用 Cmd+Z 撤销）
• 设计系统组件无论出现在哪里，外观和行为都应一致
• 不要给标准 Web 模式重新命名（例如，不要把“面包屑导航”称为“路径轨迹”）

**评审问题：**同一操作在整个产品中是否始终具有相同的外观和行为？

---

5. 错误预防

好的错误消息很重要，但最好的设计会从一开始就防止错误发生。

错误预防既要应对失误（无意的操作），也要应对错误（误解设计意图）。

实际应用：

• 使用限制条件，让错误输入无法提交（例如，在必填字段填写完成前禁用“提交”按钮）
• 在执行破坏性或不可逆操作前要求确认
• 使用输入掩码、验证和合理的默认值，引导用户正确输入
• 设计表单，让顺利完成任务的路径一目了然

**评审问题：**每项破坏性或不可逆操作是否都有确认步骤或撤销途径？

---

6. 识别，而非回忆

通过让元素、操作和选项清晰可见，尽量减轻用户的记忆负担。用户不应该需要记住界面某一处的信息，再到另一处使用。

识别所需的认知努力少于回忆。清晰可见的操作提示能减少使用产品所需的精力。

实践建议：

• 在适当的情境中展示相关选项，而不是要求用户记住命令
• 在相关情境中显示之前输入的数据（例如，预填已知字段）
• 图标应搭配标签使用；对许多用户来说，单独的图标含义不明确
• 导航应始终可见，而不是隐藏在手势或悬停操作之后

评审问题： 回访用户需要记住什么，才能从上次中断处继续？

---

7. 灵活性与使用效率

对新手用户隐藏的快捷方式，可能会加快专家用户的操作。设计应同时服务这两类用户。

加速器、自定义和个性化功能可以让有经验的用户更快完成工作，同时不增加新手用户的使用复杂度。

实践建议：

• 为常用操作提供键盘快捷键
• 同时支持引导式流程（面向新用户）和直接操作路径（面向专家）
• 允许用户自定义经常使用的视图、筛选器或布局
• 根据使用模式，将常用操作醒目地呈现出来

评审问题： 高级用户能否比首次使用的用户显著更快地完成最常执行的任务？

---

8. 美观与简约设计

界面中不应包含无关或很少用到的信息。每增加一项信息，都会与相关信息争夺注意力，降低后者的相对可见度。

内容和视觉设计应聚焦于支持用户主要目标的关键要素。少即是多，但前提是删减得当。

实践建议：

• 移除没有实际意义的装饰元素
• 次要和第三级操作的视觉权重应低于主要操作
• 避免同时展示所有功能；渐进式披露只在需要时呈现复杂内容
• 空状态、错误状态和加载状态应获得与内容状态同等的设计关注

评审问题： 屏幕上的每个元素都有存在的必要吗？还是有些元素只是“以防万一”？

---

9. 帮助用户识别、诊断并从错误中恢复

错误消息应使用通俗易懂的语言，准确指出问题，并以建设性的方式给出解决建议。

错误消息是用户体验的一部分，应像其他任何界面文案一样认真设计。

实践建议：

• 切勿向最终用户显示原始错误代码或堆栈跟踪
• 用通俗易懂的语言清楚说明出了什么问题
• 告诉用户接下来该怎么做，而不只是说明哪里失败了
• 使用恰当的视觉样式：错误用红色，警告或信息提示则不要用红色
• 行内验证错误应显示在出问题的字段旁边

评审问题： 每条错误消息是否都告诉了用户发生了什么、为什么发生，以及接下来该怎么做？

---

10. 帮助与文档

最好让系统无需额外说明也能被理解。不过，有时仍需要提供文档来帮助用户完成任务。

帮助内容应与情境相关、可搜索且可执行，而不应成为埋在页脚中的最后手段。

实践建议：

• 优先采用不言自明的界面，而不是工具提示；优先采用工具提示，而不是文档
• 行内帮助（占位文本、辅助文本、工具提示）应出现在用户需要的地方
• 文档应以任务为导向（“如何……？”），而不是以功能为导向（“设置面板介绍”）
• 空状态是提供情境化帮助的机会，而不应只是一块空白屏幕

评审问题： 困惑的用户能否不离开当前屏幕就找到帮助？

---

启发式评审清单

#	启发式原则	检查项
1	系统状态	每项操作都能在 1s 内提供可见反馈
2	贴近现实语言	不使用行话，术语符合用户的用语习惯
3	用户控制权	提供撤销功能，始终显示退出路径
4	一致性	相同操作在任何地方都使用相同标签和行为
5	防错	不可逆操作需提供确认或撤销选项
6	识别优于回忆	在上下文中显示选项，不隐藏命令
7	灵活性	为高级用户提供更快捷的常用任务操作路径
8	极简设计	每个元素都应有其存在价值
9	错误恢复	错误消息应通俗、具体且可操作
10	帮助和文档	在需要时提供上下文相关的帮助