Mental Models a field guide

Tool/Design and Human Factors/No. 0333

Error Prevention

Error prevention is the design of products and tasks to reduce mistakes before they occur. In human factors and Jakob Nielsen’s usability heuristics, it includes removing risky conditions, adding checks, and making actions that conflict with clear rules hard or impossible to complete.

a tool: pick it up
Evidence
Well established
Read
6 min
Links
13 connections
Useful when
Designing products · Risk and safety · Running projects

01You've seen this when…

  1. in life

    You nearly send a message to the wrong Alex. Their profile photo beside the recipient’s name makes you pause before tapping Send.

  2. at work

    A reimbursement page stalls after you submit it. You click again, unsure whether the first click worked. The system recognizes the repeated request and creates one payment.

  3. out in the world

    At a parking garage, the payment machine holds your ticket until you take your bank card back. You leave with both.

02The idea

A form accepts an impossible date. Two adjacent buttons perform very different actions. A machine starts while its access panel is open. Each design leaves a predictable route to an error.

Error prevention changes that route before someone takes it. It can remove an unnecessary decision, make the safe action easier to recognize, reject an invalid entry, or require a deliberate check before an irreversible step. A physical constraint might keep a part from fitting backward. A software rule might prevent a booking from ending before it begins.

Human-factors researchers distinguish slips from mistakes. A slip happens when someone understands the task but executes it incorrectly, such as selecting the neighboring file. A mistake happens when the person’s understanding or plan is wrong, such as assuming that deleting a shared file affects only their own copy. Good prevention addresses both: clear controls support execution, and clear consequences support understanding.

The strongest safeguard matches a specific error to a specific design change. Affordances and signifiers help people recognize possible actions. Constraints limit which actions can actually happen. Recovery options remain useful because a designer cannot anticipate every failure.

03How to use it

  1. Trace one risky task from beginning to end. Watch people perform it in context. Include interruptions, unfamiliar users, accessibility needs, and slow connections. Record where an error begins and what harm follows. Usability testing often reveals trouble that a design review misses.
  2. Name the error precisely. Write something observable: a user selects the wrong recipient, submits the same payment twice, or enters an end date earlier than the start date. Separate an execution slip from a misunderstanding; each needs a different safeguard.
  3. Remove unnecessary opportunities for error. Reuse information the system already has. Reduce repeated entry. Separate easily confused controls. Make relevant details visible at the moment of action, reducing the demands on working memory.
  4. Enforce rules the system can know. Block impossible date ranges, unsupported file types, or duplicate processing of the same request. Explain the rule beside the affected control and show how to proceed. A valid format alone cannot establish that a value is correct.
  5. Reserve deliberate checks for consequential choices. Before a bank transfer, show the recipient, amount, and account together. Give users enough context to verify the transaction. Match the interruption to the potential harm; a generic confirmation on every click soon becomes routine.
  6. Test the safeguard and its side effects. Measure completed tasks, errors, blocked legitimate actions, and workarounds. Try impatient clicking, repeated requests, and unexpected inputs. Keep system status visible, and preserve a way to recover when prevention fails.

Start with a frequent or costly error. One well-targeted change is easier to test than a collection of warnings added throughout a workflow.

04A worked example

Consider an illustrative expense system. An employee submits an $840 reimbursement. The page gives no visible response while the server processes it. The employee clicks Submit again, and the system creates two reimbursement records.

What it looks like An impatient employee has caused a duplicate. The team proposes a reminder asking everyone to click only once.

What’s actually going on The interface leaves the employee uncertain about whether the action succeeded. The backend also treats each click as a fresh instruction. A predictable response to uncertainty can therefore produce a financial error. Disabling the button helps with repeated clicks on that page, but requests can also be repeated by a refresh or a network retry.

The revised design immediately shows that submission is underway. Each logical submission carries a stable request identifier, and the server records and checks that identifier so retries return the existing result. When processing finishes, the page shows the reimbursement’s status. A separate, explicit action lets the employee begin another claim.

What made it work The team paired visible feedback with a rule enforced where records are created. It defined a duplicate as repeated processing of the same request. Two legitimate claims for $840 can still proceed. Testing includes rapid clicking and a lost network response, since both can trigger repetition.

05When to reach for it

Use error prevention when people repeatedly make the same mistake, especially during routine work. Frequent errors around one control or handoff suggest a design problem that deserves inspection.

It is especially valuable when actions are expensive, dangerous, or difficult to reverse; users are rushed or distracted; or newcomers must act without training. In safety-critical work, combine prevention with detection and recovery through defense in depth. Each safeguard can have its own failure modes.

06When it misleads

  • Warnings can become background noise. Repeated confirmations train people to dismiss them automatically. Place a check where the consequence changes, and make the details specific enough to inspect. Added behavioral friction earns its place when it reduces a defined risk.
  • The system can enforce the wrong rule. A rigid form may reject a legitimate name, address, or unusual transaction. Check assumptions against actual users and provide a controlled exception path. Excessive restrictions can drive people into unofficial workarounds.
  • A safeguard can protect only the visible surface. A disabled button leaves other routes open if the server still accepts duplicate requests. Identify where the consequence occurs and enforce the relevant rule there.
  • Prevention can create false confidence. An accepted value may still be wrong. A plausible account number can belong to someone else. Show the limits of validation, retain useful recovery options, and preserve user control.

For high-consequence tasks, evaluate the whole workflow. A local reduction in mistakes can be outweighed by confusion, delays, or a new failure introduced elsewhere.

07Roots

On factory floors in Japan, industrial engineer Shigeo Shingo promoted ways to catch errors at the step where they began. A missing part discovered after assembly meant inspection and rework. A fixture, sensor, or counting device could expose the problem while the worker still had the assembly in hand. His approach became associated with poka-yoke, usually translated as mistake-proofing, and he described it in his 1986 book on source inspection.

Software designers faced a related problem. Users could receive an accurate error message only after an interface had allowed them into trouble. Jakob Nielsen and Rolf Molich developed heuristic evaluation: inspecting interfaces against a small set of usability principles. Nielsen’s widely used 1994 list included error prevention among its ten heuristics, giving reviewers a prompt to examine the conditions preceding an error.

Error prevention has broader roots in human-factors engineering, so Nielsen’s contribution was its influential formulation for interface design. Donald Norman’s work helped explain why safeguards must account for both execution slips and mistaken understanding. Across these traditions, responsibility expands from the person performing the task to the conditions in which the task is performed.

08How solid is this?

ContestedMixedUsefulEstablished

Error prevention is an established human-factors design principle, and well-specified constraints can eliminate particular invalid actions. The effectiveness of a safeguard depends on task-specific testing; Nielsen’s heuristic supplies no universal effect size or guarantee of safety.

09Connections

counterscounterscounterspart ofErrorPreventionNot written yetWorking MemoryHabituationSwissCheese ModelDefensein DepthCognitiveOffloadingBehavioralFrictionNot written yetUsabilityTestingNot written yetSignifierNot written yetVisibility ofSystem StatusNot written yetUser Controland Freedom

+ 3 more in the list

10Origin and sources

Developed across human-factors engineering and industrial mistake-proofing. Jakob Nielsen included error prevention in his influential 1994 usability heuristics, building on earlier work with Rolf Molich.

  1. [1]Nielsen, J. (1994). Enhancing the explanatory power of usability heuristics. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 152–158.
  2. [2]Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books.
  3. [3]Shingo, S. (1986). Zero Quality Control: Source Inspection and the Poka-Yoke System. Productivity Press.

Suggest an edit· Updated 2026-10-02