status-colors-and-errors

Name: status-colors-and-errors
Author: dembrandt

267installs5forks

How to install status-colors-and-errors?

dembrandt/dembrandt-skills/status-colors-and-errors

$npx -y skills add dembrandt/dembrandt-skills --skill status-colors-and-errors

Installs into the current project.

Summary

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 statu

Files · 1

View on GitHub

SKILL.md

1	# Status Colours and Error Design
2
3	## Keep the Colour Set Small
4
5	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.
6
7	The minimal set that covers almost everything:
8
9	\| Colour \| Semantic meaning \| Always means \|
10	\|---\|---\|---\|
11	\| Red \| Error / failure / destructive \| Something went wrong, or this action cannot be undone \|
12	\| Orange / Amber \| Warning \| Something needs attention before proceeding \|
13	\| Green \| Success / positive \| Action completed, state is healthy \|
14	\| Blue \| Info / neutral status \| Informational, no action required \|
15
16	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.
17
18	When in doubt, cut the colour — neutral grey communicates status without semantic weight, and neutral is better than a misused semantic colour.
19
20	## Orange Is Always a Warning
21
22	Orange (amber) carries a specific signal: pay attention, something may go wrong. Do not use it for:
23	- Neutral states (use grey)
24	- Progress or pending (use blue or a spinner)
25	- Informational content (use blue)
26	- Branding or decorative purposes inside status indicators
27
28	If orange appears in the UI, the user should immediately know it requires their attention.
29
30	## Errors Should Be Recoverable
31
32	The worst error is one the user cannot recover from. Design every error state with a path forward.
33
34	### Error message anatomy
35	Every error should answer three questions:
36	1. What went wrong? — plain language, no error codes
37	2. Why did it happen? — if useful and known
38	3. What should the user do next? — specific, actionable
39
40	```
41	❌ "Error 500"
42	❌ "Something went wrong"
43	✓ "We couldn't save your changes. Check your connection and try again."
44	✓ "This email is already in use. Sign in instead, or use a different email."
45	```
46
47	### Recovery actions
48	- Always provide a retry button for transient failures (network errors, timeouts)
49	- For validation errors, point directly to the problematic field
50	- For destructive actions that failed, reassure the user nothing was lost
51	- For session expiry, redirect to login and return the user to where they were
52
53	## Prevent Large Errors Before They Happen
54
55	The most damaging errors — data loss, irreversible actions, broken state — should be prevented at the design level, not handled after the fact.
56
57	- Confirm before irreversible actions: "Delete this project and all 47 tasks? This cannot be undone."
58	- Disable unavailable actions rather than letting users trigger them and hit an error
59	- Autosave where possible so a browser crash or accidental close does not destroy work
60	- Optimistic UI with rollback: show the success state immediately, silently retry on failure, surface an error only if the retry also fails
61
62	*State the consequences before* the user acts, not after.** Fear comes from not knowing what a control will do. Make the outcome legible ahead of the action so the user commits with confidence:
63	- Plain-language consequence text next to or inside the control: "This will email all 240 subscribers", "Publishing makes this visible to everyone".
64	- Staged guidance for anything multi-step or heavy: break it into steps and tell the user what each one will do before they proceed, so the whole operation is predictable rather than a leap.
65	- Reserve the strong interruptions (confirm dialogs, typed confirmation) for the genuinely dangerous cases above; for everyday actions, a quiet line of helper text is enough. The goal is the same — no surprises, so nothi

People who liked this also viewed

6 picks

Type

status-colors-and-errors

267installs5forks

View on GitHub

How to install status-colors-and-errors?

dembrandt/dembrandt-skills/status-colors-and-errors

$npx -y skills add dembrandt/dembrandt-skills --skill status-colors-and-errors

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Status Colours and Error Design
2
3	## Keep the Colour Set Small
4
5	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.
6
7	The minimal set that covers almost everything:
8
9	\| Colour \| Semantic meaning \| Always means \|
10	\|---\|---\|---\|
11	\| Red \| Error / failure / destructive \| Something went wrong, or this action cannot be undone \|
12	\| Orange / Amber \| Warning \| Something needs attention before proceeding \|
13	\| Green \| Success / positive \| Action completed, state is healthy \|
14	\| Blue \| Info / neutral status \| Informational, no action required \|
15
16	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.
17
18	When in doubt, cut the colour — neutral grey communicates status without semantic weight, and neutral is better than a misused semantic colour.
19
20	## Orange Is Always a Warning
21
22	Orange (amber) carries a specific signal: pay attention, something may go wrong. Do not use it for:
23	- Neutral states (use grey)
24	- Progress or pending (use blue or a spinner)
25	- Informational content (use blue)
26	- Branding or decorative purposes inside status indicators
27
28	If orange appears in the UI, the user should immediately know it requires their attention.
29
30	## Errors Should Be Recoverable
31
32	The worst error is one the user cannot recover from. Design every error state with a path forward.
33
34	### Error message anatomy
35	Every error should answer three questions:
36	1. What went wrong? — plain language, no error codes
37	2. Why did it happen? — if useful and known
38	3. What should the user do next? — specific, actionable
39
40	```
41	❌ "Error 500"
42	❌ "Something went wrong"
43	✓ "We couldn't save your changes. Check your connection and try again."
44	✓ "This email is already in use. Sign in instead, or use a different email."
45	```
46
47	### Recovery actions
48	- Always provide a retry button for transient failures (network errors, timeouts)
49	- For validation errors, point directly to the problematic field
50	- For destructive actions that failed, reassure the user nothing was lost
51	- For session expiry, redirect to login and return the user to where they were
52
53	## Prevent Large Errors Before They Happen
54
55	The most damaging errors — data loss, irreversible actions, broken state — should be prevented at the design level, not handled after the fact.
56
57	- Confirm before irreversible actions: "Delete this project and all 47 tasks? This cannot be undone."
58	- Disable unavailable actions rather than letting users trigger them and hit an error
59	- Autosave where possible so a browser crash or accidental close does not destroy work
60	- Optimistic UI with rollback: show the success state immediately, silently retry on failure, surface an error only if the retry also fails
61
62	*State the consequences before* the user acts, not after.** Fear comes from not knowing what a control will do. Make the outcome legible ahead of the action so the user commits with confidence:
63	- Plain-language consequence text next to or inside the control: "This will email all 240 subscribers", "Publishing makes this visible to everyone".
64	- Staged guidance for anything multi-step or heavy: break it into steps and tell the user what each one will do before they proceed, so the whole operation is predictable rather than a leap.
65	- Reserve the strong interruptions (confirm dialogs, typed confirmation) for the genuinely dangerous cases above; for everyday actions, a quiet line of helper text is enough. The goal is the same — no surprises, so nothi

People who liked this also viewed

6 picks

Type