Error Prevention and Recovery
An error prevented is strictly cheaper than an error caught: even a well-written error message still means an interruption and a fix the user has to make, while a prevented error costs nothing at all — the same reasoning Error Messages already leans on in its own rule that avoiding a message entirely beats writing a good one. That doesn’t make recovery unnecessary, since no interface prevents every possible error, but it does mean prevention deserves the first design effort, with detection and recovery as the layers that catch whatever prevention couldn’t.
An error prevented is strictly cheaper than an error caught: even a well-written error message still means an interruption and a fix the user has to make, while a prevented error costs nothing at all.
Diagnose before you can prevent: slips vs. mistakes
Usability Engineering‘s two-part taxonomy of human error sets up everything below it: a slip is the right goal carried out via the wrong action — a typo, clicking the wrong menu item — typically a failure of automatic behavior rather than judgment; a mistake is a wrong goal, deliberately chosen, where the underlying plan itself was flawed. The two call for different fixes: a slip is addressed by making the correct action easier to execute and the wrong one harder to fall into by accident (the rest of this page); a mistake is addressed by better information at the planning stage — clearer options, clearer consequences — before the user commits to a plan at all. A mode error is the sharpest example of a slip: the action was right for the mode the user believed was active, wrong for the one that actually was.
Eliminate the error, don’t just catch it
The most effective prevention removes the error-prone condition rather than watching for it. Poka-yoke (“mistake-proofing”), Shigeo Shingo’s term from the Toyota Production System, names this directly: redesign a task so the mistake can’t physically happen, rather than trusting a person to avoid it through care alone. A keyed connector (HDMI, USB-C) that only fits one way is the classic physical case; a car that won’t start out of gear, or a microwave that stops the instant its door opens, are others. The interface equivalent is a control constraint: a submit button disabled until required fields are filled, an option that can’t be selected until its prerequisite is met, an amount field that won’t accept a value the account can’t cover. Where elimination genuinely isn’t possible, the weaker fallback is a warning — a signal delivered before the mistake completes, giving the user a chance to stop, rather than a message that only arrives after the fact. This is the same territory exploiting constraints and designing for error occupy among Norman’s own operationalizations of user-centered design — two entries on the same list as explaining affordances, not a separate concern.
Redesign a task so the mistake can’t physically happen, rather than trusting a person to avoid it through care alone.
Catch what elimination can’t reach
Some conditions can’t be designed away entirely, so the next layer is noticing an error as close to the moment it happens as possible — the same principle field-level validation already applies: catch a problem at or before submission rather than letting it travel further into the system undetected. The wider version of the same idea is error-tolerant design: an interface built to accept honest variation in what a person actually does, rather than treating every deviation as invalid. A spell-checker that flags a probable typo and suggests a fix, instead of just rejecting the word outright, is doing detection and a first pass at recovery in the same motion.
When you can’t prevent it, make it survivable
Some actions genuinely can’t be made safe by elimination or detection alone — a destructive action still has to be possible for the interface to be useful. Two mitigations do most of the remaining work: a confirmation step for a consequential action, defaulting to the harmless choice rather than the destructive one so an unthinking click doesn’t confirm the mistake; and a reversible design — Undo, a trash or recycle bin the user can restore from — that turns a completed mistake back into a survivable one instead of a permanent one. Both are explicitly the fallback layer, not the first line: a confirmation dialog that fires on every routine action trains the same habituation a modal window risks generally, and undo is a safety net for what prevention missed, not a substitute for preventing the common case.
Undo is a safety net for what prevention missed, not a substitute for preventing the common case.
Related Concepts
Patterns
Principles
Processes
Further reading
Nielsen Norman Group’s Confirmation Dialogs Can Prevent User Errors (nngroup.com/articles/confirmation-dialog/ — copyright NN/g, no open license) and NN/g’s error-prevention heuristic material together add a sharper cost comparison than “prevention is better”: even the best error message still costs a user the interruption, the dented confidence, and the cognitive overhead of recovering, while a genuinely prevented error keeps their attention on the task uninterrupted — and give practical confirmation-dialog guidance (a harmless default action, wording that names the actual consequence rather than a generic “Are you sure?”).
Sources
Poka-yoke (Wikipedia) is the source for poka-yoke itself — the mistake-vs-defect distinction, the warning-vs-control implementation types, the spring-switch worked example, and the keyed-connector/transmission/microwave examples.
Error-Tolerant Design (Wikipedia) is the source for the prevention/mitigation framing and the confirmation-dialog, trash-bin, and detect-and-suggest mitigation techniques under “When you can’t prevent it, make it survivable.”
The Design of Everyday Things (Wikipedia) is the source for “exploiting constraints” and “designing for error” as two of Norman’s own named operationalizations of user-centered design, alongside explaining affordances.