nielsen-usability-heuristics
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseNielsen's 10 Usability Heuristics
Nielsen's 10 Usability Heuristics
Foundational principles for evaluating and designing usable interfaces. Apply these as a review checklist and as design constraints from the start — not only as a post-hoc audit tool.
评估与设计易用界面的基础原则。应将这些原则作为评审检查表，从设计初期就当作设计约束来应用——而不仅仅是事后审计工具。
1. Visibility of System Status
1. 系统状态可见性
The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.
Users cannot make good decisions without knowing the current state of the system. Trust is built through clear, timely feedback.
In practice:
- Show loading states, progress indicators, and completion confirmations
- Indicate where the user is in a multi-step process
- Reflect state changes immediately (optimistic UI or loading spinners)
- Never leave a user wondering whether an action was registered
Review question: After any user action, is the outcome visible within 1 second?
设计应始终通过合理时间内的恰当反馈，让用户了解当前系统状态。
用户若不清楚系统当前状态，就无法做出正确决策。清晰及时的反馈能够建立用户信任。
实践要点：
- 展示加载状态、进度指示器和完成确认信息
- 标明用户在多步骤流程中的当前位置
- 立即反映状态变化（如乐观UI或加载 spinner）
- 绝不能让用户疑惑操作是否已被系统接收
评审问题： 用户执行任何操作后，结果是否能在1秒内可见？
2. Match Between System and Real World
2. 系统与现实世界匹配
The design should speak the users' language — words, phrases, and concepts familiar to the user, not internal jargon or system terminology.
Follow real-world conventions and natural mapping so the interface feels intuitive rather than requiring translation.
In practice:
- Use terminology the target audience uses, not what the engineering team uses
- Icons should match real-world objects or widely established web conventions
- Spatial metaphors should match real-world expectations (e.g. "trash" for deletion)
- Avoid exposing internal system concepts (IDs, error codes, process names) to end users
Review question: Would a user unfamiliar with this product understand every label and term?
设计应使用用户熟悉的语言——即用户常用的词汇、短语和概念，而非内部行话或系统术语。
遵循现实世界的惯例和自然映射，让界面直观易懂，无需用户额外理解转换。
实践要点：
- 使用目标受众的术语，而非工程团队的内部用语
- 图标应匹配现实世界物体或广泛认可的网页惯例
- 空间隐喻应符合现实世界预期（如用“垃圾桶”代表删除）
- 避免向终端用户暴露内部系统概念（如ID、错误代码、流程名称）
评审问题： 不熟悉该产品的用户能否理解所有标签和术语？
3. User Control and Freedom
3. 用户控制与自由
Users often perform actions by mistake. They need a clearly marked emergency exit to leave an unwanted state without going through an extended process.
Easy undo and escape paths foster confidence and prevent users from feeling trapped.
In practice:
- Always provide Undo for destructive or irreversible actions
- Modals and dialogs need an obvious close/cancel action
- Multi-step flows need a way to go back
- Destructive actions (delete, publish, send) should be reversible where possible — or require explicit confirmation
Review question: Can the user get out of any state without losing their work or needing to contact support?
用户时常会误操作。他们需要一个标记清晰的紧急退出途径，无需繁琐流程即可脱离不想要的状态。
便捷的撤销和退出路径能增强用户信心，避免用户产生被困感。
实践要点：
- 对于破坏性或不可逆操作，始终提供撤销功能
- 模态框和对话框需有明显的关闭/取消操作
- 多步骤流程需支持返回上一步
- 破坏性操作（删除、发布、发送）应尽可能可逆——或要求用户明确确认
评审问题： 用户能否在不丢失工作成果或联系客服的情况下，脱离任何状态？
4. Consistency and Standards
4. 一致性与标准
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.
Consistency reduces cognitive load by meeting expectations users have built from other products.
In practice:
- Use the same label for the same action across the entire product
- Follow platform conventions (e.g. left-swipe to delete on mobile, Cmd+Z for undo)
- Design system components should look and behave identically everywhere they appear
- Do not rename standard web patterns (e.g. calling a "breadcrumb" a "path trail")
Review question: Does the same action always look and behave the same way throughout the product?
用户不应疑惑不同的词汇、场景或操作是否指代同一事物。遵循平台和行业惯例。
一致性能够降低认知负荷，符合用户从其他产品中建立的预期。
实践要点：
- 同一操作在整个产品中使用相同标签
- 遵循平台惯例（如移动端左滑删除、Cmd+Z撤销）
- 设计系统组件在所有出现的位置，外观和行为都应完全一致
- 不要重命名标准网页模式（如将“面包屑”称为“路径轨迹”）
评审问题： 同一操作在整个产品中的外观和行为是否始终一致？
5. Error Prevention
5. 错误预防
Good error messages matter, but the best designs prevent errors from occurring in the first place.
Prevention addresses both slips (unintentional actions) and mistakes (misunderstanding of design intent).
In practice:
- Use constraints to make wrong inputs impossible (e.g. disable a Submit button until required fields are complete)
- Confirm before destructive or irreversible actions
- Use input masks, validation, and sensible defaults to guide correct input
- Design forms so the happy path is the obvious path
Review question: For every destructive or irreversible action, is there a confirmation step or an undo path?
优质的错误提示固然重要，但最佳设计应从根源上避免错误发生。
错误预防需同时解决疏忽（无意操作）和误解（对设计意图的错误理解）两类问题。
实践要点：
- 使用约束机制避免错误输入（如在必填字段未填写完成前禁用提交按钮）
- 执行破坏性或不可逆操作前要求确认
- 使用输入掩码、验证和合理默认值引导正确输入
- 设计表单时让顺畅路径成为最明显的选择
评审问题： 对于每一项破坏性或不可逆操作，是否有确认步骤或撤销路径？
6. Recognition Rather Than Recall
6. 识别而非回忆
Minimise the user's memory load by making elements, actions, and options visible. The user should not have to remember information from one part of the interface to another.
Recognition requires less cognitive effort than recall. Visible affordances reduce the work of using the product.
In practice:
- Show relevant options in context rather than requiring users to remember commands
- Display previously entered data when relevant (e.g. pre-fill known fields)
- Use icons with labels — icons alone are ambiguous to many users
- Navigation should be visible at all times, not hidden behind a gesture or hover
Review question: Does a returning user need to remember anything to pick up where they left off?
通过让元素、操作和选项可见，最小化用户的记忆负担。用户无需从界面的一个部分回忆信息到另一个部分。
识别所需的认知努力远少于回忆。可见的功能提示能降低产品使用难度。
实践要点：
- 在上下文环境中展示相关选项，而非要求用户记住命令
- 相关时显示用户之前输入的数据（如预填充已知字段）
- 图标搭配标签使用——仅靠图标对许多用户而言含义模糊
- 导航应始终可见，而非隐藏在手势或悬停操作后
评审问题： 回头使用产品的用户是否需要记住任何信息才能继续之前的操作？
7. Flexibility and Efficiency of Use
7. 使用灵活性与效率
Shortcuts — hidden from novice users — may speed up interaction for expert users. The design should serve both.
Accelerators, customisation, and personalisation let experienced users work faster without adding complexity for beginners.
In practice:
- Provide keyboard shortcuts for frequent actions
- Support both guided flows (for new users) and direct paths (for experts)
- Allow users to customise views, filters, or layouts they use repeatedly
- Surface frequently used actions prominently based on usage patterns
Review question: Can a power user complete their most frequent task significantly faster than a first-time user?
对新手用户隐藏的快捷方式，可加速专家用户的交互流程。设计应同时服务两类用户。
快捷键、自定义和个性化设置，让资深用户能够更快操作，同时不会增加新手用户的理解复杂度。
实践要点：
- 为频繁操作提供键盘快捷键
- 同时支持引导流程（面向新用户）和直接路径（面向专家用户）
- 允许用户自定义常用的视图、过滤器或布局
- 根据使用模式，突出显示频繁使用的操作
评审问题： 资深用户完成最频繁任务的速度是否显著快于首次使用的用户？
8. Aesthetic and Minimalist Design
8. 美观与极简设计
Interfaces should not contain information that is irrelevant or rarely needed. Every extra unit of information competes with relevant information and reduces its relative visibility.
Focus content and visual design on the essentials that support primary user goals. Less is more, only when the less is the right less.
In practice:
- Remove decorative elements that carry no meaning
- Secondary and tertiary actions should be visually subordinate to primary ones
- Avoid showing all features simultaneously — progressive disclosure reveals complexity only when needed
- Empty states, error states, and loading states deserve the same design attention as content states
Review question: Does every element on screen earn its place, or is something there "just in case"?
界面不应包含无关或极少使用的信息。每一项额外信息都会与相关信息竞争，降低其相对可见性。
内容和视觉设计应聚焦于支持用户核心目标的必要元素。少即是多，但前提是“少”的是正确的内容。
实践要点：
- 删除无意义的装饰元素
- 次要和三级操作在视觉上应从属于主要操作
- 避免同时展示所有功能——渐进式披露仅在需要时才呈现复杂内容
- 空状态、错误状态和加载状态应获得与内容状态同等的设计关注
评审问题： 屏幕上的每一个元素是否都有存在的必要，还是有些只是“以防万一”？
9. Help Users Recognize, Diagnose, and Recover from Errors
9. 帮助用户识别、诊断并从错误中恢复
Error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution.
Error messages are a UX surface — they deserve the same care as any other UI copy.
In practice:
- Never show raw error codes or stack traces to end users
- State clearly what went wrong in plain language
- Tell the user what to do next, not just what failed
- Use appropriate visual treatment: red for errors, but not red for warnings or info
- Inline validation errors should appear adjacent to the problematic field
Review question: Does every error message tell the user what happened, why, and what to do next?
错误提示应使用平实语言，精准指出问题，并建设性地给出解决方案。
错误提示是UX界面的一部分——应给予与其他UI文案同等的重视。
实践要点：
- 绝不要向终端用户显示原始错误代码或堆栈跟踪信息
- 用平实语言清晰说明问题所在
- 告诉用户下一步该怎么做，而非仅说明哪里出错了
- 使用恰当的视觉处理：错误用红色，但警告或信息提示不要用红色
- 内联验证错误应显示在问题字段附近
评审问题： 每一条错误提示是否都告知用户发生了什么、原因是什么以及下一步该怎么做？
10. Help and Documentation
10. 帮助与文档
It is best if the system does not need any additional explanation. However, it may be necessary to provide documentation to help users complete tasks.
Help should be contextual, searchable, and actionable — not a last resort buried in a footer.
In practice:
- Prefer self-explanatory UI over tooltips; prefer tooltips over documentation
- Inline help (placeholder text, helper text, tooltips) should appear at the point of need
- Documentation should be task-oriented ("How do I…") not feature-oriented ("About the settings panel")
- Empty states are an opportunity for contextual help, not just a blank screen
Review question: Can a confused user find help without leaving the current screen?
理想情况下，系统无需额外说明。但在必要时，应提供文档帮助用户完成任务。
帮助内容应具备上下文相关性、可搜索性和可操作性——而非作为最后手段隐藏在页脚中。
实践要点：
- 优先选择自解释UI，其次是工具提示，最后才是文档
- 内联帮助（占位符文本、辅助文本、工具提示）应在需要时出现
- 文档应面向任务（如“如何……”）而非功能（如“关于设置面板”）
- 空状态是提供上下文帮助的机会，而非仅显示空白屏幕
评审问题： 困惑的用户能否在不离开当前屏幕的情况下找到帮助？
Heuristic Review Checklist
启发式评审检查表
| # | Heuristic | Check |
|---|---|---|
| 1 | System status | Every action gives visible feedback within 1s |
| 2 | Real-world language | No jargon, terminology matches user vocabulary |
| 3 | User control | Undo available, exit paths always visible |
| 4 | Consistency | Same action = same label and behaviour everywhere |
| 5 | Error prevention | Irreversible actions have confirmation or undo |
| 6 | Recognition over recall | Options visible in context, no hidden commands |
| 7 | Flexibility | Power users have faster paths to frequent tasks |
| 8 | Minimalist design | Every element earns its place |
| 9 | Error recovery | Error messages are plain, specific, and actionable |
| 10 | Help and docs | Help is contextual and available at point of need |
| # | 启发式原则 | 检查项 |
|---|---|---|
| 1 | 系统状态可见性 | 所有操作都能在1秒内给出可见反馈 |
| 2 | 匹配现实世界语言 | 无行话，术语符合用户词汇习惯 |
| 3 | 用户控制与自由 | 提供撤销功能，退出路径始终可见 |
| 4 | 一致性与标准 | 同一操作在所有位置的标签和行为都一致 |
| 5 | 错误预防 | 不可逆操作有确认步骤或撤销路径 |
| 6 | 识别而非回忆 | 选项在上下文环境中可见，无隐藏命令 |
| 7 | 使用灵活性与效率 | 资深用户完成频繁任务有更快路径 |
| 8 | 极简美观设计 | 每一个元素都有存在的必要 |
| 9 | 错误恢复 | 错误提示平实、具体且具备可操作性 |
| 10 | 帮助与文档 | 帮助内容具备上下文相关性，在需要时可获取 |