Error States

Practical patterns for clear error messages, recovery paths, and calm failure handling.

01 — Foundation

Errors are inevitable — recovery is the job

Good systems help users recover calmly. Bad systems create panic and support tickets.

Errors will happen. The interface should explain what went wrong, whether the problem is temporary, what to do next, and whether progress was lost.

02 — Messages

Say what happened and how to fix it

Specificity reduces uncertainty immediately.

Too vague

'Something went wrong'

Clearer

'Payment failed. Check your card details and try again.'

03 — Severity

Match tone and treatment to severity

Not every error is equal — treat them differently.

  • validation issues — beside the field, linked with aria-describedby
  • temporary failures — explain retry and whether data was preserved
  • permission or system outages — say what is blocked and what support can do

04 — Recovery

Recovery and accessibility

Users should know whether to retry, wait, or contact support.

  • offer retry when it makes sense; do not leave dead ends
  • errors visible, connected to fields, and announced to screen readers
  • do not rely on colour alone; avoid technical stack traces in user-facing UI
  • do not blame users — explain the fix in plain language

For forms, see the Accessible Forms pattern for error summaries and focus management after failed submission.

05 — Review

Before you approve

A short checklist for error states in code review.

  • message explains what happened and what to do next
  • severity matches treatment; recovery path exists
  • fields linked; announcements meaningful; contrast sufficient

A good error state reduces uncertainty. A bad one creates it.