Skip to content
UX Atlas
Plate HEUR·009 · HeuristicGrid A2 · Rev. 2026-08-14

Help Users Recognise, Diagnose and Recover From Errors

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

HeuristicExpert heuristicFoundational

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 plate
  1. 1Definition
  2. 2The three parts of a usable error
  3. 3Writing and placing errors
  4. 4Rewriting the errors every product has
  5. 5In practice
  6. 6Commonly confused with
  7. 7Local chart
  8. 8Sources
  9. 9Continue from here

Reach for this when

  • Writing any error state.
  • Designing form validation.
  • Reviewing support tickets caused by unclear failures.

Common mistakes

  • Generic messages that offer no next action.
  • Errors that appear far from their cause.
  • Losing the user's input on failure.
  • Writing the message for the developer reading the logs rather than the person reading the screen.

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.

Rewriting the errors every product has

UnhelpfulWhat it should say
Invalid inputEnter a date in the future. The end date must be after the start date
Something went wrongWe could not reach the payment provider. Your card has not been charged. Try again
Error 403You do not have permission to edit this project. Ask its owner for access
Login failedThat password does not match. Reset it, or try another sign-in method
Upload failedThat file is 28 MB. The limit is 10 MB. Compress it or upload a smaller version

In practice

  1. i.

    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'.

  2. ii.

    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.

  3. iii.

    Naming what did not happen

    Reassurance as part of the message

    A failed payment message that says the card has not been charged prevents a second attempt, a duplicate charge and a support ticket. The sentence costs nothing and does more than the retry button.

Commonly confused with

Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.

vs.

Error Prevention

Heuristic

Designing so the error cannot occur, or is caught before it is committed.

Key difference

Error prevention removes the conditions in which a mistake can happen. Error recovery deals with the mistake once it has. Prevention is always cheaper, and no product prevents everything, so both are required.

Use Help Users Recognise, Diagnose and Recover From Errors when

  • The failure has already happened.
  • The levers are the message, the location of the fix and the route back.
  • The error came from outside, as with a network or a server.

Use Error Prevention when

  • The mistake is predictable and can be designed out.
  • The levers are constraints, sensible defaults, formats and confirmation.
  • The work happens before anything goes wrong.

Learn about Error Prevention

Local chart

HEUR·009 · Region I · Grid A2

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Alert and Inline MessageCMP·015 · APPLIED THROUGHInput ValidationPAT·007 · APPLIED THROUGHOptimistic UIPAT·013 · APPLIED THROUGHError MessagesWRT·002 · APPLIED THROUGHMicrocopyWRT·001 · APPLIED THROUGHFullStoryTOOL·027 · OFTEN USED WITHError PreventionHEUR·005 · COMMONLY CONFUSED WITHForm UX ChecklistCHK·001 · CHECK YOUR WORKError Identification and SuggestionA11Y·016 · RELATED CONCEPTUser Control and FreedomHEUR·003 · RELATED CONCEPTPeak-End RuleLAW·007 · RELATED CONCEPTFeedbackPRIN·004 · RELATED CONCEPT

Sources

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

  1. [1]

    10 Usability Heuristics for User Interface Design

    J. Nielsen, Nielsen Norman Group, 1994, revised 2020

  2. [2]

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.