Skip to content
UX Atlas
HeuristicExpert heuristicFoundational

Help Users Recognise, Diagnose and Recover From Errors

Error messages should say what happened, why, and what to do next, in plain language.

Definition

Nielsen's ninth heuristic. Error messages should be expressed in plain language rather than codes, precisely indicate the problem, and constructively suggest a solution.

Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.

On this page
  1. Definition
  2. The three parts of a usable error
  3. Writing and placing errors
  4. In practice
  5. Sources
  6. Continue from here

The three parts of a usable error

  1. 1

    What happened

    State the outcome in the user's terms. 'Your card was declined' rather than 'Transaction failed with code 402'.

  2. 2

    Why, when you can say honestly

    Give the reason if you know it and can share it. If you cannot, say so rather than inventing a cause. 'Your bank declined the payment. They do not tell us why.'

  3. 3

    What to do next

    Give a specific action, ideally as a control in the message itself. 'Try a different card' with a button beats 'Please try again later'.

Writing and placing errors

Do

  • Place the message next to the thing that caused it.
  • Preserve everything the user entered.
  • Summarise at the top of a long form and link each summary item to its field.
  • Move focus to the summary or first error on submit, so screen reader users are told.
  • Use a calm, non-accusatory tone. The user is not the problem.

Do not

  • Use red as the only signal, which fails colour vision deficiency.
  • Show raw exception text, stack traces or status codes.
  • Blame the user with words like 'invalid' and 'illegal'.
  • Use a toast for an error the user must act on.

In practice

Specific payment failures

Checkout

Distinguishing 'insufficient funds', 'card expired' and 'address does not match' gives the user an action. A single 'payment failed' forces them to guess, and most guess 'this site is broken'.

Error summary at the top of a long form

Applications

A summary listing each problem, each item linking to its field, with focus moved to the summary on submit, is the pattern used in government service design and it works for every user, not only screen reader users.

Sources

Where a source establishes something narrower than the popular reading of it, the note says so.

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applied through

Where this shows up as a concrete interface decision.

Often used with

These usually appear in the same screen or the same decision.

Check your work

Review passes that test whether this was done properly.

Related concept

Connected closely enough to change how you apply this.