← ClaudeAtlas

status-colors-and-errorslisted

Keep status and error colours minimal and consistent — too many semantic colours confuse users. Each colour must mean exactly one thing. Errors should be recoverable, large failures must be prevented, and the UI should always give the user a path forward. Use when designing status indicators, error states, form validation, alerts, or any feedback system.
dembrandt/dembrandt-skills · ★ 13 · Web & Frontend · score 83
Install: claude install-skill dembrandt/dembrandt-skills
# Status 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. ## Errors Should Be Recoverable **The worst error is one the user cannot recover from