Error state design
Every error is a conversation. When something breaks, the interface should acknowledge the failure, explain what happened in plain language, and offer a clear path forward — never a dead end.
The three-part pattern
A well-designed error state has exactly three elements: an unambiguous status indicator, a human-readable description of what went wrong, and a single primary action the user can take right now. Omit any one of these and you leave the user stranded.
Tone matters
Never blame the user. Avoid technical jargon unless your audience is exclusively developers. “Something went wrong on our end” is almost always better than “Invalid request parameter.” The goal is to reduce anxiety, not add to it.
Empty states are not errors
An empty inbox is not a failure — it is a success state with zero results. Distinguish between “nothing to show” and “we could not load this.” The former gets an illustration and a call to action; the latter gets the three-part error pattern above.
Recovery actions
Every error screen must offer at least one of: retry, go back, contact support, or check status. If the error is transient, a retry button with a short delay is ideal. If it is permanent, route users to a fallback experience or support channel.
Quick checklist
- • Is the error visible and distinct from normal content?
- • Does the copy explain what happened without jargon?
- • Is there exactly one primary recovery action?
- • Have you tested this state with real failure modes?