Error Prevention and Recovery
Date: 2026-08-17
Stopping errors happening beats handling them well, and handling them well beats both alternatives to the one that actually occurs. Most “user errors” are design errors with the blame relocated.
Error prevention designs so a mistake can’t be made. Error recovery makes the mistake cheap to correct when it happens anyway.
The framing that matters: an error the interface permitted is an interface problem. “User error” is usually a design decision that allowed an invalid state.
Slips versus mistakes
The distinction determines which fix applies:
SLIP right intention, wrong action
→ tapped the wrong button,
typed a digit wrong
FIX: bigger targets, spacing,
confirmation on
destructive actions,
undo — Fitts's Law
MISTAKE wrong intention — they
misunderstood
→ ordered the wrong size
because sizing was unclear
FIX: clearer information,
better labels, constraints
Confirmation dialogues prevent slips and do nothing for mistakes. Someone who confidently intends the wrong thing confirms it — which is why “are you sure?” is weaker than it looks.
Prevention, in order of strength
1 MAKE IT IMPOSSIBLE
a date picker with past dates
disabled
← strongest. No error to handle
2 CONSTRAIN THE INPUT
numeric keypad for a phone number
a select rather than free text
3 FORMAT AS THEY TYPE
card number spacing, postcode
capitalisation
4 SENSIBLE DEFAULTS
— The Default Effect
5 VALIDATE EARLY, INLINE
on blur, not on submit
6 CONFIRM DESTRUCTIVE ACTIONS
← weakest, and most reached for
The list is inverted in practice. Teams reach for 6 first because it’s cheapest, and 1 is usually available and rarely considered.
Inline validation, done properly
ON BLUR, not on every keystroke
→ validating as they type an email
shows an error before they've
finished typing it
POSITIVE confirmation for slow checks
→ "postcode found ✓"
ERROR STAYS until fixed
→ not a toast that disappears
RE-VALIDATE on submit
→ client-side validation is a
courtesy, never a guarantee
— Common Vulnerabilities
What an error message needs
WHAT WENT WRONG in plain language
WHERE which field
HOW TO FIX IT the specific action
WHAT WAS KEPT "your basket is saved"
BAD GOOD
"Invalid input" "Postcode not
recognised. Check
it, or enter your
address manually"
"An error occurred" "We couldn't take
payment. Your card
wasn't charged.
Try another card?"
"Field required" "We need a phone
number so the
courier can
contact you"
“Your card wasn’t charged” is the most important sentence in a payment error, and it’s frequently missing. Without it, the person doesn’t know whether to retry — and either abandons or double-pays.
Recovery
PRESERVE INPUT never clear a form on
error. This is the
cardinal rule
UNDO over CONFIRM for reversible actions
AN ALTERNATIVE "try another card",
"enter address manually",
"contact us"
A ROUTE OUT an error page with no
navigation is a dead end
Clearing a form on validation failure is the most infuriating pattern in this note, and it still happens — usually as a side effect of a full page reload.
The blame question
| Blaming | Neutral |
|---|---|
| ”You entered an invalid postcode" | "That postcode wasn’t recognised" |
| "You forgot to…" | "We still need…" |
| "Invalid card" | "That card was declined” |
Neutral phrasing isn’t only politeness. “Invalid card” implies the customer did something wrong when the cause is usually the bank — and the difference determines whether they retry or leave — Voice and Tone.
Accessibility
ERRORS ANNOUNCED aria-live, or move
focus to a summary
— Focus Management
FIELD ASSOCIATED aria-describedby links
the message to the input
NOT COLOUR ALONE icon plus text
— Colour Contrast
FOCUS TO FIRST on submit failure
ERROR
A red border with no text is invisible to a screen reader and ambiguous to everyone else — Accessible Forms.
Measuring it
- Field-level error rate — which fields fail, and how often — Form Analytics
- Repeat error rate — failing twice on the same field means the message didn’t help
- Abandonment after error — the cost, quantified
- Payment decline recovery rate — do they retry? — Involuntary Churn and Dunning
Repeat errors on the same field are the sharpest signal available — the person is trying, the message isn’t telling them what’s wrong, and each attempt raises the chance they leave.