status-colors-and-errors

状态颜色与错误设计

保持颜色种类精简

系统中每增加一种状态颜色，都会增加用户的认知负担。他们必须了解每种颜色的含义、记住它，并在压力下正确解读——而错误恰恰会在这种时候发生。

几乎适用于所有情况的最小颜色集合：

颜色	语义	始终表示
红色	错误／失败／破坏性操作	出了问题，或此操作无法撤销
橙色／琥珀色	警告	继续之前需要注意某些事项
绿色	成功／正向	操作已完成，状态正常
蓝色	信息／中性状态	仅提供信息，无需采取行动

规则：整个产品中，每种颜色只能对应一种含义。 如果橙色在一个组件中表示“警告”，在另一个组件中却表示“待处理”，整个系统就会失效。

每种状态色调都必须与其他颜色明显区分。 如果两个令牌呈现出来相似，就保留一个。同一种可见颜色换个名字，不会成为第二种状态：作者会任选其一，用户看到的却是同一种状态，这个名字也就成了谎言。草稿和待处理状态应使用中性色，而不是警告色调。

拿不准时，就删掉这种颜色——中性灰可以传达状态，却不带有语义暗示；用中性色胜过误用语义颜色。

橙色始终表示警告

橙色（琥珀色）传递着明确的信号：请注意，可能会出问题。不要将其用于：

• 中性状态（使用灰色）
• 进度或待处理状态（使用蓝色或旋转指示器）
• 信息内容（使用蓝色）
• 状态指示器中的品牌或装饰用途

如果界面中出现橙色，用户应该立刻知道这需要他们留意。

错误应当可以恢复

最糟糕的错误，是用户无法恢复的错误。 设计每种错误状态时，都要提供继续操作的路径。

错误消息的构成

每条错误消息都应回答三个问题：

1. 出了什么问题？——使用通俗语言，不要使用错误代码
2. 为什么会发生？——在有用且已知的情况下说明原因
3. 用户接下来应该做什么？——给出具体、可执行的建议

❌ "Error 500"
❌ "Something went wrong"
✓  "We couldn't save your changes. Check your connection and try again."
✓  "This email is already in use. Sign in instead, or use a different email."

恢复操作

• 对暂时性故障（网络错误、超时）始终提供重试按钮
• 对验证错误，直接指出有问题的字段
• 对失败的破坏性操作，向用户保证没有数据丢失
• 对会话过期，将用户重定向到登录页，并在登录后带回他们先前所在的位置

在重大错误发生之前加以预防

破坏性最大的错误——数据丢失、不可逆操作、状态异常——应在设计层面预防，而不是事后处理。

• 不可逆操作前先确认：“删除此项目及其全部 47 个任务？此操作无法撤销。”
• 禁用当前不可用的操作，而不是让用户触发后再遇到错误
• 尽可能自动保存，避免浏览器崩溃或意外关闭导致工作丢失
• 使用乐观 UI 并支持回滚：立即显示成功状态，失败时静默重试，只有重试也失败时才显示错误

在用户操作之前说明后果，而不是事后说明。 恐惧源于不清楚某个控件会产生什么结果。应提前清楚说明操作结果，让用户可以放心决定：

• 在控件旁边或内部提供通俗易懂的后果说明：“这会向全部 240 位订阅者发送邮件”“发布后所有人都能看到此内容”。
• 对多步骤或影响较大的操作提供分阶段指引：将其拆分为多个步骤，并在用户继续之前说明每一步会执行什么，让整个操作变得可预期，而不是让用户贸然行动。
• 将强提醒（确认对话框、输入确认文字）留给上述真正危险的情况；对于日常操作，一句简短的辅助说明就足够了。目标始终不变——避免意外，让操作不再令人害怕。

严重程度级别 — 谨慎使用

问题的严重程度各不相同。反馈的视觉权重应与问题严重程度相匹配。

严重程度	样式	使用时机
阻断性错误	全页错误状态或模态框	应用无法继续，用户必须采取操作
行内错误	字段下方的红色文字	表单字段验证失败
Toast / snackbar	临时通知，显示在屏幕底部	用户应当知晓但可以关闭的短暂故障
警示横幅	区域顶部的常驻横条	影响当前上下文的持续问题
空状态	带插图或说明的空白屏幕	暂无数据——应借此提供引导，而非只显示空白

避免同时显示多种错误类型——一条清晰的消息比三条重叠的警示更有用。

相似度只用一种色相，切勿从红色过渡到绿色

这里表示的是程度，而非状态。状态仍应使用上文的语义调色板；具有既定惯例的图表也应沿用该惯例（参见 [[data-display-and-selection]]）。当单元格展示两项事物有多相似，或某项事物的数量有多少时，应使用同一种色相，从近乎黑色（毫无共同点）渐变到强调色（完全相同）。低值端的红色和黄色会让人联想到警告，使差异页面看起来像错误页面；绿色则会让人觉得是在打分。单一色相表示程度，这正是数值所表达的含义。

审查清单

• 产品使用的语义状态颜色是否不超过四种？
• 每种颜色是否只表示一种含义，并且在所有地方始终如一？
• 每种状态色调是否都能与其他色调明显区分，并已合并容易混淆的色彩标记？
• 橙色／琥珀色是否专门用于警告？
• 每条错误消息是否说明了出错原因和下一步操作？
• 所有短暂错误（网络、超时）是否都有重试操作？
• 不可撤销的破坏性操作是否都需要经过确认？
• 长篇或复杂输入是否支持自动保存或草稿恢复？
• 是否避免了多个错误状态同时出现？
• 相似度或大小量级是否使用单一色相表示，并将警告色和成功色留给状态使用？

常见反模式

反模式	问题	修正方法
仅显示“出了点问题”，没有任何操作	用户陷入困境，无法继续	补充具体原因，并提供重试或联系链接
同时用橙色表示“待处理”和“警告”	颜色失去含义	橙色只表示警告；待处理使用蓝色或旋转指示器
使用五种或更多状态颜色（红色、橙色、黄色、青绿色、紫色……）	用户必须学习并记住复杂的图例	精简到最低限度：红色、橙色、绿色、蓝色
仅在提交时进行行内验证	用户会一次性发现所有错误	在字段失焦时验证，及时提供反馈
删除时不进行确认	用户可能误删数据	所有不可撤销的操作都必须要求明确确认