Human-Centered Design Fundamentals

Design products that accommodate actual human cognition and behavior rather than expecting humans to adapt to arbitrary system requirements.

When to Use

✅ Use for:

• Physical product design (doors, appliances, controls, tools)

• Digital interface design (software, touchscreens, dashboards)

• System design where human error is critical (medical devices, industrial controls, aircraft)

• Redesigning systems after repeated user errors

• Creating instructions and documentation

• Error prevention and safety-critical systems

❌ NOT for:

• Pure visual design without functional components

• Marketing and brand identity

• Autonomous systems with no human interaction

• Systems where users have unlimited training time and perfect memory

Core Process

Seven Stages of Action Decision Tree

START: User encounters system │ ├─→ Is this GOAL-DRIVEN (user has objective)? │ ├─→ YES: Begin at Stage 1 (Form Goal) │ │ ├─→ Can user identify what they want? │ │ │ ├─→ NO: MISTAKE likely → Provide clear conceptual model │ │ │ └─→ YES: Proceed to Stage 2 │ │ │ │ │ ├─→ Stage 2: Plan action sequence │ │ │ ├─→ Are alternatives clear? │ │ │ │ ├─→ NO: MISTAKE likely → Improve discoverability │ │ │ │ └─→ YES: Proceed to Stage 3 │ │ │ │ │ ├─→ Stage 3: Specify action │ │ │ ├─→ Is correct action obvious? │ │ │ │ ├─→ NO: Gulf of Execution too wide → Add signifiers │ │ │ │ └─→ YES: Proceed to Stage 4 │ │ │ │ │ └─→ Stage 4: Perform action │ │ ├─→ Is user expert (subconscious execution)? │ │ │ ├─→ YES: High SLIP risk → Add forcing functions │ │ │ └─→ NO: Conscious execution → Provide clear affordances │ │ └─→ Is this EVENT-DRIVEN (environmental trigger)? └─→ YES: Begin at Stage 5 (Perceive state) ├─→ Stage 5: Perceive world state │ ├─→ Is feedback immediate (<0.1s)? │ │ ├─→ NO: Add immediate feedback │ │ └─→ YES: Proceed to Stage 6 │ ├─→ Stage 6: Interpret perception │ ├─→ Does system state make sense? │ │ ├─→ NO: Gulf of Evaluation too wide → Improve conceptual model │ │ └─→ YES: Proceed to Stage 7 │ └─→ Stage 7: Compare with goal ├─→ Is outcome clear? │ ├─→ NO: Add better feedback + conceptual model │ └─→ YES: Action cycle complete │ └─→ Goal achieved? ├─→ NO: Return to Stage 2 (new plan) └─→ YES: END

Design Evaluation Decision Tree

EVALUATE DESIGN: Start here │ ├─→ Discoverability Check │ ├─→ Can user determine possible actions without instructions? │ │ ├─→ NO: Missing signifiers → Add visible indicators │ │ └─→ YES: Check constraints │ │ │ ├─→ Are constraints visible and effective? │ │ ├─→ NO: Add physical/semantic/cultural/logical constraints │ │ └─→ YES: Check mapping │ │ │ └─→ Is control-to-effect mapping natural? │ ├─→ NO: Redesign spatial relationships or use cultural conventions │ └─→ YES: Proceed to Understanding Check │ ├─→ Understanding Check │ ├─→ Does system image communicate conceptual model? │ │ ├─→ NO: Improve structure, labels, documentation │ │ └─→ YES: Check feedback │ │ │ ├─→ Is feedback immediate and informative? │ │ ├─→ NO: Add/improve feedback mechanisms │ │ └─→ YES: Check processing levels │ │ │ └─→ Are all three levels addressed? │ ├─→ Visceral: Is it aesthetically appealing? │ ├─→ Behavioral: Does it support learned patterns? │ └─→ Reflective: Will memory of use be positive? │ └─→ Error Prevention Check ├─→ What error types are possible? │ ├─→ SLIPS (execution errors)? │ │ └─→ Add forcing functions, reduce steps, prevent capture │ ├─→ MISTAKES (planning errors)? │ │ └─→ Improve conceptual model, add feedforward │ └─→ MEMORY LAPSES? │ └─→ Put knowledge in world, add reminders, minimize steps │ ├─→ Are modes present? │ ├─→ YES: MODE ERROR risk │ │ ├─→ Can you eliminate modes? │ │ │ ├─→ YES: Eliminate them │ │ │ └─→ NO: Make current mode extremely salient │ │ └─→ Does security exceed human capability? └─→ YES: Users will create workarounds → Redesign for actual capabilities

Root Cause Analysis Process

INCIDENT OCCURS │ ├─→ Ask: "What happened?" (Identify symptom) │ └─→ Document observable failure │ ├─→ Ask: "Why did this happen?" (First cause) │ ├─→ Answer: "Human error" │ │ └─→ NEVER STOP HERE - This is anti-pattern │ └─→ Continue investigation │ ├─→ Ask: "Why did the human make that error?" (Second why) │ ├─→ Was signifier missing/unclear? │ ├─→ Was feedback absent/poor? │ ├─→ Was mapping unnatural? │ ├─→ Was conceptual model wrong? │ └─→ Continue for each factor │ ├─→ Ask: "Why was design inadequate?" (Third why) │ └─→ Investigate design process failures │ ├─→ Ask: "Why did process fail?" (Fourth why) │ └─→ Investigate organizational factors │ ├─→ Ask: "Why did organization allow this?" (Fifth why) │ └─→ Reach fundamental systemic cause │ └─→ DECISION: Fix person or fix system? ├─→ Multiple people made same error? │ └─→ YES: System design failure → REDESIGN SYSTEM └─→ Isolated incident with unique circumstances? └─→ Investigate further - may still be system issue

Anti-Patterns

🚫 Blaming Human Error

Novice approach:

• Incident occurs

• Investigation identifies operator action as proximate cause

• Conclusion: "Human error - operator needs retraining"

• Action: Discipline/replace operator, add more warnings

• Timeline: Immediate blame assignment within hours/days

Expert approach:

• Incident occurs

• Acknowledge human action as symptom, not cause

• Apply Five Whys: "Why did operator make that choice?"

• Discover: Ambiguous signifier, mode confusion, inadequate feedback, excessive memory load

• Conclusion: "System failed to support human capabilities"

• Action: Redesign interface to prevent error conditions

• Timeline: Weeks of investigation to understand systemic factors

Shibboleth: "If an error is common, it's a design failure. Human error usually is a result of poor design: it should be called system error."

🚫 Norman Doors (Signifier Failure)

Novice approach:

• Design beautiful door with minimal visual interruption

• Use identical hardware on both sides

• Add small "PUSH" sign when people struggle

• Blame users for not reading sign

• Timeline: Sign added after first complaints (days)

Expert approach:

• Design inherently communicates operation

• Push side: Flat plate (anti-affordance for pulling)

• Pull side: Vertical handle (affordance for gripping)

• Hinge side visible where applicable

• No signs needed - hardware IS the signifier

• Timeline: Correct from initial design specification

Shibboleth: "The design of the door should indicate how to work it without any need for signs, certainly without any need for trial and error."

🚫 Mode Errors

Novice approach:

• Single button performs different functions in different modes

• Mode indicated by small icon or buried in menu

• User manual explains mode system

• "Users should remember current mode"

• Timeline: Mode confusion appears immediately but attributed to user error

Expert approach:

• Minimize modes entirely - use different controls for different functions

• If modes unavoidable: Make current mode EXTREMELY salient

• Use forcing functions to prevent dangerous mode transitions

• Physical mode indicators that cannot be overlooked

• Test with interruptions to verify mode clarity

• Timeline: Mode clarity validated during prototype testing before release

Shibboleth: "Mode errors are design errors. When equipment has multiple modes, the equipment must make the mode clearly visible."

🚫 Knowledge-In-Head Assumption

Novice approach:

• Expect users to memorize 8+ character passwords with mixed case, numbers, symbols

• Require remembering multi-step procedures

• Provide training once, assume retention

• "Users need to pay more attention"

• Timeline: Password policies created in single meeting

Expert approach:

• Recognize working memory holds 3-7 items, fragile under interruption

• Design puts knowledge in world: Structure, constraints, visible reminders

• Multi-factor authentication: "Something you have" + "something you know"

• Procedures self-evident from interface structure

• Checklists and external aids for critical sequences

• Timeline: Iterative testing reveals memory failures; design evolves

Shibboleth: "The most effective way of helping people remember is to make it unnecessary. Put required knowledge in the world."

🚫 Missing Feedback

Novice approach:

• Button press triggers background process

• No indication action was received

• User unsure if click registered

• User clicks multiple times ("button mashing")

• System processes multiple requests

• Timeline: Complaint emerges after users discover duplicates (days/weeks)

Expert approach:

• Immediate feedback within 0.1 seconds of action

• Button shows depressed state

• Progress indicator for operations >1 second

• Clear completion confirmation

• Prevent duplicate actions through lock-in forcing function

• Timeline: Feedback designed into initial prototype

Shibboleth: "Feedback must be immediate, informative, and appropriately prioritized. Poor feedback can be worse than no feedback."

🚫 Aesthetics Over Usability

Novice approach:

• Hide all controls for visual minimalism

• Invisible door hardware (smooth glass)

• Touch-sensitive surfaces with no tactile feedback

• "Clean design" means featureless

• Timeline: Awards received; usability complaints ignored for years

Expert approach:

• Beauty and usability need not conflict

• Controls visible but elegantly integrated

• Signifiers enhance rather than detract from aesthetics

• Address visceral (beauty) AND behavioral (usability) AND reflective (pride of ownership)

• Timeline: Iterative prototypes balance all three processing levels

Shibboleth: "Attractive things work better - but only when they ALSO work well. Good design is invisible because it fits needs perfectly."

🚫 Excessive Security Theater

Novice approach:

• 12+ character passwords changed monthly

• Complex rules: uppercase, lowercase, numbers, symbols, no dictionary words

• Multiple authentication steps for routine tasks

• Lock users out after 3 failed attempts

• Timeline: Security policy implemented top-down in single quarter

Expert approach:

• Recognize humans cannot remember 50+ complex passwords

• Accept reality: Excessive security → insecurity via workarounds

• Users write passwords on monitors, use "Password123!", disable locks

• Design FOR human limitations: Password managers, biometrics, tokens

• Balance security with usability to prevent counterproductive behavior

• Timeline: Security usability testing reveals actual user behavior; policy adjusted

Shibboleth: "Making systems too secure makes them less secure. We must accept human behavior the way it is, not the way we wish it to be."

Mental Models & Shibboleths

Gulf Metaphor:

• Novice: "Users need training to cross the gulf"

• Expert: "Designer builds bridges across gulfs through signifiers (execution) and feedback + conceptual models (evaluation)"

Knowledge Distribution:

• Novice: "Users should memorize procedures"

• Expert: "Combination of person + artifact creates intelligence; design puts knowledge in world"

Error Attribution:

• Novice: "Operator error caused failure"

• Expert: "Never stop at human error - apply Five Whys to reach systemic cause"

Swiss Cheese Model:

• Novice: "Find the single root cause"

• Expert: "Accidents occur when holes in multiple defensive layers align simultaneously"

Action Cycles:

• Novice: "Users always start with clear goals"

• Expert: "Behavior can be goal-driven (top-down) or event-driven (opportunistic) - design supports both"

Processing Levels:

• Novice: "Focus on functionality"

• Expert: "Address visceral (immediate aesthetics), behavioral (learned patterns), and reflective (long-term memory and meaning)"

Temporal Knowledge

1988 (Original Edition): Focus on affordances; academic cognitive psychology perspective; "Psychology of Everyday Things" title emphasized scientific foundation

2013 (Revised Edition): Shifted emphasis from affordances to signifiers after recognizing confusion in digital design community; added chapters on emotion, experience design, and design thinking; incorporated business and industry perspectives from author's Apple/HP experience

Pre-automation era (<1900s): Direct physical manipulation; immediate mechanical feedback; human operators controlled complex systems with transparent cause-effect relationships

Modern automation (1900s-2000s): Separation of users from direct system control; new error modes from automation; "ironies of automation" where increased automation demands higher operator skill

Touchscreen era (2000s+): Loss of physical affordances; gesture-based interaction; metaphor shift from "moving window" to "moving text" scrolling; elimination of tactile feedback requiring stronger visual signifiers

Current challenge (2010s+): Balancing security requirements with human cognitive limitations; designing for interruption-heavy multitasking environments; accommodating aging populations with declining capabilities

References

• Source: "The Design of Everyday Things" (Revised and Expanded Edition, 2013) by Don Norman

• Original Edition: "The Psychology of Everyday Things" (1988)

• Foundation: Cognitive psychology research on human perception, memory, action, and error