Core Idea
- Good design is invisible—it anticipates user errors and makes the right action obvious without instruction manuals or blame
- Human "error" is a design failure—when many people struggle with something, redesign the system, not the person
Make Actions Obvious
- Use signifiers (visual/auditory cues) to show where and how to act; affordances alone don't guide behavior
- Employ natural mappings: arrange controls to spatially match what they control (e.g., stove knobs in grid matching burners)
- Combine knowledge in the head with knowledge in the world—don't force memorization of arbitrary conventions
- Provide immediate feedback (within 0.1 seconds) so users know actions registered
Prevent Errors Through Constraints
- Physical constraints: design components to work only one correct way (battery orientation, incompatible plugs)
- Semantic constraints: make purpose visually obvious through shape and appearance
- Cultural/logical constraints: leverage conventions (hot=left) and eliminate options as users progress
- Forcing functions: use interlocks and lockouts to make wrong sequences impossible (e.g., ATM card retrieval before cash)
When Errors Happen, Minimize Damage
- Make actions reversible (Undo)—one mistake won't cascade into disaster
- Display system state clearly at all times; make current goals/plans visible continuously
- Add sensibility checks: flag anomalies (transaction amount 10x normal, medication dose far beyond range)
- Create redundancy: multiple independent safety layers prevent single failures from causing harm
Root Cause Analysis, Not Blame
- Ask "Why?" five times to find underlying design flaws, not just surface human error
- When investigating failures, ask "Why did the system allow this?" not "Why did the person fail?"
- Reward error reporting in organizations—punishing errors hides design problems that will strike again
Design for Real Conditions
- Assume users will be interrupted, fatigued, multitasking, or under pressure—build safeguards around this reality
- Use checklists done collaboratively (one reads, one executes, one checks) for high-risk work
- Avoid warning fatigue: sparingly use alarms; most warnings are ignored because they're too frequent
- Test with real users in realistic conditions before launch; lab testing misses real-world chaos
Action Plan
- Audit one daily object you design/control (app, form, physical product)—identify hidden controls, unclear feedback, or unmapped relationships between controls and effects
- Reframe the last user complaint you heard from "user error" to "design opportunity"—what constraint, signifier, or feedback would have prevented it?
- Apply one constraint type to your next design: physical, semantic, cultural, or forcing function
- Test with a real user who knows nothing about your design—watch where they fail silently; that's where signifiers are missing