Error Prevention
Better than a good error message is a design in which the error cannot occur.
Definition
Nielsen's fifth heuristic. Eliminate error-prone conditions, or check for them and present the user with a confirmation before they commit. Prevention operates on both slips, which are execution failures, and mistakes, which are planning failures.
Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.
On this plate
Reach for this when
- Designing any form or destructive operation.
- Reviewing error logs and support tickets for repeated user errors.
- Deciding between constraint, validation and confirmation.
Common mistakes
- Aggressive validation while the user is still typing.
- Confirmation dialogs used as a substitute for good constraints.
- Preventing slips while ignoring the mistakes, which are usually more costly.
- Preventing an error with a rule that is wrong in some legitimate cases, and offering no way past it.
Slips and mistakes need different fixes
Norman's distinction is load-bearing here. A slip is doing the wrong thing while intending the right thing, such as tapping the adjacent button. A mistake is doing the intended thing where the intention was wrong, such as deleting the correct file believing it was a duplicate.
Slips are prevented by physical design: bigger targets, more spacing, separation of destructive from frequent actions. Mistakes are prevented by information: better labels, previews, and showing consequences before commitment.
Prevention techniques, strongest first
- Remove the possibility. Do not offer a state the system cannot honour.
- Constrain the input. A date picker cannot produce the 31st of February.
- Use good defaults, so the common case needs no decision.
- Separate destructive from frequent actions in space and in style.
- Validate in real time on the field, with helpful text before submission rather than a red wall after it.
- Preview the consequence, such as showing what will be deleted and how many items that is.
- Confirm only what is genuinely irreversible.
Prevention techniques, and what each rules out
| Technique | Error it removes |
|---|---|
| Constrain the input, as with a date picker for a date range | Impossible values entered in good faith |
| Sensible default | The error of not knowing what to choose |
| Separate destructive actions physically | The slip of hitting the wrong adjacent control |
| Confirm with the object's name typed in | Deleting the right kind of thing, wrongly chosen |
| Make the safe path the fast one | Errors caused by people routing around friction |
| Undo instead of confirmation | The cost of the error, rather than the error itself |
In practice
- i.
Disabling unavailable dates
BookingA calendar that greys out unavailable dates removes an entire error class. The user cannot select a date that will be rejected, so the rejection message never has to exist.
- ii.
Separating destructive actions
File managementPlacing delete in an overflow menu rather than adjacent to a frequently used action removes the most common slip in list interfaces at zero cost to discoverability.
- iii.
The date range that could not be inverted
Constraint over validationA picker that greys out any end date before the start date removes an entire class of error message. Validating afterwards and explaining the rule is the same work done later and worse.
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.
Help Users Recognise, Diagnose and Recover From Errors
HeuristicHelping the reader recognise what went wrong, understand why, and fix it.
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 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.
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.
Learn about Help Users Recognise, Diagnose and Recover From Errors
Local chart
HEUR·005 · Region I · Grid B1
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
10 Usability Heuristics for User Interface Design
J. Nielsen, Nielsen Norman Group, 1994, revised 2020
- [2]
The Design of Everyday Things
D. A. Norman, Basic Books, 1988, revised 2013
Source of the slips and mistakes distinction.
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.
Applies when you are designing
Applied through
Where this shows up as a concrete interface decision.
- Date PickerCMP·009 · Component
- ConfirmationPAT·008 · Pattern
- Destructive ActionsPAT·009 · Pattern
- Input ValidationPAT·007 · Pattern
- UndoPAT·022 · Pattern
- Heuristic EvaluationRES·002 · Research method
- Error MessagesWRT·002 · UX writing
Check your work
Review passes that test whether this was done properly.
- Form UX ChecklistCHK·001 · Checklist
Related concept
Connected closely enough to change how you apply this.
- User Control and FreedomHEUR·003 · Heuristic
- Fitts's LawLAW·002 · Law
- Postel's LawLAW·012 · Law
- Tesler's LawLAW·005 · Law
- ConstraintsPRIN·009 · Principle
- ForgivenessPRIN·006 · Principle