Designing for Error
Assume every possible mishap will happen and protect against it. Treat human–machine interaction like a conversation: misstatements are normal; ask for clarification, don't beep. Think of the user's action as an approximation to what is desired.
Core checklist
- Understand error causes; design to minimize them.
- Sensibility checks — does the action pass the common-sense test? (Reject a 1000× radiation dose; query a transfer far larger than normal.)
- Make actions reversible (Undo) — the most powerful tool; or make irreversible actions hard. Deleted files → Trash, not gone.
- Make errors easy to discover and correct.
- Don't treat the action as an "error" — help the person complete it.
Specific techniques
- Add constraints to block errors: shape/size coding (different fluid openings/colors in cars; machine-readable medication codes); segregate easily-confused controls; hide irrelevant controls. Uses poka-yoke (mistake-proofing). See Forcing Functions — Interlocks, Lock-ins, Lockouts and Four Kinds of Constraints.
- Confirmations: weak against mistakes (people expect the dialog and click through; the close-window example). Make the object being acted on prominent, not just the action. Better than confirmation: reversibility + secretly saving "Don't Save" content.
- Minimize slips: don't demand constant conscious attention (skilled behavior must stay subconscious). Make actions/controls dissimilar and far apart; eliminate modes or make them very visible; provide perceptible feedback + undo.
- Warnings are usually not the answer: uncoordinated alarms create dangerous cacophony; people disable them. Warnings must attract attention and convey nature of the event; need coordination/standards.
Interruptions
A major source of (especially memory-lapse) error. Resuming costs more than the interruption time. Multitasking degrades performance. Borrow aviation's "sterile cockpit" — no non-essential talk during critical phases.
System-level: Swiss cheese remedies
Reduce accidents by: add more slices of cheese (lines of defense, checklists), reduce/shrink the holes (fewer error opportunities), alert operators when holes line up. "Design redundancy and layers of defense" (NTSB). See Root Cause Analysis and the Five Whys.
Resilience engineering & the automation paradox
- Resilience engineering: design systems/procedures/training to cope with complexity under pressure; treat safety as a core value, not a count; deliberately inject failures to test recovery. ("Safety shows itself only by the events that do not happen.")
- Paradox of automation: automation handles dull tasks well but gives up on the complex ones — exactly when it's needed — and fails without warning, leaving the human "out of the loop" (Royal Majesty grounding via undetected dead-reckoning mode error). See "Cases: Error & Accident Investigations".
Three summary principles
- Put knowledge in the world and allow expert operation from the head (Knowledge in the Head and in the World).
- Use natural & artificial constraints, forcing functions, natural mappings.
- Bridge both gulfs — make execution options and result-states visible.
Confidence
1.0 — explicit, extensive.
Sources: ["DOET ch.5 'Designing for Error' / 'Design Principles for Dealing with Error' p.198-216"]