Files of Case Studies: Design Analysis Using Norman's Principles
wondelai/
Show the full text312 lines
Case Studies: Design Analysis Using Norman's Principles
This collection of case studies applies Don Norman's design principles to real products, both physical and digital. Each case follows the same structure: the product, the design problem, the principle violated, a detailed analysis, the fix, and the broader lesson. These cases demonstrate that the same small set of principles explains why products are intuitive or infuriating.
Table of Contents
- Case Study 1: The Norman Door
- Case Study 2: The Thermostat Mental Model
- Case Study 3: Stovetop Burner Mapping
- Case Study 4: Airplane Cockpit Mode Errors
- Case Study 5: Hospital Medication Errors
- Case Study 6: ATM Interface Evolution
- Case Study 7: Smartphone Unlock Evolution
- Case Study 8: Smart Home Light Controls
- Cross-Cutting Patterns: What Makes Designs Intuitive vs. Confusing
Case Study 1: The Norman Door
Product
Commercial building doors with flat push-plates on both sides, or handles on a door that requires pushing.
Design Problem
People push when they should pull, and pull when they should push. This happens millions of times daily in buildings around the world. The problem is so pervasive that doors requiring a "Push" or "Pull" sign have become known as "Norman Doors."
Principles Violated
Affordances, Signifiers, Constraints
Analysis
A flat plate affords pushing. A handle affords pulling (and pushing, but the grip shape invites pulling). When a door has a handle on the side that requires pushing, the affordance (graspable handle) contradicts the required action (push). The user perceives a pull affordance, attempts to pull, fails, and then pushes. The "Push" sign is a signifier band-aid for a broken affordance.
The deeper failure is a missing constraint. If the door only opens one way, the hardware should make the wrong action impossible. A flat plate on the push side and a handle on the pull side creates a physical constraint: you cannot pull a flat plate.
Fix
- Push side: Flat plate (no handle). Affords only pushing.
- Pull side: Vertical handle. Affords pulling.
- Automatic doors: Eliminate the push/pull decision entirely.
Lesson
When users consistently do the wrong thing, the design is wrong, not the users. The cheapest fix (a sign) is also the weakest. The best fix changes the physical design so the correct action is the only possible action.
Case Study 2: The Thermostat Mental Model
Product
Home thermostats (traditional and digital).
Design Problem
Users set the thermostat to an extreme temperature (90 degrees) believing it will heat the room faster. It does not. The heating system operates at a constant rate regardless of the target temperature. Setting it to 90 just means it runs longer, overshoots the comfortable temperature, and wastes energy.
Principle Violated
Conceptual Models
Analysis
Users apply a "valve" mental model: more = faster, like a faucet where turning the handle further produces more water flow. The thermostat actually works as a "goal-seeking" system: it turns heating on/off to reach and maintain a target temperature. The rate of heating is fixed.
The system image fails because traditional thermostats show only the target number. They do not show the current temperature, the heating state (on/off), or the rate of change. Without this information, users cannot build the correct conceptual model.
Fix
- Show current temperature AND target temperature side by side.
- Show "Heating to 72..." with an animated indicator.
- Show estimated time to reach target: "~15 minutes."
- Nest smart thermostats (like Nest) show all of this and learned the pattern early.
Lesson
When users consistently misuse a product, the product's system image is failing to communicate its conceptual model. The fix is to make the internal mechanism visible, not to educate users through manuals.
Case Study 3: Stovetop Burner Mapping
Product
Gas and electric stoves with four burners in a 2x2 grid and four control knobs in a 1x4 row.
Design Problem
Users turn the wrong knob for the burner they want to use. They must look at labels (often small and hard to read) to determine which knob controls which burner because the linear arrangement of knobs does not correspond to the grid arrangement of burners.
Principle Violated
Mappings
Analysis
The four burners are arranged in a square:
[FL] [FR]
[BL] [BR]
The four knobs are arranged in a line:
[K1] [K2] [K3] [K4]
There is no natural spatial mapping between the linear knobs and the grid of burners. The relationship is arbitrary and must be memorized or read from a label. Even after years of use, many people occasionally turn the wrong knob.
Fix
Arrange the knobs in a 2x2 grid matching the burner layout:
[FL] [FR] [KFL] [KFR]
[BL] [BR] [KBL] [KBR]
Or place each knob directly adjacent to its burner. Some modern stove designs use a staggered or offset knob layout that better matches the burner positions.
Lesson
Natural spatial mapping eliminates the need for labels, memorization, and guesswork. When the control layout matches the output layout, the relationship is self-evident.
Case Study 4: Airplane Cockpit Mode Errors
Product
Commercial aircraft autopilot and flight management systems.
Design Problem
Pilots perform the correct action for the wrong mode, or fail to notice a mode change, leading to altitude deviations, speed errors, or in extreme cases, accidents. The 1994 Nagoya A300 crash and the 2009 Air France 447 disaster both involved mode confusion.
Principles Violated
Feedback, Signifiers, Conceptual Models
Analysis
Modern autopilot systems have dozens of modes: altitude hold, vertical speed, flight level change, approach, go-around, autothrottle, and many more. Mode transitions can be triggered by the pilot, by the automation, or by the system responding to conditions (e.g., reaching a target altitude).
The problems are compounded:
- Mode annunciations are small: A tiny text label on the Primary Flight Display changes from "ALT HOLD" to "V/S" but may not attract attention.
- Automation acts silently: The system transitions modes without alerting the pilot. A critical mode change (like autothrottle disconnection) may be signaled by a brief tone that is missed in a noisy cockpit.
- Model complexity: Pilots must maintain a mental model of multiple interacting automation modes. The combinations are too numerous to track reliably.
Fix
- Prominent mode annunciations: Large, color-coded mode displays that change distinctly when the mode changes.
- Mode change alerts: Auditory and visual alerts when the automation changes mode, especially uncommanded changes.
- Simplified mode structure: Reduce the number of modes. Combine similar modes. Make transitions predictable.
- Consistent behavior: Same pilot action should produce the same result regardless of mode.
Lesson
When systems have modes, those modes must be visible, and mode changes must be unmissable. The more modes a system has, the more likely users are to lose track of the current state. Simplify modes wherever possible, and make remaining modes impossible to overlook.
Case Study 5: Hospital Medication Errors
Product
Electronic health record (EHR) systems and medication ordering interfaces.
Design Problem
Physicians and nurses select the wrong medication, wrong dose, or wrong route of administration when ordering or administering medications. The Institute of Medicine estimates that medication errors harm at least 1.5 million Americans annually.
Principles Violated
Constraints, Signifiers, Feedback, Mappings
Analysis
Multiple design failures contribute:
| Failure | Principle | Description |
|---|---|---|
| Drug name confusion | Signifiers | "Hydroxyzine" vs. "Hydralazine" look similar in dropdown lists |
| Dose entry as free text | Constraints | No range validation; a tenfold error (1.0mg vs 10mg) is not caught |
| Units not locked | Constraints | User can type "mg" when "mcg" is required |
| Alert fatigue | Feedback | So many alerts fire that clinicians override 90%+ of them, including real dangers |
| Display density | Mappings | Medication lists show 50+ items in a flat list with no grouping or hierarchy |
Fix
- Tall Man Lettering: hydrOXYzine vs. hydrALAzine (capitalize distinguishing letters).
- Dose range validation: Flag doses outside the normal range for the selected drug: "10mg is 10x the typical adult dose. Confirm or adjust."
- Pre-set dose options: Dropdown of standard doses for each drug instead of free-text entry.
- Tiered alerts: Reserve modal alerts for true contraindications. Use inline warnings for less critical issues. Reduce alert volume by 80% so the remaining alerts are respected.
- Visual grouping: Group medications by category (cardiac, analgesic, antibiotic) with visual separation.
Lesson
In high-stakes environments, constraints are the most important design tool. Preventing errors is always better than detecting them. Alert fatigue is a failure of the feedback system: when everything is flagged as important, nothing is.
Case Study 6: ATM Interface Evolution
Product: Automated teller machines (1980s to present). Principles Violated (early ATMs): Signifiers, Feedback, Conceptual Models, Mappings.
Early ATMs had unlabeled buttons beside cryptic text screens. The mapping between button position and screen menu item was arbitrary and fragile. Users made frequent errors and needed staff assistance.
| Era | Interface | Mapping | Feedback | Errors |
|---|---|---|---|---|
| 1980s | Unlabeled buttons + text menu | Arbitrary | Minimal; cryptic messages | High |
| 1990s | Labeled buttons + graphical menu | Improved (labels adjacent to items) | Better; clearer messages | Moderate |
| 2010s | Touchscreen | Direct (tap the option itself) | Good; progress bars, animations | Low |
Lesson
Direct manipulation (touching the thing itself) produces the best mapping possible. ATM evolution is a 40-year demonstration of mapping improvement through progressively more natural interaction.
Case Study 7: Smartphone Unlock Evolution
Product: Smartphone lock screens (2007 to present). Principles Applied: Affordances, Constraints, Feedback.
Securing a device accessed 80-150 times daily requires balancing security against usability. Each generation reduced friction while maintaining or improving security.
| Method | Era | Signifier | Feedback | Error Recovery |
|---|---|---|---|---|
| Slide to unlock | 2007 | Arrow and track | Slider follows finger | Springs back on failure |
| PIN | 2007+ | Familiar keypad | Dots fill, shake on error | Escalating delays |
| Pattern | 2008+ | Grid of dots | Line follows finger | Shake, timeout |
| Fingerprint | 2013+ | Sensor position | Haptic pulse | Falls back to PIN |
| Face unlock | 2017+ | None (ambient) | Padlock icon animation | Falls back to PIN |
Lesson
The best interface is no interface. Each evolution reduced the Gulf of Execution while keeping evaluation clear. As technology improves, constraints can be maintained while affordances become invisible.
Case Study 8: Smart Home Light Controls
Product: Smart home lighting (Philips Hue, LIFX, smart switches, voice assistants). Principles Violated: Conceptual Models, Mappings, Affordances.
A simple task (turn on the kitchen light) now involves choosing between a wall switch, app, voice command, hub, or automation. Users often cannot turn on their own lights because the conceptual model is fragmented.
Analysis
| Problem | Principle | Description |
|---|---|---|
| Wall switch kills smart bulb power | Conceptual model conflict | User's model: switch controls light. Reality: switch cuts power to the smart bulb, making it unresponsive to the app. |
| Multiple control points | Mapping confusion | The light can be controlled from 4+ places. Which one is "current"? |
| State ambiguity | Feedback failure | Is the light off because the switch is off, the app is off, the schedule turned it off, or the bulb has no power? |
| Voice command variability | Specification difficulty | "Turn on the kitchen light" vs "Turn on kitchen" vs "Lights on in the kitchen." Which works? |
| Automation surprises | Unexpected behavior | Lights turn on at 6 AM because of an automation the user forgot they set up. |
Fix
- Single source of truth: All control methods feed into one system reflecting true state.
- Switches send commands, not power: Smart switches send commands to the hub rather than cutting electrical power to the bulb.
- State always visible: App and wall display always show current state.
- Fallback to simple: If the smart system fails, the physical switch still works.
Lesson
Adding "smart" capabilities to simple products undermines the original simplicity. Every new control point must integrate with the existing model, not create a parallel one.
Cross-Cutting Patterns: What Makes Designs Intuitive vs. Confusing
Across all eight case studies, the same patterns emerge repeatedly.
What Makes Designs Intuitive
| Pattern | How It Works | Seen In |
|---|---|---|
| Direct manipulation | Act on the thing itself, not through an intermediary | Touchscreen ATM, smartphone unlock, WYSIWYG editors |
| Spatial correspondence | Control layout matches output layout | Stove fix, car seat adjusters, elevator buttons |
| Visible system state | Users always know what mode, state, or phase the system is in | Thermostat fix, airplane mode annunciation, smart home state |
| Physical constraint | Wrong action is impossible | Norman Door fix, USB-C, medication dose validation |
| Immediate feedback | Every action produces a perceivable result | Smartphone unlock haptics, ATM animations, inline validation |
| Familiar metaphors | New products map to known mental models | Trash can, folders, shopping cart |
What Makes Designs Confusing
| Pattern | How It Fails | Seen In |
|---|---|---|
| Hidden modes | Users perform correct action in wrong mode | Airplane autopilot, caps lock, smart home automations |
| Arbitrary mapping | Controls have no logical connection to outcomes | Stove knobs, early ATM buttons, light switch panels |
| Silent failures | Errors produce no feedback | Form submissions, background sync, medication order processing |
| Conflicting affordances | Hardware suggests one action, system requires another | Norman Door, smart home wall switch |
| Broken metaphors | Product looks like something familiar but behaves differently | Thermostat as valve, cloud as physical location |
| Alert fatigue | Too many warnings cause all warnings to be ignored | Hospital medication alerts, confirmation dialogs |
The Universal Fix
Every confusing design can be improved by asking six questions:
- Can the user see what actions are possible? (Affordances, Signifiers)
- Can the user tell which control affects which outcome? (Mappings)
- Can the user avoid making errors? (Constraints)
- Can the user see what happened? (Feedback)
- Does the user understand how the system works? (Conceptual Model)
- Can the user recover from mistakes? (Error Tolerance)
If the answer to any question is "no," the corresponding principle identifies both the problem and the category of solution.
| 1 | # Case Studies: Design Analysis Using Norman's Principles |
| 2 | |
| 3 | This collection of case studies applies Don Norman's design principles to real products, both physical and digital. Each case follows the same structure: the product, the design problem, the principle violated, a detailed analysis, the fix, and the broader lesson. These cases demonstrate that the same small set of principles explains why products are intuitive or infuriating. |
| 4 | |
| 5 | ## Table of Contents |
| 6 | [Case Study 1: The Norman Door] |
| 7 | [Case Study 2: The Thermostat Mental Model] |
| 8 | [Case Study 3: Stovetop Burner Mapping] |
| 9 | [Case Study 4: Airplane Cockpit Mode Errors] |
| 10 | [Case Study 5: Hospital Medication Errors] |
| 11 | [Case Study 6: ATM Interface Evolution] |
| 12 | [Case Study 7: Smartphone Unlock Evolution] |
| 13 | [Case Study 8: Smart Home Light Controls] |
| 14 | [Cross-Cutting Patterns: What Makes Designs Intuitive vs. Confusing] |
| 15 | |
| 16 | |
| 17 | |
| 18 | ## Case Study 1: The Norman Door |
| 19 | |
| 20 | ### Product |
| 21 | |
| 22 | Commercial building doors with flat push-plates on both sides, or handles on a door that requires pushing. |
| 23 | |
| 24 | ### Design Problem |
| 25 | |
| 26 | People push when they should pull, and pull when they should push. This happens millions of times daily in buildings around the world. The problem is so pervasive that doors requiring a "Push" or "Pull" sign have become known as "Norman Doors." |
| 27 | |
| 28 | ### Principles Violated |
| 29 | |
| 30 | **Affordances**, **Signifiers**, **Constraints** |
| 31 | |
| 32 | ### Analysis |
| 33 | |
| 34 | A flat plate affords pushing. A handle affords pulling (and pushing, but the grip shape invites pulling). When a door has a handle on the side that requires pushing, the affordance (graspable handle) contradicts the required action (push). The user perceives a pull affordance, attempts to pull, fails, and then pushes. The "Push" sign is a signifier band-aid for a broken affordance. |
| 35 | |
| 36 | The deeper failure is a missing constraint. If the door only opens one way, the hardware should make the wrong action impossible. A flat plate on the push side and a handle on the pull side creates a physical constraint: you cannot pull a flat plate. |
| 37 | |
| 38 | ### Fix |
| 39 | |
| 40 | **Push side**: Flat plate (no handle). Affords only pushing. |
| 41 | **Pull side**: Vertical handle. Affords pulling. |
| 42 | **Automatic doors**: Eliminate the push/pull decision entirely. |
| 43 | |
| 44 | ### Lesson |
| 45 | |
| 46 | When users consistently do the wrong thing, the design is wrong, not the users. The cheapest fix (a sign) is also the weakest. The best fix changes the physical design so the correct action is the only possible action. |
| 47 | |
| 48 | |
| 49 | |
| 50 | ## Case Study 2: The Thermostat Mental Model |
| 51 | |
| 52 | ### Product |
| 53 | |
| 54 | Home thermostats (traditional and digital). |
| 55 | |
| 56 | ### Design Problem |
| 57 | |
| 58 | Users set the thermostat to an extreme temperature (90 degrees) believing it will heat the room faster. It does not. The heating system operates at a constant rate regardless of the target temperature. Setting it to 90 just means it runs longer, overshoots the comfortable temperature, and wastes energy. |
| 59 | |
| 60 | ### Principle Violated |
| 61 | |
| 62 | **Conceptual Models** |
| 63 | |
| 64 | ### Analysis |
| 65 | |
| 66 | Users apply a "valve" mental model: more = faster, like a faucet where turning the handle further produces more water flow. The thermostat actually works as a "goal-seeking" system: it turns heating on/off to reach and maintain a target temperature. The rate of heating is fixed. |
| 67 | |
| 68 | The system image fails because traditional thermostats show only the target number. They do not show the current temperature, the heating state (on/off), or the rate of change. Without this information, users cannot build the correct conceptual model. |
| 69 | |
| 70 | ### Fix |
| 71 | |
| 72 | Show current temperature AND target temperature side by side. |
| 73 | Show "Heating to 72..." with an animated indicator. |
| 74 | Show estimated time to reach target: "~15 minutes." |
| 75 | Nest smart thermostats (like Nest) show all of this and learned the pattern early. |
| 76 | |
| 77 | ### Lesson |
| 78 | |
| 79 | When users consistently misuse a product, the product's system image is failing to communicate its conceptual model. The fix is to make the internal mechanism visible, not to educate users through manuals. |
| 80 | |
| 81 | |
| 82 | |
| 83 | ## Case Study 3: Stovetop Burner Mapping |
| 84 | |
| 85 | ### Product |
| 86 | |
| 87 | Gas and electric stoves with four burners in a 2x2 grid and four control knobs in a 1x4 row. |
| 88 | |
| 89 | ### Design Problem |
| 90 | |
| 91 | Users turn the wrong knob for the burner they want to use. They must look at labels (often small and hard to read) to determine which knob controls which burner because the linear arrangement of knobs does not correspond to the grid arrangement of burners. |
| 92 | |
| 93 | ### Principle Violated |
| 94 | |
| 95 | **Mappings** |
| 96 | |
| 97 | ### Analysis |
| 98 | |
| 99 | The four burners are arranged in a square: |
| 100 | |
| 101 | |
| 102 | [FL] [FR] |
| 103 | [BL] [BR] |
| 104 | |
| 105 | |
| 106 | The four knobs are arranged in a line: |
| 107 | |
| 108 | |
| 109 | [K1] [K2] [K3] [K4] |
| 110 | |
| 111 | |
| 112 | There is no natural spatial mapping between the linear knobs and the grid of burners. The relationship is arbitrary and must be memorized or read from a label. Even after years of use, many people occasionally turn the wrong knob. |
| 113 | |
| 114 | ### Fix |
| 115 | |
| 116 | Arrange the knobs in a 2x2 grid matching the burner layout: |
| 117 | |
| 118 | |
| 119 | [FL] [FR] [KFL] [KFR] |
| 120 | [BL] [BR] [KBL] [KBR] |
| 121 | |
| 122 | |
| 123 | Or place each knob directly adjacent to its burner. Some modern stove designs use a staggered or offset knob layout that better matches the burner positions. |
| 124 | |
| 125 | ### Lesson |
| 126 | |
| 127 | Natural spatial mapping eliminates the need for labels, memorization, and guesswork. When the control layout matches the output layout, the relationship is self-evident. |
| 128 | |
| 129 | |
| 130 | |
| 131 | ## Case Study 4: Airplane Cockpit Mode Errors |
| 132 | |
| 133 | ### Product |
| 134 | |
| 135 | Commercial aircraft autopilot and flight management systems. |
| 136 | |
| 137 | ### Design Problem |
| 138 | |
| 139 | Pilots perform the correct action for the wrong mode, or fail to notice a mode change, leading to altitude deviations, speed errors, or in extreme cases, accidents. The 1994 Nagoya A300 crash and the 2009 Air France 447 disaster both involved mode confusion. |
| 140 | |
| 141 | ### Principles Violated |
| 142 | |
| 143 | **Feedback**, **Signifiers**, **Conceptual Models** |
| 144 | |
| 145 | ### Analysis |
| 146 | |
| 147 | Modern autopilot systems have dozens of modes: altitude hold, vertical speed, flight level change, approach, go-around, autothrottle, and many more. Mode transitions can be triggered by the pilot, by the automation, or by the system responding to conditions (e.g., reaching a target altitude). |
| 148 | |
| 149 | The problems are compounded: |
| 150 | **Mode annunciations are small**: A tiny text label on the Primary Flight Display changes from "ALT HOLD" to "V/S" but may not attract attention. |
| 151 | **Automation acts silently**: The system transitions modes without alerting the pilot. A critical mode change (like autothrottle disconnection) may be signaled by a brief tone that is missed in a noisy cockpit. |
| 152 | **Model complexity**: Pilots must maintain a mental model of multiple interacting automation modes. The combinations are too numerous to track reliably. |
| 153 | |
| 154 | ### Fix |
| 155 | |
| 156 | **Prominent mode annunciations**: Large, color-coded mode displays that change distinctly when the mode changes. |
| 157 | **Mode change alerts**: Auditory and visual alerts when the automation changes mode, especially uncommanded changes. |
| 158 | **Simplified mode structure**: Reduce the number of modes. Combine similar modes. Make transitions predictable. |
| 159 | **Consistent behavior**: Same pilot action should produce the same result regardless of mode. |
| 160 | |
| 161 | ### Lesson |
| 162 | |
| 163 | When systems have modes, those modes must be visible, and mode changes must be unmissable. The more modes a system has, the more likely users are to lose track of the current state. Simplify modes wherever possible, and make remaining modes impossible to overlook. |
| 164 | |
| 165 | |
| 166 | |
| 167 | ## Case Study 5: Hospital Medication Errors |
| 168 | |
| 169 | ### Product |
| 170 | |
| 171 | Electronic health record (EHR) systems and medication ordering interfaces. |
| 172 | |
| 173 | ### Design Problem |
| 174 | |
| 175 | Physicians and nurses select the wrong medication, wrong dose, or wrong route of administration when ordering or administering medications. The Institute of Medicine estimates that medication errors harm at least 1.5 million Americans annually. |
| 176 | |
| 177 | ### Principles Violated |
| 178 | |
| 179 | **Constraints**, **Signifiers**, **Feedback**, **Mappings** |
| 180 | |
| 181 | ### Analysis |
| 182 | |
| 183 | Multiple design failures contribute: |
| 184 | |
| 185 | | Failure | Principle | Description | |
| 186 | |---------|-----------|-------------| |
| 187 | | Drug name confusion | Signifiers | "Hydroxyzine" vs. "Hydralazine" look similar in dropdown lists | |
| 188 | | Dose entry as free text | Constraints | No range validation; a tenfold error (1.0mg vs 10mg) is not caught | |
| 189 | | Units not locked | Constraints | User can type "mg" when "mcg" is required | |
| 190 | | Alert fatigue | Feedback | So many alerts fire that clinicians override 90%+ of them, including real dangers | |
| 191 | | Display density | Mappings | Medication lists show 50+ items in a flat list with no grouping or hierarchy | |
| 192 | |
| 193 | ### Fix |
| 194 | |
| 195 | **Tall Man Lettering**: hydrOXYzine vs. hydrALAzine (capitalize distinguishing letters). |
| 196 | **Dose range validation**: Flag doses outside the normal range for the selected drug: "10mg is 10x the typical adult dose. Confirm or adjust." |
| 197 | **Pre-set dose options**: Dropdown of standard doses for each drug instead of free-text entry. |
| 198 | **Tiered alerts**: Reserve modal alerts for true contraindications. Use inline warnings for less critical issues. Reduce alert volume by 80% so the remaining alerts are respected. |
| 199 | **Visual grouping**: Group medications by category (cardiac, analgesic, antibiotic) with visual separation. |
| 200 | |
| 201 | ### Lesson |
| 202 | |
| 203 | In high-stakes environments, constraints are the most important design tool. Preventing errors is always better than detecting them. Alert fatigue is a failure of the feedback system: when everything is flagged as important, nothing is. |
| 204 | |
| 205 | |
| 206 | |
| 207 | ## Case Study 6: ATM Interface Evolution |
| 208 | |
| 209 | **Product**: Automated teller machines (1980s to present). **Principles Violated** (early ATMs): Signifiers, Feedback, Conceptual Models, Mappings. |
| 210 | |
| 211 | Early ATMs had unlabeled buttons beside cryptic text screens. The mapping between button position and screen menu item was arbitrary and fragile. Users made frequent errors and needed staff assistance. |
| 212 | |
| 213 | | Era | Interface | Mapping | Feedback | Errors | |
| 214 | |-----|-----------|---------|----------|--------| |
| 215 | | 1980s | Unlabeled buttons + text menu | Arbitrary | Minimal; cryptic messages | High | |
| 216 | | 1990s | Labeled buttons + graphical menu | Improved (labels adjacent to items) | Better; clearer messages | Moderate | |
| 217 | | 2010s | Touchscreen | Direct (tap the option itself) | Good; progress bars, animations | Low | |
| 218 | |
| 219 | ### Lesson |
| 220 | |
| 221 | Direct manipulation (touching the thing itself) produces the best mapping possible. ATM evolution is a 40-year demonstration of mapping improvement through progressively more natural interaction. |
| 222 | |
| 223 | |
| 224 | |
| 225 | ## Case Study 7: Smartphone Unlock Evolution |
| 226 | |
| 227 | **Product**: Smartphone lock screens (2007 to present). **Principles Applied**: Affordances, Constraints, Feedback. |
| 228 | |
| 229 | Securing a device accessed 80-150 times daily requires balancing security against usability. Each generation reduced friction while maintaining or improving security. |
| 230 | |
| 231 | | Method | Era | Signifier | Feedback | Error Recovery | |
| 232 | |--------|-----|-----------|----------|---------------| |
| 233 | | **Slide to unlock** | 2007 | Arrow and track | Slider follows finger | Springs back on failure | |
| 234 | | **PIN** | 2007+ | Familiar keypad | Dots fill, shake on error | Escalating delays | |
| 235 | | **Pattern** | 2008+ | Grid of dots | Line follows finger | Shake, timeout | |
| 236 | | **Fingerprint** | 2013+ | Sensor position | Haptic pulse | Falls back to PIN | |
| 237 | | **Face unlock** | 2017+ | None (ambient) | Padlock icon animation | Falls back to PIN | |
| 238 | |
| 239 | ### Lesson |
| 240 | |
| 241 | The best interface is no interface. Each evolution reduced the Gulf of Execution while keeping evaluation clear. As technology improves, constraints can be maintained while affordances become invisible. |
| 242 | |
| 243 | |
| 244 | |
| 245 | ## Case Study 8: Smart Home Light Controls |
| 246 | |
| 247 | **Product**: Smart home lighting (Philips Hue, LIFX, smart switches, voice assistants). **Principles Violated**: Conceptual Models, Mappings, Affordances. |
| 248 | |
| 249 | A simple task (turn on the kitchen light) now involves choosing between a wall switch, app, voice command, hub, or automation. Users often cannot turn on their own lights because the conceptual model is fragmented. |
| 250 | |
| 251 | ### Analysis |
| 252 | |
| 253 | | Problem | Principle | Description | |
| 254 | |---------|-----------|-------------| |
| 255 | | Wall switch kills smart bulb power | Conceptual model conflict | User's model: switch controls light. Reality: switch cuts power to the smart bulb, making it unresponsive to the app. | |
| 256 | | Multiple control points | Mapping confusion | The light can be controlled from 4+ places. Which one is "current"? | |
| 257 | | State ambiguity | Feedback failure | Is the light off because the switch is off, the app is off, the schedule turned it off, or the bulb has no power? | |
| 258 | | Voice command variability | Specification difficulty | "Turn on the kitchen light" vs "Turn on kitchen" vs "Lights on in the kitchen." Which works? | |
| 259 | | Automation surprises | Unexpected behavior | Lights turn on at 6 AM because of an automation the user forgot they set up. | |
| 260 | |
| 261 | ### Fix |
| 262 | |
| 263 | **Single source of truth**: All control methods feed into one system reflecting true state. |
| 264 | **Switches send commands, not power**: Smart switches send commands to the hub rather than cutting electrical power to the bulb. |
| 265 | **State always visible**: App and wall display always show current state. |
| 266 | **Fallback to simple**: If the smart system fails, the physical switch still works. |
| 267 | |
| 268 | ### Lesson |
| 269 | |
| 270 | Adding "smart" capabilities to simple products undermines the original simplicity. Every new control point must integrate with the existing model, not create a parallel one. |
| 271 | |
| 272 | |
| 273 | |
| 274 | ## Cross-Cutting Patterns: What Makes Designs Intuitive vs. Confusing |
| 275 | |
| 276 | Across all eight case studies, the same patterns emerge repeatedly. |
| 277 | |
| 278 | ### What Makes Designs Intuitive |
| 279 | |
| 280 | | Pattern | How It Works | Seen In | |
| 281 | |---------|-------------|---------| |
| 282 | | **Direct manipulation** | Act on the thing itself, not through an intermediary | Touchscreen ATM, smartphone unlock, WYSIWYG editors | |
| 283 | | **Spatial correspondence** | Control layout matches output layout | Stove fix, car seat adjusters, elevator buttons | |
| 284 | | **Visible system state** | Users always know what mode, state, or phase the system is in | Thermostat fix, airplane mode annunciation, smart home state | |
| 285 | | **Physical constraint** | Wrong action is impossible | Norman Door fix, USB-C, medication dose validation | |
| 286 | | **Immediate feedback** | Every action produces a perceivable result | Smartphone unlock haptics, ATM animations, inline validation | |
| 287 | | **Familiar metaphors** | New products map to known mental models | Trash can, folders, shopping cart | |
| 288 | |
| 289 | ### What Makes Designs Confusing |
| 290 | |
| 291 | | Pattern | How It Fails | Seen In | |
| 292 | |---------|-------------|---------| |
| 293 | | **Hidden modes** | Users perform correct action in wrong mode | Airplane autopilot, caps lock, smart home automations | |
| 294 | | **Arbitrary mapping** | Controls have no logical connection to outcomes | Stove knobs, early ATM buttons, light switch panels | |
| 295 | | **Silent failures** | Errors produce no feedback | Form submissions, background sync, medication order processing | |
| 296 | | **Conflicting affordances** | Hardware suggests one action, system requires another | Norman Door, smart home wall switch | |
| 297 | | **Broken metaphors** | Product looks like something familiar but behaves differently | Thermostat as valve, cloud as physical location | |
| 298 | | **Alert fatigue** | Too many warnings cause all warnings to be ignored | Hospital medication alerts, confirmation dialogs | |
| 299 | |
| 300 | ### The Universal Fix |
| 301 | |
| 302 | Every confusing design can be improved by asking six questions: |
| 303 | |
| 304 | **Can the user see what actions are possible?** (Affordances, Signifiers) |
| 305 | **Can the user tell which control affects which outcome?** (Mappings) |
| 306 | **Can the user avoid making errors?** (Constraints) |
| 307 | **Can the user see what happened?** (Feedback) |
| 308 | **Does the user understand how the system works?** (Conceptual Model) |
| 309 | **Can the user recover from mistakes?** (Error Tolerance) |
| 310 | |
| 311 | If the answer to any question is "no," the corresponding principle identifies both the problem and the category of solution. |
| 312 |
Discussion
Browse more free Claude skills.