status-colors-and-errors
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseStatus Colours and Error Design
状态颜色与错误设计
Keep the Colour Set Small
精简颜色集合
Every status colour added to a system is a cognitive burden on the user. They must learn what each colour means, remember it, and interpret it correctly under stress — which is exactly when errors occur.
The minimal set that covers almost everything:
| Colour | Semantic meaning | Always means |
|---|---|---|
| Red | Error / failure / destructive | Something went wrong, or this action cannot be undone |
| Orange / Amber | Warning | Something needs attention before proceeding |
| Green | Success / positive | Action completed, state is healthy |
| Blue | Info / neutral status | Informational, no action required |
Rule: each colour maps to exactly one meaning across the entire product. If orange means "warning" in one component and "pending" in another, the system breaks down.
When in doubt, cut the colour — neutral grey communicates status without semantic weight, and neutral is better than a misused semantic colour.
系统中每新增一种状态颜色，都会增加用户的认知负担。用户必须学习每种颜色的含义、记住它，并在压力下（而错误往往就发生在此时）正确解读它。
几乎能覆盖所有场景的最小颜色集合：
| 颜色 | 语义含义 | 固定含义 |
|---|---|---|
| 红色 | 错误/失败/破坏性操作 | 出现问题，或该操作无法撤销 |
| 橙色/琥珀色 | 警告 | 需在继续操作前关注相关事项 |
| 绿色 | 成功/积极状态 | 操作完成，状态健康 |
| 蓝色 | 信息/中性状态 | 仅为告知性内容，无需操作 |
规则：整个产品中每种颜色对应且仅对应一种含义。 如果橙色在某个组件中表示“警告”，在另一个组件中表示“待处理”，整个系统的语义就会崩溃。
若拿不定主意，就去掉该颜色——中性灰色可传达状态且无语义权重，中性颜色比误用的语义颜色更好。
Orange Is Always a Warning
橙色仅用于警告
Orange (amber) carries a specific signal: pay attention, something may go wrong. Do not use it for:
- Neutral states (use grey)
- Progress or pending (use blue or a spinner)
- Informational content (use blue)
- Branding or decorative purposes inside status indicators
If orange appears in the UI, the user should immediately know it requires their attention.
橙色（琥珀色）传递特定信号：请注意，可能会出现问题。请勿将其用于：
- 中性状态（使用灰色）
- 进度或待处理状态（使用蓝色或加载动画）
- 告知性内容（使用蓝色）
- 状态指示器内的品牌装饰用途
如果UI中出现橙色，用户应立即明白这需要他们的关注。
Errors Should Be Recoverable
错误应具备可恢复性
The worst error is one the user cannot recover from. Design every error state with a path forward.
最糟糕的错误是用户无法恢复的错误。 为每个错误状态设计解决路径。
Error message anatomy
错误消息结构
Every error should answer three questions:
- What went wrong? — plain language, no error codes
- Why did it happen? — if useful and known
- What should the user do next? — specific, actionable
❌ "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."每个错误都应回答三个问题：
- 出了什么问题？ —— 使用直白语言，不要错误代码
- 为什么会发生？ —— 若有用且已知原因
- 用户接下来该怎么做？ —— 具体、可执行
❌ "Error 500"
❌ "Something went wrong"
✓ "我们无法保存您的更改。请检查网络连接后重试。"
✓ "该邮箱已被使用。请登录或更换其他邮箱。"Recovery actions
恢复操作
- Always provide a retry button for transient failures (network errors, timeouts)
- For validation errors, point directly to the problematic field
- For destructive actions that failed, reassure the user nothing was lost
- For session expiry, redirect to login and return the user to where they were
- 针对临时故障（网络错误、超时）始终提供重试按钮
- 对于验证错误，直接指向有问题的字段
- 对于失败的破坏性操作，向用户确认未丢失任何内容
- 对于会话过期，重定向至登录页面并在登录后返回用户之前的位置
Prevent Large Errors Before They Happen
提前预防重大错误
The most damaging errors — data loss, irreversible actions, broken state — should be prevented at the design level, not handled after the fact.
- Confirm before irreversible actions: "Delete this project and all 47 tasks? This cannot be undone."
- Disable unavailable actions rather than letting users trigger them and hit an error
- Autosave where possible so a browser crash or accidental close does not destroy work
- Optimistic UI with rollback: show the success state immediately, silently retry on failure, surface an error only if the retry also fails
最具破坏性的错误——数据丢失、不可撤销的操作、状态损坏——应在设计层面预防，而不是事后处理。
- 不可撤销操作前确认： “删除此项目及所有47个任务？此操作无法撤销。”
- 禁用不可用操作，而非让用户触发后遇到错误
- 尽可能自动保存，避免浏览器崩溃或意外关闭导致工作成果丢失
- 带回滚机制的乐观UI：立即显示成功状态，失败时静默重试，仅在重试也失败时才显示错误
Levels of Severity — Use Sparingly
严重程度分级——谨慎使用
Not every problem is equal. Match the visual weight of the feedback to the severity.
| Severity | Pattern | When to use |
|---|---|---|
| Blocking error | Full-page error state or modal | App cannot continue, user must act |
| Inline error | Red text below a field | Form field validation failure |
| Toast / snackbar | Temporary notification, bottom of screen | Transient failure the user should know about but can dismiss |
| Alert banner | Persistent bar at top of section | Ongoing issue affecting the current context |
| Empty state | Illustrated or descriptive empty screen | No data yet — use as an opportunity for guidance, not just a blank |
Avoid showing multiple simultaneous error types at once — one clear message is more useful than three overlapping alerts.
并非所有问题的严重程度都相同。反馈的视觉权重应与严重程度匹配。
| 严重程度 | 呈现方式 | 使用场景 |
|---|---|---|
| 阻塞性错误 | 全屏错误状态或模态框 | 应用无法继续，用户必须采取行动 |
| 内联错误 | 字段下方的红色文本 | 表单字段验证失败 |
| 提示条/ snackbar | 屏幕底部的临时通知 | 用户需要知晓但可忽略的临时故障 |
| 提示横幅 | 区域顶部的持久栏 | 影响当前上下文的持续问题 |
| 空状态 | 带插图或描述性内容的空页面 | 暂无数据——借此提供引导，而非仅显示空白 |
避免同时显示多个不同类型的错误——一条清晰的消息比三个重叠的提示更有用。
Review Checklist
审查清单
- Does the product use four or fewer semantic status colours?
- Does each colour mean exactly one thing, used consistently everywhere?
- Is orange/amber reserved exclusively for warnings?
- Does every error message state what went wrong and what to do next?
- Do all transient errors (network, timeout) have a retry action?
- Are irreversible destructive actions protected by a confirmation step?
- Is autosave or draft recovery available for long-form or complex inputs?
- Are multiple simultaneous error states avoided?
- 产品是否使用四种或更少的语义状态颜色？
- 每种颜色是否有且仅有一种含义，且在所有场景中保持一致？
- 橙色/琥珀色是否仅用于警告？
- 每个错误消息是否说明问题所在及后续操作？
- 所有临时错误（网络、超时）是否都有重试操作？
- 不可撤销的破坏性操作是否有确认步骤保护？
- 长文本或复杂输入是否支持自动保存或草稿恢复？
- 是否避免了同时显示多个错误状态？
Common Anti-Patterns
常见反模式
| Anti-pattern | Problem | Fix |
|---|---|---|
| "Something went wrong" with no action | User is stuck with no path forward | Add specific cause and a retry or contact link |
| Orange used for "pending" and "warning" simultaneously | Colour loses its meaning | Orange = warning only; use blue or spinner for pending |
| Five or more status colours (red, orange, yellow, teal, purple…) | User must learn and remember a complex legend | Cut to the minimum: red, orange, green, blue |
| Inline validation only on submit | User discovers all errors at once | Validate on blur (leaving a field) for immediate feedback |
| No confirmation on delete | Users accidentally delete data | Require explicit confirmation for all irreversible actions |
| 反模式 | 问题 | 修复方案 |
|---|---|---|
| “出了点问题”但无任何操作选项 | 用户陷入困境，无路可走 | 添加具体原因及重试或联系链接 |
| 同时将橙色用于“待处理”和“警告” | 颜色失去语义 | 橙色仅用于警告；待处理状态使用蓝色或加载动画 |
| 使用五种或更多状态颜色（红、橙、黄、青、紫……） | 用户必须学习并记住复杂的图例 | 精简至最小集合：红、橙、绿、蓝 |
| 仅在提交时进行内联验证 | 用户一次性发现所有错误 | 在字段失焦时验证，提供即时反馈 |
| 删除操作无确认步骤 | 用户意外删除数据 | 所有不可撤销操作都需明确确认 |