Usability Heuristics
Help Users Recognise, Diagnose, and Recover From Errors
Error messages should be plain English, name the exact problem, and suggest the fix.
Where it comes from
It's the ninth of Jakob Nielsen's ten usability heuristics. When prevention fails and an error does occur, the message that follows should help the user recover — by stating the problem clearly, in plain language, and pointing to a way forward.
Why it matters for your website
When something goes wrong, clarity is everything. Nielsen Norman Group's ninth heuristic says an error message should state the problem in plain language, point to exactly what's wrong, and suggest a way forward. Vague errors make users feel at fault and send them elsewhere.
A good error message does three things: it states the problem in plain language, names exactly what's wrong, and suggests a fix — turning a dead-end into a next step. A vague error ('an error occurred', 'invalid input') does none of these, leaving the user stuck and guessing.
Tone matters as much as content. An error that seems to blame the user — cryptic codes, accusatory phrasing — makes them feel at fault and sends them elsewhere; one that's clear, blameless, and constructive keeps them moving. The message is a moment where trust is either kept or lost.
Wrong vs right
A vague error ('Something went wrong' or 'Error 0x004') that names neither the problem nor the fix.
A message that says what's wrong in plain language and exactly how to fix it.
An error worded to blame the user, making them feel at fault.
Blameless, constructive phrasing that helps the user recover without feeling accused.
A technical error code with no human-readable explanation or next step.
Plain English, the specific problem named, and a clear way forward.
Understanding Help Users Recognise, Diagnose, and Recover From Errors
Help users recognise, diagnose, and recover from errors is the ninth of Jakob Nielsen's ten usability heuristics. It governs what happens when prevention fails and an error does occur: the message should state the problem in plain language, point precisely to what's wrong, and suggest a constructive way forward.
The difference between a good and bad error message is large. A good one does three jobs — names the problem clearly, says exactly what went wrong, and offers a fix — turning a dead-end into a next step. A vague one ('an error occurred', 'invalid input') does none of these, leaving the user stuck, guessing, and frustrated.
Tone is part of the job. An error that seems to blame the user makes them feel at fault and sends them elsewhere; a clear, blameless, constructive message keeps them moving. Error messages are a moment where trust is kept or lost, and clarity is what keeps it. It's the recovery counterpart to error prevention, and it connects to feedback and microcopy.
How Kweri checks it
Kweri can assess error messages it can observe — whether they're in plain language, name the specific problem, and suggest a fix, or are vague, technical, or accusatory — and flag those that would leave users stuck. What it can't always reach without exercising the interface is every error state, since many only appear under specific failure conditions. So Kweri surfaces the error messages it can see against the plain-language, specific, constructive standard, and prompts you to improve them, while reaching every error state means triggering the failures.
FAQ
What makes a good error message?
A good error message states the problem in plain language, names exactly what went wrong, and suggests how to fix it. It's clear, specific, and constructive — turning a dead-end into a next step rather than leaving the user stuck.
Why are vague error messages a problem?
Because they name neither the problem nor the fix, leaving the user stuck and guessing. Worse, vague or accusatory errors make users feel at fault, which damages trust and sends them elsewhere instead of helping them recover.
What should an error message include?
Three things: a plain-language statement of the problem, a precise indication of what's wrong, and a suggested way forward. Avoid technical codes, jargon, and blame; focus on helping the user recover.
How does error message tone affect users?
Strongly. An error that blames the user makes them feel at fault and more likely to leave; a blameless, constructive message keeps them moving. The tone of an error is a moment where trust is either kept or lost.
How is this related to error prevention?
Error prevention (heuristic 5) stops errors happening; this heuristic (9) handles the ones that do, helping users recognise, diagnose, and recover from them. Prevention is preferred, with good error messages as the safety net.
Related principles
User errors divide into two fundamentally different types: slips (right goal, wrong action — a lapse of execution) and mistakes (wrong goal — a failure of understanding). Each requires a different design response.
Stop problems before they happen — that beats even the best error message.
Errors should be flagged as users complete each field, not after the entire form is submitted — post-submit error discovery forces users to stop, hunt for problems, and often repeat work they've already done.
Attribution & sources
Identified by Jakob Nielsen (1994). Catalogued from Nielsen Norman Group — Error Message Guidelines.
The ninth of Nielsen's 10 Usability Heuristics; the linked article is the reference used here.
See Help Users Recognise, Diagnose, and Recover From Errors on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →