B3.05.1Error Preventiondesignresearch

Eliminating error conditions beats providing error messages

Aliases: error prevention · constraint design · mistake proofing

What it is

The priority of error prevention is to make erroneous actions impossible, unavailable, or automatically corrected; messaging comes afterward. Messages still matter, but if users must commit an error before learning the rule, the design has shifted validation work onto them.

Why it happens

Messages arrive when attention is strained and motivation is anxious; users must read a rule, go back, and reinterpret state, which costs more than a prior constraint. Conditions can be removed through legal-only choices, automatic format handling, disabling conflicting objects, physical or logical constraints, scoped defaults, and templates. Good prevention preserves exceptions but routes them through explicit permission or process rather than letting everyone hit the wall.

Studying it

Collect error logs and support tickets, classifying them by trigger, field, device, role, and task stage. Compare constraints, immediate validation, and post-submit messages in task experiments: measure first-attempt success, errors, correction paths, time, frustration, and repeated mistakes. The key question is whether the error can be designed out, not merely how often it occurs.

Where it stops holding

Over-prevention blocks legitimate exceptions and slows experts; narrow inputs, forced formats, and permanent disabling can create accessibility problems. Some errors originate in upstream data or organizational rules and cannot be eliminated by one interface. Messages and recovery remain necessary because not every context can be anticipated.

Applying it

  • For each frequent error, ask whether selection, templates, defaults, range limits, or automatic conversion can eliminate it.
  • Disable only truly unavailable options and explain why plus how to recover; pair every message with an executable correction.
  • Handle formats at input time—phone, date, currency, units—rather than making users guess parsing rules.
  • After release, track whether the error disappears, moves elsewhere, or creates a new one, and keep a support channel.

Related

  • Same group: B3.05.2 Distinguish slips from mistakes and apply different prevention · B3.05.3 High-consequence operations need extra confirmation or delay
  • Nearby: B2.05 Constraints · Y3 Error Prevention and Recovery
  • Search terms: error prevention · poka-yoke · input validation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/B3.05.1