尼尔森十大可用性原则是一组检查界面是否容易理解和使用的通用原则。它们可以帮助产品经理、设计师和研发发现状态不清、术语难懂、容易误操作、错误后无法恢复等问题。它们是判断线索,不是十条固定的视觉样式,也不能代替真实用户试用。
Jakob Nielsen在NN/g发布的十项原则依次为:系统状态可见、贴近现实世界、用户控制与自由、一致性与标准、防错、识别而非回忆、灵活与高效、审美与简约、帮助识别诊断和恢复错误、帮助与文档。中文译法可能不同,理解每一项要解决的问题更重要。

系统状态可见原则
用户应能知道系统当前在做什么,以及自己的操作产生了什么结果。重点不仅是有动画,更是反馈能否帮助用户决定下一步。
比如提交申请后,按钮显示“提交中”,完成后显示申请编号与查看入口;提交失败时仍保留已经填写的内容。三种状态承担不同含义。若按钮变灰后一直没有提示,用户可能既不敢退出,又想再次点击。
- 开始处理时尽快给出可感知反馈,避免用户怀疑点击没有生效。
- 能获得真实进度时显示进度;无法确定时说明正在处理,不随意显示假的百分比。
- 等待很久时提供恰当的下一步,例如继续等待、取消或稍后查看。
- 成功提示应说明完成了哪个动作,失败提示应说明怎样恢复。

绘制原型时,可以参考加载组件模板,分别选择适合整页加载、局部刷新和按钮提交的形式。不要给每种等待都套同一个全屏遮罩。
贴近场景原则
用用户熟悉的概念与顺序组织信息。这里的“贴近现实”并不是把所有现实物件都画到屏幕上,而是减少用户翻译系统语言的负担。
购物车适合表达“先收集商品,再统一结算”;搜索图标可帮助识别查找入口。但图标并非人人都认识。面对不熟悉的业务概念,应加入文字标签,而不是假设某个符号天然通用。

- 先看用户工作中如何称呼对象,再确定菜单与字段名称。
- 按任务发生的顺序呈现信息,例如先选择商品和规格,再确认配送与支付。
- 普通用户看到“连接超时”可能仍不知道该怎么办,应补上重试或检查网络的动作。
- 专业软件可以保留专业术语,但同一概念不要在不同页面反复改名。

可以从图标组件资源挑选视觉统一的一组,并在实际尺寸下检查含义、识别度与标签是否匹配。
可控性原则
用户应能退出不想继续的流程,并在条件允许时撤销、修改或恢复操作。返回入口不能只存在于设计说明里,要在实际路径中找得到。删除等高风险操作可结合删除确认与撤销设计,明确确认、恢复和回收站规则。
多步表单返回上一步时,应尽量保留已填内容;关闭筛选面板后,已应用的筛选条件应有明确表现;取消上传时,要告诉用户文件是否已部分保存。控制权建立在对结果的理解上。
- 对编辑、移动和可逆删除等操作提供撤销或恢复方式。
- 对支付、外部发送或彻底删除等高影响行为,明确对象、范围与后果,再选择确认措施。
- 多步流程支持返回、保存草稿或退出,避免用户被迫完成整条流程。
- 有撤回期限时,让期限和生效条件被看见,不暗示所有操作都能无限撤回。

可以参考弹窗组件模板。但二次确认不是通用解法:可撤销的小动作不必每次打断;真正不可逆的行为也不能只写模糊的“确定吗”。
一致性与标准化原则
用户不应该猜测相似名称或相似控件是否代表同一件事。既要保持产品内部一致,也要尊重平台与用户已经形成的使用习惯。
同一个产品里,“保存”不应有时立即生效、有时只是暂存却不说明。按钮可以因风险等级采用不同强调方式,但同种状态应有稳定含义。返回、关闭和取消也不能随意混用:返回改变当前位置,关闭结束当前容器,取消放弃某次操作。

- 统一术语、图标、状态和组件行为,不只是统一颜色。
- 优先遵循目标平台的导航、键盘、返回与焦点习惯。
- 同类表单采用一致的必填、帮助、错误和成功提示方式。
- 确实需要打破习惯时,给出明显的解释或引导,并观察用户是否理解。
需要更广的理论背景,可以继续阅读UI交互设计原则;已经有多个业务模块的团队,应把重复决策沉淀到组件规范,而不是每页重新决定一次。
防错原则
防错发生在错误之前。用户不应该提交完一整页信息,才知道文件类型不支持、时间段已经结束,或某个动作会影响全部成员。
上传区域提前写明“PDF,不超过10 MB”;选择日期时对不可用日期作清晰标识;批量删除时显示选中数量与对象范围。这些做法比出错以后只给一句“失败”更有效。
- 在用户作决定的位置说明格式、单位、范围与必要条件。
- 提供合理默认值与输入辅助,但不要替用户默认勾选重要授权或付费选项。
- 选择合适的校验时机,避免用户刚输入第一个字符就被整页错误提示打断。
- 让不可用操作有可理解的原因;一个灰色按钮本身不能说明该如何解锁。
- 重复提交应有处理规则,不能只依赖用户不会连点。

邮箱并不能仅通过“包含@和句点”判定有效,手机号也不能在全球场景中统一按11位处理。原型需要说明采用哪种规则与适用地区,具体校验由产品与研发共同确认。规则越复杂,越应同时写出合法样例和失败时的修改路径。
协助记忆原则
这条原则更准确的含义是“识别,而非回忆”:尽量让选项、对象和上下文可见,减少用户依靠记忆完成任务的负担,而不是教用户背下更多规则。
对比商品时保留关键参数,确认订单时同时展示收货信息与费用,选择模板时展示名称和缩略图。不要让用户返回上一页记住编号,再回到当前页手动输入。

- 在需要作决定的位置显示相关信息,避免频繁跨页记忆。
- 把常用入口和近期使用项放在可发现的位置。
- 输入框需要持久标签,不能只靠输入后就消失的占位文字。
- 历史记录和推荐选项要能被理解、清除或修改,避免产生新的困扰。
“全都展开”也不是答案。信息太多会提高查找难度,可以按任务分组、渐进展示,并保留清楚的当前位置与已选结果。
灵活高效原则
同一产品通常同时服务新手和熟练用户。基本操作应能被发现,熟练用户也应有更高效的路径,例如快捷键、批量操作、保存筛选条件和重复任务复用。
例如文件列表中,新手可以逐项选择,熟练用户可以多选后批量移动。批量操作仍应说明影响对象和失败结果,不能为了少点几次就省略必要反馈。

- 为高频动作提供可学习的快捷方式,并在需要时展示说明。
- 支持批量处理时,明确作用范围、部分失败和恢复方式。
- 允许保存合适的偏好,但不要让过多设置成为新手的第一道门槛。
- 高级能力可放在扩展入口,基础任务不应依赖隐藏操作才能完成。
审美和简约设计原则
简约是让重要信息更容易被发现。它不等于删到只剩一个按钮,也不等于所有页面都必须极少文字。客服工作台需要同时比较多个字段,内容网站需要帮助读者判断文章是否值得读,不同任务有不同的信息密度。

- 确认页面的主任务,弱化与当前决策无关的营销和装饰。
- 用层级、分组与留白组织信息,不把所有文字都加粗或放大。
- 保留价格条件、风险提示、帮助和恢复入口等必要信息。
- 删除模块前,先问它是否帮助用户作决定;增加模块前,问它会挤占谁的注意力。
常见反例是为了“干净”隐藏表单标签、按钮文字和错误说明,用户只能边试边猜。视觉简洁如果提高了理解成本,就没有解决可用性问题。
容错原则
第九项强调帮助用户识别、诊断并从错误中恢复。它与第五项“提前防错”有关,但发生在不同阶段。
上传失败后,应明确是格式不支持、文件过大,还是网络中断,并提供对应动作。网络中断可以重试;格式不支持需要更换文件。只给所有失败统一加一个“重试”按钮,可能让用户不断重复同一个错误。
- 指出问题:用用户能理解的话说明发生了什么。
- 定位对象:哪一个字段、文件或步骤受影响。
- 提供路径:修改、重试、返回、换一种方式或寻求帮助。
- 保留工作:尽可能保留合法输入,避免一次错误让用户全部重填。

可参考后台空状态与异常状态素材。图形可以帮助识别,但真正帮助恢复的是准确的文案和可执行动作。对于支付等结果暂时不确定的操作,应先提供查询结果的路径,避免诱导用户直接重复付款。
人性化帮助设计原则
优先让界面本身易于理解;必要的帮助应围绕用户当下任务,容易找到,并给出具体操作。用户上传文件时需要知道支持什么格式,而不是被送到一篇很长的产品介绍。

- 在容易出错或术语陌生的位置提供简短解释。
- 复杂任务给出步骤,并让用户能回到原来的操作位置。
- 帮助搜索使用用户会输入的词,例如“找回删除文件”,不只依赖内部功能名称。
- 静态说明解决不了的问题,应有明确的后续支持渠道。
对所有用户强制播放长篇引导,不一定比就近帮助更好。可以先展示完成当前任务所需的信息,用户需要更多时再展开。
怎样用十条原则检查一个页面
启发式评估需要对具体界面和任务进行观察。不要对着十条名称逐项打“通过”,也不要凭喜欢哪种颜色决定问题严重程度。
- 先定范围:选择一项任务和起点,例如“上传一份不超过10 MB的PDF,并确认是否提交成功”。
- 独立走一遍:先看入口是否清楚,再实际操作。加入失败、返回和修改,不只观看成功演示。
- 记录具体问题:写明页面、操作、观察到的现象和造成的影响,再关联原则。
- 按影响排序:优先处理任务受阻、错误结果和无法恢复;其次处理反复误解与明显绕路;最后处理低影响的视觉细节。
- 修改后重新走路径:确认问题消失,也确认相邻状态没有被破坏。
| 不够具体的意见 | 能直接讨论的记录 | 关联原则 |
|---|---|---|
| 上传体验不好 | 选择12 MB文件后才提示失败,上传区没有大小限制;需要提前说明10 MB上限 | 防错、帮助 |
| 状态不清楚 | 点击提交后按钮无变化,等待时可重复点击;需要处理中状态与重复请求规则 | 状态可见、防错 |
| 错误提示太弱 | 网络中断后文件消失,仅显示“失败”;应保留文件并提供重试 | 错误恢复、用户控制 |
一个问题可能同时对应多条原则,不需要硬选唯一分类。评估也不是保证可用性的“认证”:涉及用户语言、复杂业务和不同能力人群时,还需要观察真实使用。规则检查善于发现常见缺陷,用户试用能暴露预想之外的理解问题。
