interaction design
Error prevention
What is error prevention, and why is it better than a good error message?
Error prevention is designing so a mistake can't happen in the first place - constraints, sensible defaults, disabling impossible actions, formats that can't be entered wrong - rather than letting the slip occur and catching it with a message afterwards. The best error is the one the interface made impossible to make.
Also known as: error prevention, preventing errors, poka-yoke
Prefer to watch?
Watch the recap 0:47
The demo
Pick how many to buy - there are five in stock. Try it as a control that won't let you go wrong, then as a box that lets you, then scolds you.
What this demo shows (text version)
Choosing a quantity (five in stock) is shown two ways. In "prevent", a stepper with minus and plus buttons is clamped to the valid range: the minus disables at zero, the plus at five, so you physically cannot choose an impossible amount. There's no error to make.
In "catch", a free text box accepts anything - 99, -2, even letters - and only when you press "Add to basket" does it tell you the value was wrong. You did the work, then got the message. The lesson: a clear error message is a fallback, not a goal; designing the mistake out with a constraint is better than catching it afterwards. Keep good messages for the errors you genuinely can't prevent.
A good error message is a consolation prize; preventing the error is the win. Constrain inputs so invalid values can't be entered, disable actions that aren't yet valid, and use formats and defaults that make mistakes structurally impossible - then keep clear, kind messages for the errors you genuinely can't design out. Stop the slip before it happens; explain only what's left.
Preventing it, you simply couldn't go wrong - the control wouldn't let you exceed the stock or type nonsense, so there was no error to fix. Catching it, you did the work, hit submit, and only then got told off. Same goal; one path made the mistake impossible, the other waited to scold you for it.
Prevention beats cure because catching an error always costs the user something they'd already spent: the effort of the wrong input, the interruption of the message, the rework to put it right. Designing the mistake out - so the value can't be invalid, the button can't be pressed too early - spares all of that.
The toolkit is constraints and good defaults. Steppers and pickers that only offer valid values, inputs that accept any reasonable format and normalise it, actions disabled until their preconditions are met, destructive options kept out of easy reach. Each removes a class of error structurally, rather than relying on the user to be careful.
Prevention doesn't replace good error messages - it shrinks the set you still need. Some errors can't be designed away (a genuinely wrong password, a name typo), so for those, be clear, specific and kind: say what went wrong, where, and how to fix it. Prevent what you can; explain what you can't.