Evidence rating
Effect score (E): 4/5 Evidence for the underlying principle or measurement method.
Transfer score (T): 4/5 Evidence for reliable results in digital product practice.
Evidence level: High
[Plausible based on UX research] Analyze errors as an interaction between task, system, and context rather than attributing them prematurely to individual failure.
Scale and rating rules
Effect score: 5 established · 4 robust · 3 context-dependent · 2 weak · 1 preliminary.
Transfer score: 5 practice-proven · 4 field-supported · 3 partially supported · 2 plausible · 1 hypothesis.
Without a robust scientific or normative source, E is capped at 3. Blog and agency opinions support at most T=2. If evidence conflicts, the more conservative score applies until justified otherwise.
Evidence level: High = E ≥ 4 and T ≥ 3; Moderate = E ≥ 3; Preliminary = E ≤ 2 or T ≤ 1.
Error Models & User Errors
Errors are part of interacting with digital systems - but they are not a sign of stupidity, they can be systematically explained. UX design must understand and intercept them.
User errors are unintended actions or outcomes during interaction. Understanding whether an error is a slip or a mistake helps UX teams prevent it through clearer design and better recovery.
Definition
A user error is an unintentional action or an incorrect result that occurs when using a system - regardless of whether the system works “correctly”.
The three error types at a glance
The practical distinction is where the problem starts: execution, memory or planning. Norman distinguishes slips from mistakes; Reason also names lapses and describes how mistakes can arise.
| Type | What goes wrong? | UI example | Useful design response |
|---|---|---|---|
| Slip | The user has the right goal but performs the wrong action | They select Delete instead of Archive because the controls are adjacent | Separate and label controls; offer undo |
| Lapse | The user forgets an intended step | After an interruption, they submit a form without completing a required field | Show progress and missing steps; preserve entered data |
| Mistake | The user’s goal, assumption or chosen rule is wrong | They choose “Save” expecting the item to be shared with the team | Explain concepts and consequences before the action |
Slip: the right intention, the wrong action
A slip happens during execution. Someone may click the wrong control, mistype a value or repeat an action without noticing. The user knows what they want to do; the interface or context makes the intended action easy to miss.
Design focus: prevent near-misses with clear labels, adequate spacing and visible states. Make recovery easy with undo rather than relying only on a confirmation dialog.
Lapse: an intended step is forgotten
A lapse is a memory failure, not a wrong decision. For example, a user returns to a multi-step form after a phone call and overlooks a required address field.
Design focus: keep progress visible, identify incomplete fields at the point of need and preserve work when users navigate back.
Mistake: the plan or assumption is wrong
A mistake happens during planning or interpretation. A user may misunderstand a label, apply a familiar rule in a new situation or form an incorrect idea about what the system will do. In Reason’s model, mistakes can be rule-based (the wrong rule is applied) or knowledge-based (the situation is unfamiliar and the user reasons from incomplete information).
Design focus: use language users understand, make consequences explicit and align interface concepts with the system’s actual behavior.
How the models differ
Norman’s distinction focuses on whether the action or the intention is wrong: slips versus mistakes. Reason’s model also includes lapses and further classifies mistakes as rule-based or knowledge-based. A lapse is not simply another kind of mistake.
Design Against Errors
| Principle | Implementation |
|---|---|
| Error tolerance | Undo, restore, queries before deletion actions |
| Feedback & status displays | What has been done? What is happening right now? |
| Error avoidance instead of error handling | Deactivate buttons instead of showing warning later |
| Consistency | Recognizable symbols, navigation, layouts |
| Explicit labeling | ”Cancel” instead of “Back” |
A practical error-prevention process
- Observe where users make slips or form incorrect assumptions.
- Classify the error as an execution problem, a missed step or a planning problem.
- Remove avoidable error opportunities before adding warnings.
- Add feedback, undo and recovery for errors that remain possible.
- Re-test the complete flow with representative users.
For example, if users repeatedly submit a form with a missing delivery address, first make the required field and its error state visible, then preserve entered data and provide a clear route to correct it. A warning alone does not address the underlying interaction problem.
Conclusion
User errors do not occur because people are unfocused or incompetent - but because systems are designed to be complex, ambiguous or error-prone.
UX design should focus on being error-friendly rather than error-free.
Take Home Message
Errors are systemic - not individual. Good design makes mistakes unlikely and reversible.
Frequently asked questions (FAQ)
What are user errors in UX design?
What types of errors does Donald Norman distinguish?
What does James Reason's error model describe?
How can UX design avoid errors?
Why do errors often arise from the system and not from humans?
Science corner: evidence data
- Setting
- Laboratory and field observations of human interaction
- Replication status
- Replicated / repeatedly studied
- Evidence level
- High (E=4, T=4)
- Key sources (APA)
-
- Norman, D. A. (1981). Categorization of action slips. Psychological Review, 88(1), 1–15. https://doi.org/10.1037/0033-295X.88.1.1
- Reason, J. (1990). Human error. Cambridge University Press. https://doi.org/10.1017/CBO9781139062367
- Rasmussen, J. (1983). Skills, rules, and knowledge; signals, signs, and symbols, and other distinctions in human performance models. IEEE Transactions on Systems, Man, and Cybernetics, SMC-13(3), 257–266. https://doi.org/10.1109/TSMC.1983.6313160
- Review date / version
- 2026-11-01 · 1.1
- Next review
- 2027-11-01 (Review cycle: 12 months)
Last modified: 1 November 2026