Foundations

Error Prevention

Designing interfaces that prevent errors before they happen — and recover gracefully when they do.

#errors#prevention#validation#confirmation#constraints#recovery#undo

What is it?

Error prevention is the practice of designing systems that reduce the likelihood of users making mistakes — and recovering gracefully when they do. It is Nielsen's 5th heuristic and arguably one of the most impactful: it's far better to prevent a problem than to show a good error message after it occurs.

Why it matters

Errors are expensive — for users (time and frustration) and for businesses (support costs, lost conversions, data problems). A well-designed error prevention strategy can reduce support tickets by 30–50%, improve form completion rates, and dramatically increase user confidence.

Best Practices

Use constraints to make errors impossible: if a field accepts only numbers, show a numeric keypad on mobile and reject letters on desktop.
Provide inline format hints before users make mistakes: "MM/DD/YYYY" before the date field, not after the error.
Validate in real-time (on blur) so users catch errors immediately, not after completing the whole form.
For destructive actions, require confirmation and make the action reversible where possible.
Use sensible defaults that are correct for most users — reducing the chance of accidental wrong values.
For high-stakes operations (delete, payment, publish), implement a confirmation dialog that summarizes what will happen.
Provide undo functionality for reversible actions instead of confirmation dialogs — undo is faster and more forgiving.
Show password requirements before the user fails, not after. Display them as they type.
Limit free text where possible. Use selectors, pickers, and autocomplete to constrain input.
On forms with many fields, save progress automatically — preventing loss of work on error.

Common Mistakes

Only validating on form submit — users complete everything before learning field 2 was wrong from the start.
Not showing password requirements until the user has already failed.
Using irreversible destructive actions without confirmation dialogs.
Ambiguous action labels: "Submit" on a destructive operation. The label should say what will happen: "Delete Account."
Hiding format requirements as placeholder text that disappears when the user starts typing.
Not preserving form data when validation fails — users have to re-enter everything.
Confirmation dialogs with "Yes/No" — these don't convey the action. Use "Delete/Cancel" or "Confirm Purchase/Cancel."

Checklist

Input fields use constraints where possible (numeric keyboard, date pickers, dropdowns)

Format requirements are shown before the field, not only on error

Validation fires on blur (not only on submit)

Destructive actions have a confirmation dialog with specific action language

Reversible actions offer undo instead of confirmation

Password requirements are shown during typing, not only on failure

Form data is preserved when validation fails

Sensible defaults are pre-selected

Error recovery paths are designed and tested

Action labels describe outcomes, not just the action ("Delete Account" not "Submit")

Research & Theory

Nielsen's Heuristic #5: Error Prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them.

Why it's relevant

Error prevention is more impactful than error recovery. Invest in prevention first.

The Cost of Errors (Baymard Institute)

Baymard research shows that form errors cause 27% of checkout abandonment. Specific: "unclear error messages" and "finding errors only on submit" are the top causes.

Why it's relevant

In e-commerce, error prevention in checkout forms has direct, measurable revenue impact.

Slips vs. Mistakes (Norman)

Slips are unintentional errors (muscle memory, typos). Mistakes are intentional but incorrect actions. Design prevents slips through constraints; it prevents mistakes through confirmation.

Why it's relevant

Know which type of error you're designing against — the prevention strategy is different for each.

Real-World Examples

GitHub

To delete a repository, you must type the full repo name. This constraint makes accidental deletion practically impossible — while keeping the action available.

Stripe

Card inputs auto-detect card type (Visa/Amex/etc.), format the number as you type, and validate in real time. Errors are shown instantly with specific guidance.

Google Forms

Required fields are marked before submission. Format guidance is shown inline. Responses are auto-saved. Losing work is nearly impossible.