# Affordances: Designing for Action

An affordance is a relationship between an object and a person that determines how the object could possibly be used. A chair affords sitting. A handle affords pulling. A button affords pressing. Affordances exist in the physical properties of the object relative to the capabilities of the user, whether or not the user perceives them. The central design challenge is making affordances visible and unmistakable.

## Affordance Types

| Type | Definition | Key Characteristic | Example |
|------|------------|-------------------|---------|
| **Real affordance** | An action the object genuinely supports | Exists in the physics/code | A physical button can be pressed; a text input accepts keystrokes |
| **Perceived affordance** | An action the user believes is possible | Exists in the user's mind | A raised, shadowed rectangle looks pressable even if it is decorative |
| **Hidden affordance** | An action that exists but is not visible | Discoverable only by accident or instruction | Right-click context menus, multi-finger trackpad gestures |
| **False affordance** | An appearance of action that does not exist | Misleads the user | Underlined blue text that is not a link; a card with a shadow that is not clickable |
| **Anti-affordance** | A deliberate prevention of action | Communicates "you cannot do this" | A grayed-out disabled button; a railing that prevents falling |

### The Critical Distinction

Real affordances are properties of the system. Perceived affordances are properties of the user's interpretation. Good design aligns these two: every real affordance should be perceived, and no false affordance should exist.

---

## Digital Affordance Patterns

### Buttons

| Property | Affords | Signal |
|----------|---------|--------|
| Raised appearance / shadow | Pressing / clicking | Drop shadow, gradient, border |
| Color contrast with background | Attention and interaction | Primary color, high contrast |
| Hover state change | "I respond to interaction" | Background darkens, cursor changes |
| Active/pressed state | "Your click registered" | Slight depression, color shift |
| Disabled state (grayed) | "Not available right now" | Reduced opacity, no cursor change |

### Links

| Property | Affords | Signal |
|----------|---------|--------|
| Color differentiation | Navigation | Blue or brand-accent color |
| Underline | "I am clickable text" | Text decoration underline |
| Cursor change to pointer | "Click me" | CSS cursor: pointer |
| Visited state color | "You have been here" | Purple or muted color |

### Text Inputs

| Property | Affords | Signal |
|----------|---------|--------|
| Border / outline | "Type here" | Visible rectangular boundary |
| Placeholder text | "This is what goes here" | Light gray sample text |
| Focus ring | "You are editing this" | Blue outline on focus |
| Blinking cursor | "I am ready for input" | Text insertion cursor |
| Label above/beside | "This field is for X" | Descriptive text |

### Sliders

| Property | Affords | Signal |
|----------|---------|--------|
| Handle / thumb | Dragging | Circular or rectangular grab target |
| Track | Range of movement | Horizontal or vertical line |
| Fill color | Current value | Colored portion of the track |
| Min/max labels | Boundaries | Text or numbers at each end |

### Drag Targets

| Property | Affords | Signal |
|----------|---------|--------|
| Grip dots or lines | "Grab and move me" | Six-dot handle icon |
| Cursor change to grab | "Draggable" | CSS cursor: grab |
| Lift animation on drag start | "I am being moved" | Shadow increase, slight scale up |
| Drop zone highlight | "Drop it here" | Border change, background tint |

---

## Physical vs. Digital Affordances

| Dimension | Physical | Digital |
|-----------|----------|---------|
| **Perception** | Seen, felt, heard directly | Seen on screen; no physical texture |
| **Constraint** | Physics prevents wrong use | Only code prevents wrong use |
| **Discoverability** | Explore by touch and manipulation | Explore by clicking, hovering, scrolling |
| **Feedback** | Immediate tactile response | Must be programmed explicitly |
| **Cultural learning** | Handles, knobs, buttons are universal | UI conventions are learned (hamburger menu, swipe gestures) |
| **Cost of error** | May cause physical harm | Rarely dangerous, but data loss possible |

### Implications for Digital Design

Physical objects get affordances "for free" from their material properties. Digital interfaces must manufacture every affordance through visual design. This means:

1. Every interactive element needs deliberate visual treatment.
2. Non-interactive elements must be visually distinct from interactive ones.
3. New interaction patterns (gestures, voice) start with zero perceived affordance and need onboarding.

---

## The Flat Design Problem: When Affordances Disappear

Flat design (the removal of skeuomorphic visual cues like shadows, gradients, and borders) creates a systematic affordance crisis. When buttons look like labels and labels look like buttons, users cannot distinguish interactive elements from static content.

### What Flat Design Removes

| Removed Cue | Affordance Lost | User Impact |
|-------------|----------------|-------------|
| Drop shadows on buttons | "This is pressable" | Users do not recognize buttons |
| Borders on inputs | "Type here" | Users do not know where to click to type |
| Underlines on links | "This navigates" | Users cannot find links in body text |
| Gradients and bevels | "This is interactive" | All elements look equally flat and static |
| Visual depth / layering | "This is above/below that" | Users lose sense of hierarchy |

### Recovering Affordances in Flat Design

- Use **color contrast** to distinguish interactive elements from static ones.
- Add **hover and focus states** that reveal interactivity.
- Use **consistent spacing** to create clickable regions.
- Apply **subtle shadows or borders** (flat design does not mean zero visual depth).
- Always provide **cursor changes** on interactive elements.
- Pair **icons with labels** so meaning is not ambiguous.

---

## Touch vs. Mouse Affordances

| Factor | Mouse | Touch |
|--------|-------|-------|
| **Hover state** | Available and essential | Does not exist; cannot preview interactivity |
| **Precision** | High (single pixel) | Low (finger covers ~44px) |
| **Right-click** | Common interaction | Not available natively |
| **Drag and drop** | Natural with mouse | Conflicts with scroll gesture |
| **Cursor feedback** | Changes shape to signal affordance | No cursor exists |
| **Target size** | Minimum ~24px | Minimum 44x44px (Apple HIG) or 48x48dp (Material) |

### Touch-Specific Affordance Strategies

- Make all touch targets at least 44x44 points.
- Use visual weight (size, color, shadow) instead of hover states to signal interactivity.
- Provide haptic feedback (vibration) on interaction to replace the tactile click of a mouse button.
- Avoid relying on gestures as the only way to access critical actions; always provide a visible alternative.
- Show visual hints for swipeable content (partial next-card visible, dots indicator).

---

## Affordance Audit Checklist

Use this checklist to evaluate any screen or physical product.

### Interactive Elements

- [ ] Every button is visually distinguishable from non-interactive text and containers.
- [ ] Every link has at least two signals (color + underline, or color + cursor change).
- [ ] Every text input has a visible boundary (border, background contrast, or underline).
- [ ] Every slider has a visible handle and track.
- [ ] Every draggable element has a grip indicator.
- [ ] All touch targets are at least 44x44 points (mobile) or 24x24 pixels (desktop).

### Non-Interactive Elements

- [ ] Static text does not use the same color as links.
- [ ] Decorative images do not have clickable appearance (no pointer cursor, no hover effect).
- [ ] Section headers are not styled like buttons.
- [ ] Cards and containers that are not clickable do not have hover lift effects.

### Hidden Affordances

- [ ] Any gesture-based interaction also has a visible control alternative.
- [ ] Keyboard shortcuts are documented in the interface (tooltip, menu, help).
- [ ] Right-click menus duplicate functionality available through visible controls.
- [ ] Swipeable content shows a visual hint that more content exists.

### False Affordances

- [ ] No underlined text that is not a link.
- [ ] No colored text that looks like a link but is not.
- [ ] No card shadows or hover effects on non-interactive containers.
- [ ] No cursor: pointer on non-interactive elements.

---

## Before/After Examples of Affordance Improvements

### Example 1: Flat Submit Button

**Before**: A gray text label "Submit" with no border, no shadow, no background color. Users do not realize it is clickable.

**After**: A filled blue rectangle with white text "Submit", a subtle shadow, and a darkened hover state. Users immediately recognize it as a button.

**Principle applied**: Perceived affordance aligned with real affordance through visual treatment.

### Example 2: Hidden Navigation

**Before**: A three-line hamburger icon in the top corner. New users do not know it contains navigation. Engagement with secondary pages is low.

**After**: A visible horizontal navigation bar with text labels for the top 4 sections, plus a "More" dropdown for the rest. Engagement with secondary pages increases by 50% or more.

**Principle applied**: Hidden affordance converted to visible affordance.

### Example 3: Non-Obvious Text Input

**Before**: A thin bottom-border line with a small floating label. Users click randomly around the area unsure where the input field actually is.

**After**: A fully bordered rectangle with a label above, placeholder text inside, and a clear focus ring. Users click into the input immediately.

**Principle applied**: Real affordance made perceivable through boundary signifiers.

### Example 4: Gesture-Only Delete

**Before**: On mobile, the only way to delete a list item is to swipe left. Users who do not know the gesture cannot delete items.

**After**: Swipe-to-delete still works, but each item also has a visible trash icon on tap or a long-press menu. All users can access the delete function.

**Principle applied**: Hidden affordance supplemented with visible alternative.

---

## Common Affordance Failures by Platform

### Web

| Failure | Impact | Fix |
|---------|--------|-----|
| Ghost buttons (transparent with thin border) | Low click-through rates | Use filled buttons for primary actions |
| Cards without hover state that are clickable | Users miss clickable content | Add hover elevation or background change |
| Dropdown triggers that look like labels | Users do not know to click | Add a chevron icon and border |

### Mobile (iOS / Android)

| Failure | Impact | Fix |
|---------|--------|-----|
| Small touch targets | Frequent mis-taps, frustration | Minimum 44pt / 48dp targets |
| Swipe-only actions | Core functionality is invisible | Provide visible button alternative |
| Bottom sheet handle with no label | Users do not know to drag up | Add "Swipe up for details" text or an upward chevron |

### Desktop Applications

| Failure | Impact | Fix |
|---------|--------|-----|
| Toolbar with icon-only buttons | Users memorize slowly, new users lost | Add text labels below icons |
| Resizable panels without grab edges | Users cannot resize | Show a dotted grab edge or resize cursor on hover |
| Menu items with no keyboard shortcut listed | Power users cannot accelerate | Show shortcut text next to every menu item |

---

## Accessibility and Affordances

Affordances must work for all users, including those who use assistive technologies.

| User Group | Affordance Consideration |
|-----------|------------------------|
| **Screen reader users** | Every interactive element must have an accessible role (button, link, input) and a descriptive label. Visual affordances are invisible; semantic affordances must replace them. |
| **Keyboard-only users** | Every interactive element must be focusable and operable with Enter or Space. Focus rings are the keyboard equivalent of hover states: they are affordance signifiers. |
| **Low-vision users** | Interactive elements need sufficient color contrast (WCAG 4.5:1 for text, 3:1 for UI components). Size thresholds increase. |
| **Motor-impaired users** | Touch targets must be larger (WCAG recommends 44x44 CSS pixels). Drag-and-drop must have a click-based alternative. |
| **Cognitive disabilities** | Affordances must be explicit, not implied. Labels are better than icons alone. Consistent placement is essential. |

### Accessibility Affordance Checklist

- [ ] All interactive elements have correct ARIA roles or native HTML semantics.
- [ ] Focus order follows visual order.
- [ ] Focus rings are visible and high-contrast.
- [ ] Interactive elements are reachable and operable via keyboard.
- [ ] Color is not the only affordance signal (shape, border, or icon accompanies color).
- [ ] Touch targets meet minimum size requirements.
- [ ] Drag interactions have non-drag alternatives.

# 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
1. [Case Study 1: The Norman Door](#case-study-1-the-norman-door)
2. [Case Study 2: The Thermostat Mental Model](#case-study-2-the-thermostat-mental-model)
3. [Case Study 3: Stovetop Burner Mapping](#case-study-3-stovetop-burner-mapping)
4. [Case Study 4: Airplane Cockpit Mode Errors](#case-study-4-airplane-cockpit-mode-errors)
5. [Case Study 5: Hospital Medication Errors](#case-study-5-hospital-medication-errors)
6. [Case Study 6: ATM Interface Evolution](#case-study-6-atm-interface-evolution)
7. [Case Study 7: Smartphone Unlock Evolution](#case-study-7-smartphone-unlock-evolution)
8. [Case Study 8: Smart Home Light Controls](#case-study-8-smart-home-light-controls)
9. [Cross-Cutting Patterns: What Makes Designs Intuitive vs. Confusing](#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:
1. **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.
2. **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.
3. **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:

1. **Can the user see what actions are possible?** (Affordances, Signifiers)
2. **Can the user tell which control affects which outcome?** (Mappings)
3. **Can the user avoid making errors?** (Constraints)
4. **Can the user see what happened?** (Feedback)
5. **Does the user understand how the system works?** (Conceptual Model)
6. **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.

# Conceptual Models: How Users Think Products Work

A conceptual model is a mental representation of how something works. Users form conceptual models of every product they interact with, whether or not the designer intended a particular model. When the user's model matches reality, the product feels intuitive. When it does not, the product feels broken. The designer's most important job is shaping the system image so that users build correct mental models.

## The Three Models

### Design Model

The designer's understanding of how the product works. This model is complete and accurate because the designer built the system.

### User's Model (Mental Model)

The user's understanding of how the product works. This model is often incomplete, simplified, and sometimes wrong. Users build their model from the system image, not from documentation or training.

### System Image

Everything the product communicates to the user: its appearance, behavior, feedback, documentation, and responses. The system image is the only bridge between the design model and the user's model.

### The Relationship

```
Designer ──creates──> Design Model
                          │
                     shapes the
                          │
                          v
                    System Image
                          │
                    perceived by
                          │
                          v
User ──builds──> User's Mental Model
```

**The gap problem**: Designers communicate with users only through the system image. If the system image is unclear, incomplete, or misleading, the user's model will diverge from the design model, and the product will feel confusing.

### Why Models Matter

| Alignment | User Experience | Example |
|-----------|----------------|---------|
| Models match | User predicts outcomes correctly, feels confident, recovers easily from mistakes | User understands that "Trash" holds deleted files temporarily and can restore them |
| Models partially match | User succeeds at basic tasks but fails at advanced ones | User can send email but does not understand threading or labels |
| Models mismatch | User is confused, frustrated, blames self, calls support | User cranks thermostat to 90 expecting faster heating |

---

## Building Correct Conceptual Models

### Principle 1: Make the System Visible

Users cannot model what they cannot see. Make internal states, processes, and structures visible.

| Strategy | Implementation | Example |
|----------|---------------|---------|
| Show system state | Persistent indicators | "Connected", "Syncing", "Offline" badge |
| Show structure | Visual hierarchy, navigation | Folder tree showing file organization |
| Show process | Step indicators, progress bars | "Step 2 of 4: Payment" |
| Show relationships | Visual grouping, connecting lines | Org chart, dependency diagram |
| Show history | Activity log, version history | "Last edited by Alice, 2 hours ago" |

### Principle 2: Provide a Good Conceptual Framework

Give users a simple, accurate model they can reason with.

| Strategy | Implementation | Example |
|----------|---------------|---------|
| Use familiar metaphors | Map new concepts to known ones | Desktop, folders, trash can, shopping cart |
| Offer a simplified model first | Progressive complexity | Basic view with "Show advanced options" |
| Explain behavior, not mechanism | User-facing language | "Your file is stored safely in the cloud" not "Uploaded to S3 bucket us-east-1" |
| Be consistent | Same action always produces same result | Click always selects, double-click always opens |

### Principle 3: Provide Feedback That Reinforces the Model

Every interaction should confirm or refine the user's understanding.

| Strategy | Implementation | Example |
|----------|---------------|---------|
| Show cause and effect | Animation connecting action to result | Dragged file animates into folder |
| Confirm expectations | Success messages that describe what happened | "Your message was sent to 3 recipients" |
| Correct misunderstandings | Helpful error messages | "This action will delete the original, not create a copy" |
| Reveal hidden states | Make the invisible visible | Show "Background sync in progress" instead of syncing silently |

---

## Metaphor-Based Conceptual Models

Metaphors are the most powerful tool for building conceptual models. They let users apply existing knowledge to new systems.

### Classic Software Metaphors

| Metaphor | Source Domain | What It Maps | What It Teaches |
|----------|-------------|-------------|----------------|
| **Desktop** | Office desk | Screen is a workspace | Organize items spatially, stack windows |
| **Folders** | Filing cabinet | Directory structure | Hierarchical organization, nesting |
| **Trash / Recycle Bin** | Physical waste bin | Deletion holding area | Deletion is two-phase: discard, then empty |
| **Shopping cart** | Physical shopping cart | Purchase collection | Gather items, then checkout all at once |
| **Inbox** | Physical mailbox | Message arrival point | New items arrive here, process and move them |
| **Clipboard** | Physical clipboard | Temporary storage | Copy puts it on the clipboard, paste retrieves it |
| **Bookmark** | Physical bookmark | Saved location | Mark a place to return to later |
| **Dashboard** | Car dashboard | Overview of key metrics | At-a-glance status of important indicators |

### Why Metaphors Work

1. **Transfer of knowledge**: Users already know how a physical shopping cart works. They apply that knowledge to the digital cart without instruction.
2. **Predictability**: If trash works like physical trash, users expect they can retrieve items before the bin is emptied.
3. **Vocabulary**: Metaphors provide a shared language. "Drag the file to the trash" is immediately understood.
4. **Constraints**: Metaphors imply constraints. A folder contains things. A trash bin is for discarding.

---

## When Metaphors Break Down

Every metaphor eventually reaches its limits. The digital domain does not perfectly mirror the physical domain, and extended metaphors can mislead users.

| Metaphor | Where It Breaks | User Confusion |
|----------|----------------|---------------|
| **Desktop** | Unlimited windows, virtual desktops, no physical constraint | Users lose windows behind other windows |
| **Folders** | Files can exist in multiple locations (aliases, shortcuts, tags) | "I moved the file, why is it still in the other folder?" |
| **Trash** | Emptying trash is permanent; some systems auto-empty | "I emptied the trash, can I get it back?" |
| **Shopping cart** | Cart persists across sessions; items can sell out while in cart | "I had it in my cart yesterday, now it's gone" |
| **Save** | Auto-save means the floppy disk concept is obsolete | "Where's the save button?" (It auto-saves.) |
| **Cloud** | Implies floating, ephemeral; actually stored on physical servers | "Where exactly is my data?" |

### Handling Metaphor Limits

- **Acknowledge the limit explicitly**: "Unlike a physical folder, the same file can appear in multiple places."
- **Extend with new concepts**: Introduce "tags" as a complement to folders when hierarchical metaphor breaks down.
- **Provide escape hatches**: When the metaphor fails, provide a literal description. Show the actual file path alongside the metaphorical folder view.
- **Do not force the metaphor**: If the metaphor creates confusion, drop it and use direct interaction instead.

---

## Model Mismatch Diagnosis

When users struggle with a product, the cause is often a mismatch between their mental model and the system's actual behavior. Use this diagnostic process.

### Step 1: Identify the Symptom

| Symptom | Likely Mismatch |
|---------|----------------|
| User tries an action that does not exist | Their model includes capabilities the system lacks |
| User cannot find a feature that exists | Their model does not include the feature's location |
| User expects outcome A but gets outcome B | Their model predicts different behavior than the system delivers |
| User repeats an action unnecessarily | Their model does not include the system's automatic behavior (auto-save, sync) |
| User is afraid to act | Their model does not include recovery options (undo, trash) |

### Step 2: Identify the User's Model

Ask (or infer from behavior):
- "What did you expect to happen?"
- "Where did you look for this feature?"
- "How do you think [feature X] works?"

### Step 3: Identify the Gap

| Question | Analysis |
|----------|---------|
| Is the system image unclear? | The product does not communicate its behavior effectively |
| Is the metaphor misleading? | The metaphor sets wrong expectations |
| Is the model too complex? | The user simplified the model and lost critical detail |
| Is prior experience interfering? | The user applies a model from a different product |

### Step 4: Fix the System Image

| Gap Type | Fix Strategy |
|----------|-------------|
| Unclear system image | Add signifiers, feedback, state indicators |
| Misleading metaphor | Revise the metaphor, add explanatory text |
| Over-simplified model | Progressive disclosure: teach complexity gradually |
| Prior product interference | Onboarding that highlights "how we're different" |

---

## Progressive Model Building: Simple to Complex

Users should not need to understand the full system model before they can use it. Start with a simple model and reveal complexity as users need it.

### Implementation Strategies

| Strategy | How It Works | Example |
|----------|-------------|---------|
| **Beginner mode / Advanced mode** | Two views of the same system | Photo editor: basic adjustments vs. full curve controls |
| **Layered settings** | Common settings visible, advanced settings collapsed | "Show advanced options" expander |
| **Contextual education** | Teach concepts when the user first encounters them | Tooltip on first use: "Tags let you organize items without folders" |
| **Graduated onboarding** | Introduce features across multiple sessions | Day 1: core actions. Day 3: shortcuts. Day 7: advanced features. |
| **Inline help** | Brief explanations embedded in the interface | "?" icon next to complex settings, opening a brief explanation |

### The Progression

```
Simple Model ──use──> Encounter Edge Case ──learn──> Richer Model ──use──> Mastery
```

- **Simple model**: "Delete moves items to Trash."
- **Edge case**: "I emptied the Trash. Can I get something back?"
- **Richer model**: "Trash is a 30-day holding period. After that, items are permanently removed. Premium users can recover items for 60 days."
- **Mastery**: The user understands the full lifecycle and plans accordingly.

---

## Conceptual Model Evaluation Techniques

### Technique 1: Draw-and-Explain

Ask 5 users to draw how they think the system works (boxes, arrows, flow). Compare their drawings to the actual architecture. Where drawings diverge from reality, the system image is failing.

### Technique 2: Prediction Test

Before performing an action, ask the user: "What do you think will happen when you click this?" If their prediction is wrong, their model is wrong. Identify what led to the incorrect prediction.

### Technique 3: Teaching Test

Ask a user who has used the product for a week to explain it to a new user. Listen for:
- Inaccurate explanations (model is wrong).
- Missing concepts (model is incomplete).
- Hedging ("I think it works like... but I'm not sure") (model is uncertain).

### Technique 4: Error Analysis

Catalog the errors users make. Group them by the incorrect assumption that caused the error. Each assumption reveals a model mismatch.

| Error | Incorrect Assumption | Model Fix |
|-------|---------------------|----------|
| User tries to drag files between cloud accounts | "My cloud drive works like a folder on my desktop" | Show account boundaries clearly |
| User types a URL in the search bar | "This text field is for navigating" | Differentiate search and address bar visually |
| User closes a tab expecting it to save | "Closing saves my work" | Auto-save, or prompt before closing unsaved work |

---

## Conceptual Model Examples

### The Thermostat

- **Designer's model**: Set a target temperature. The system turns heating or cooling on/off to reach and maintain it. Setting a higher number does not make it heat faster.
- **Common user model**: The thermostat is a valve. Higher number = more heat output = faster warming.
- **System image failure**: Most thermostats show only the target number, not the rate of heating or the current mechanism (on/off). This allows the "valve" model to persist.
- **Fix**: Show current temperature AND target temperature. Show "Heating to 72..." with an animated indicator. Show estimated time to reach target.

### The File System

- **Designer's model**: Hierarchical tree structure. Files have a single location. Shortcuts/aliases point to files but are not copies.
- **Common user model**: "My documents are somewhere in the computer." Many users have no spatial model of file organization.
- **System image failure**: File explorers show the tree but do not teach the concept of hierarchy. Path bars are technical. Search bypasses the model entirely.
- **Fix**: Show breadcrumbs as a path. Animate navigation (zoom into folder). Show "You are here" in the tree. Use metaphor: "Like folders in a filing cabinet."

### Version Control (Git)

- **Designer's model**: A directed acyclic graph of snapshots with branches, merges, and remote references.
- **Common user model**: "Save" with the ability to go back. Maybe: "a timeline of saves."
- **System image failure**: Git's command-line interface exposes the full graph model with no simplification. Error messages reference concepts (detached HEAD, rebase, cherry-pick) that have no intuitive mapping.
- **Fix**: Visual branch diagrams, simplified workflows ("save point" instead of "commit"), and hiding advanced graph operations behind explicit expert mode.

### Cloud Storage

- **Designer's model**: Files stored on remote servers, synchronized across devices with conflict resolution.
- **Common user model**: "My files are in the cloud" (vague). Some users: "The cloud IS my computer's folder."
- **System image failure**: Sync status is often hidden. Conflict resolution happens silently or with cryptic duplicate filenames.
- **Fix**: Show sync status per file (synced, syncing, conflict). Explain conflicts in plain language: "This file was edited on two devices. Which version do you want to keep?"

---

## Teaching Users Correct Models Through Design

### Do Not Rely on Documentation

Users do not read manuals, help pages, or knowledge bases before using a product. The product itself must teach its model.

### Techniques for In-Product Education

| Technique | When to Use | Example |
|-----------|-------------|---------|
| **Onboarding tour** | First-time use | Highlight key areas, explain core concepts in 3-5 steps |
| **Empty states** | No content yet | "You have no projects yet. Create one to get started." with illustration showing the concept |
| **Inline hints** | First encounter with a feature | "Tip: Drag columns to reorder them" shown once, then dismissed |
| **Animated transitions** | State changes | File animates from inbox to archive, teaching the user where it went |
| **Consistent patterns** | Everywhere | When every list behaves the same way, users generalize from one to all |
| **Error messages as teaching** | On mistakes | "You cannot delete a folder that contains files. Move or delete the files first." teaches hierarchy |
| **Progressive disclosure** | Complexity management | Show basic model first, reveal advanced model on demand |

### The Golden Rule of Model Teaching

**Show, do not tell.** An animation of a file moving to the trash teaches more than a paragraph of text explaining deletion. An inline preview of formatting teaches more than a formatting guide. Let users experience the model through interaction.

# Constraints: Limiting Actions to Prevent Errors

Constraints are design elements that limit the possible actions a user can take. Used well, they make errors impossible or improbable. The underlying principle is simple: instead of telling users what not to do, make the wrong action physically, logically, or semantically impossible. Every constraint added is one fewer error the user can make.

## Four Constraint Types

### Physical Constraints

Physical constraints use shape, size, or material properties to restrict actions.

| Constraint | How It Works | Example |
|-----------|-------------|---------|
| Shape exclusion | Parts only fit one way | USB-A plug has a correct orientation; USB-C fits both ways |
| Size limitation | Object is too large/small for wrong use | A large plug cannot fit a small socket |
| Material resistance | Force required prevents accidental activation | Childproof medicine bottle requires push-and-twist |
| Barrier | Physical blockage prevents access | Guardrails prevent cars from leaving the road |

**Digital equivalent**: Input masks, character limits, file type restrictions, and minimum/maximum values.

### Cultural Constraints

Cultural constraints rely on shared social conventions and learned norms to guide behavior.

| Constraint | How It Works | Example |
|-----------|-------------|---------|
| Social norms | Expected behavior in context | Whispering in a library, facing forward in an elevator |
| Color conventions | Shared color meanings | Red for stop/danger, green for go/safe |
| Positional conventions | Expected placement of elements | OK/Cancel button order (platform-dependent) |
| Interaction conventions | Learned digital behaviors | Double-click to open, single-click to select |

**Design implication**: Cultural constraints are powerful but invisible. Violating them causes confusion even when the system technically works.

### Semantic Constraints

Semantic constraints use the meaning of a situation to limit the set of possible actions.

| Constraint | How It Works | Example |
|-----------|-------------|---------|
| Contextual meaning | Meaning restricts logical placement | A rearview mirror only makes sense facing the rear |
| Role meaning | Knowledge of purpose limits actions | A windshield is obviously not a door |
| Temporal meaning | Timing restricts when actions make sense | Cannot review an order before adding items |

**Digital equivalent**: Contextual menus that show only relevant actions, conditional fields that appear based on prior selections.

### Logical Constraints

Logical constraints use reasoning to limit what is possible through exclusion.

| Constraint | How It Works | Example |
|-----------|-------------|---------|
| Process of elimination | Only one option remains | Last puzzle piece can only go in the remaining hole |
| Mutual exclusion | Choosing A makes B impossible | Radio buttons: selecting one deselects others |
| Dependency chains | Step B requires step A | Cannot format text before selecting it |
| Completeness check | All parts must be present | Form cannot submit until all required fields are filled |

---

## Digital Constraint Implementations

### Input Validation as Constraint

| Validation Type | What It Constrains | Implementation |
|----------------|-------------------|----------------|
| **Type restriction** | Only numbers, only letters, specific format | `input type="email"`, `type="tel"`, regex patterns |
| **Range restriction** | Minimum and maximum values | `min="0" max="100"`, date ranges, slider bounds |
| **Length restriction** | Character count | `maxlength="280"`, with visible counter |
| **Format restriction** | Specific pattern required | Input mask for phone: (___) ___-____ |
| **Enum restriction** | Only predefined options allowed | Dropdown, radio buttons, autocomplete with fixed list |
| **Real-time validation** | Invalid input rejected as typed | Inline error showing before form submission |

### Best Practices for Input Validation

- Prefer prevention over detection: use a date picker instead of validating a typed date.
- Validate in real time, not only on submit. Show inline feedback as the user types.
- When rejecting input, explain what is expected: "Phone number must be 10 digits" not "Invalid input."
- Accept flexible formats and normalize internally: "1234567890", "(123) 456-7890", and "123-456-7890" should all be accepted for a phone number.

### Progressive Disclosure as Constraint

Progressive disclosure constrains what users see and interact with, reducing cognitive load and preventing premature actions.

| Pattern | What It Constrains | Example |
|---------|-------------------|---------|
| **Collapsed sections** | Hides advanced options until requested | "Advanced settings" expandable panel |
| **Wizard / stepper** | Shows only current step | Multi-step checkout flow |
| **Conditional fields** | Shows fields only when relevant | "Other" text field appears only when "Other" is selected |
| **Role-based visibility** | Shows features based on permissions | Admin panel visible only to admin users |
| **Contextual menus** | Shows only actions relevant to the selected item | Right-click menu changes based on element type |

### Disabled States and Forced Sequences

Disabled states constrain users by making actions visually present but temporarily unavailable.

| Pattern | When to Use | How to Implement |
|---------|------------|-----------------|
| **Disabled button** | Required precondition not met | Gray out button, add tooltip explaining why |
| **Locked wizard step** | Prior steps incomplete | Show step indicator but prevent skipping ahead |
| **Conditional enable** | Depends on another field's value | Enable "Confirm" only after checkbox is checked |
| **Time-gated action** | Action requires waiting period | "You can send again in 30 seconds" with countdown |
| **Auth-gated action** | Requires login or elevated permissions | Show the action but redirect to login on click |

**Critical rule for disabled states**: Always explain why the action is disabled. A disabled button with no explanation is a constraint that creates frustration rather than guiding users.

| Implementation | User Experience |
|---------------|----------------|
| Disabled button, no explanation | "Why can't I click this? Is it broken?" |
| Disabled button with tooltip | "I see -- I need to fill in the required fields first." |
| Disabled button with inline helper text | "Fill in all required fields to enable submission." |

### Undo/Redo as Error Recovery Constraint

Undo/redo does not prevent errors, but it constrains the impact of errors by making them reversible.

| Pattern | Implementation | Example |
|---------|---------------|---------|
| **Immediate undo** | Toast notification with "Undo" link | Gmail "Message sent. Undo" |
| **Action history** | List of recent actions with rollback | Google Docs version history |
| **Soft delete** | Items move to trash, not permanently deleted | Recycle bin, 30-day retention |
| **Autosave with versions** | Every change is saved and reversible | Google Docs, Figma auto-save |
| **Confirmation dialog** | "Are you sure?" before destructive action | Delete account confirmation |

### When to Use Confirmation Dialogs

Confirmation dialogs are appropriate only for:
- **Irreversible** actions (delete account, send broadcast email)
- **High-consequence** actions (charge credit card, publish to production)
- **Unusual** actions (something the user does rarely and might have triggered accidentally)

They are NOT appropriate for:
- Routine actions (saving a document, closing a tab)
- Actions that are easily reversible (moving an item, changing a setting)
- Frequent operations (every dialog slows the user down and trains them to click "OK" without reading)

---

## Constraint Design Patterns by Use Case

### E-Commerce Checkout

| Constraint | Type | Purpose |
|-----------|------|---------|
| Cannot proceed to payment without shipping address | Logical (forced sequence) | Prevents incomplete orders |
| Credit card field accepts only digits with auto-formatting | Physical (input mask) | Prevents format errors |
| "Place Order" disabled until terms checkbox is checked | Logical (dependency) | Ensures legal compliance |
| Quantity selector with min=1, max=99 | Physical (range) | Prevents zero or absurd quantities |
| Address autocomplete from verified database | Semantic (constrained options) | Prevents undeliverable addresses |

### User Registration

| Constraint | Type | Purpose |
|-----------|------|---------|
| Password strength meter with minimum requirements | Physical (validation) | Prevents weak passwords |
| Email format validation | Physical (format) | Prevents invalid email addresses |
| Username uniqueness check (real-time) | Logical (exclusion) | Prevents duplicate accounts |
| Age gate with date picker | Semantic (contextual) | Prevents underage registration |
| CAPTCHA before submission | Cultural (convention) + Logical | Prevents automated abuse |

### Content Management

| Constraint | Type | Purpose |
|-----------|------|---------|
| Draft / Published / Archived states with transitions | Logical (forced sequence) | Content must be reviewed before publishing |
| Character limits on titles and descriptions | Physical (length) | Prevents layout-breaking content |
| Image upload restricted to specific formats and sizes | Physical (type + size) | Prevents unsupported media |
| Scheduled publish date must be in the future | Semantic (temporal) | Prevents backdated publishing |
| Role-based editing permissions | Cultural (authority) + Logical | Prevents unauthorized changes |

---

## When Constraints Help vs. Frustrate

### Constraints That Help

| Scenario | Why It Helps |
|----------|-------------|
| Date picker instead of free text | Users cannot enter an invalid date format |
| Disabled "Next" until required fields are complete | Users cannot skip required information |
| Autocomplete for city/state from zip code | Reduces typing and prevents mismatched data |
| File upload limit with clear message | Prevents timeout errors on oversized files |
| Character counter approaching limit | Users adjust their content proactively |

### Constraints That Frustrate

| Scenario | Why It Frustrates |
|----------|------------------|
| Password rules that are excessively complex | Users cannot create a memorable password |
| Dropdown with 200+ country options | Slower than typing; users scroll endlessly |
| Forced sequence when steps are independent | Users cannot fill in information in their preferred order |
| Preventing paste into a "confirm email" field | Users must retype, increasing error rate |
| Requiring phone number when it is not needed | Users feel the product is collecting unnecessary data |

### The Constraint Spectrum

```
Too few constraints          Just right               Too many constraints
      |                         |                           |
  Error-prone             Error-free, smooth          Frustrating, slow
  Confusing               Guided                      Patronizing
  Flexible                Efficient                   Rigid
```

The goal is the middle zone: enough constraints to prevent errors, not so many that users feel restricted.

---

## Anti-Patterns: Over-Constraining Users

| Anti-Pattern | Problem | Better Approach |
|-------------|---------|----------------|
| **Preventing copy-paste in forms** | Increases errors by forcing manual re-entry | Allow paste; validate the result |
| **Session timeouts without warning** | Users lose work without notice | Warn before timeout, offer extension |
| **Forced password change every 90 days** | Users choose weaker passwords to cope | Monitor for breaches instead |
| **Maximum line length in text fields** | Users cannot write naturally | Use soft limits with warnings, not hard limits |
| **Blocking form submission for non-critical warnings** | Users cannot proceed despite having correct intent | Distinguish errors (block) from warnings (allow with note) |
| **Requiring all fields when most are optional** | Users abandon the form | Mark truly required fields; make the rest optional |

---

## Constraint Audit Checklist

### Error Prevention

- [ ] All form inputs have appropriate type constraints (number fields accept only numbers, etc.).
- [ ] Date and time inputs use pickers rather than free-text fields.
- [ ] Required fields are clearly marked and enforced before submission.
- [ ] Actions that depend on preconditions are disabled (with explanation) until preconditions are met.
- [ ] Destructive actions require confirmation or offer undo.

### Input Quality

- [ ] Input masks or autocomplete are used for structured data (phone, postal code, credit card).
- [ ] Range constraints are enforced with clear min/max indicators.
- [ ] Real-time validation provides feedback as the user types.
- [ ] Error messages explain what is expected, not just what is wrong.

### Sequence and Flow

- [ ] Multi-step processes enforce logical order when necessary.
- [ ] Independent steps can be completed in any order.
- [ ] The current step and remaining steps are visible.
- [ ] Users can go back to previous steps without losing data.

### Recovery

- [ ] Undo is available for all non-destructive actions.
- [ ] Soft delete (trash/archive) is used instead of permanent deletion.
- [ ] Autosave prevents data loss.
- [ ] Session recovery restores unsaved work after timeout or crash.

### Appropriateness

- [ ] No constraint exists purely for the system's convenience at the user's expense.
- [ ] Constraints match the severity of the potential error.
- [ ] Users are not forced to provide information that is not necessary for the task.
- [ ] Paste is allowed in all text fields.
- [ ] Flexible input formats are accepted and normalized (phone numbers, dates).

# Feedback: Communicating Results Back to the User

Feedback is the information a system sends back to the user after an action. Without feedback, users operate in the dark: they cannot tell whether their action registered, whether it succeeded, or what state the system is in. The absence of feedback is one of the most common and damaging design failures. Every action a user takes must produce a perceivable response.

## Feedback Types

### Visual Feedback

The most common and versatile feedback channel. Visual feedback works for nearly all interactions because users are already looking at the interface.

| Pattern | When to Use | Example |
|---------|------------|---------|
| Color change | State transitions, validation | Button turns green on success, field border turns red on error |
| Animation | Object manipulation, transitions | Item slides off screen when deleted, card flips when toggled |
| Icon change | Status updates, toggle states | Bookmark icon fills in when activated, checkbox gets a checkmark |
| Text update | Confirmations, counts, values | "3 items selected", "Saved at 2:30 PM" |
| Position change | Drag-and-drop, reordering | Item moves to its new position in the list |
| Opacity change | Enable/disable, focus shift | Background dims when a modal opens |

### Auditory Feedback

Sound provides feedback without requiring the user to look at the screen. Useful for confirmations, alerts, and background processes.

| Pattern | When to Use | Example |
|---------|------------|---------|
| Confirmation tone | Action completed successfully | macOS "whoosh" on sent email |
| Error sound | Something went wrong | System alert sound on invalid action |
| Notification chime | New information available | Chat message received sound |
| Typing clicks | Keystroke registration (mobile) | Keyboard tap sounds on iOS |
| Progress tone | Background process advancing | Scanning/processing sound |

**Caution**: Always provide a way to mute sounds. Never rely on sound as the only feedback channel (accessibility requirement). Sound should supplement visual feedback, not replace it.

### Haptic Feedback

Vibration and force feedback on touch devices provide physical confirmation of actions.

| Pattern | When to Use | Example |
|---------|------------|---------|
| Tap confirmation | Button press registered | Short vibration on keypress |
| Selection feedback | Item selected or toggled | Subtle haptic pulse on toggle |
| Error feedback | Action failed or invalid | Sharp double-vibration on error |
| Boundary feedback | Reached end of scrollable content | Rubber-band haptic at scroll edge |
| Success feedback | Major action completed | Strong single pulse on "Order Placed" |

### Progress Feedback

Communicates advancement toward completion during longer operations.

| Pattern | When to Use | Duration Context |
|---------|------------|-----------------|
| Determinate progress bar | Duration is known/estimable | File upload, multi-step process |
| Indeterminate spinner | Duration is unknown | Network request, search |
| Skeleton screen | Content is loading | Page or section load |
| Percentage text | Precise progress matters | "Uploading: 67% complete" |
| Step indicator | Multi-phase process | "Step 2 of 4: Payment" |
| Elapsed time counter | Very long operations | "Processing... 3m 22s elapsed" |

---

## Response Time Guidelines

These thresholds, established by usability research (Miller 1968, Card et al. 1983, Nielsen 1993), define user expectations for system response.

| Threshold | User Perception | Required Feedback |
|:---------:|----------------|-------------------|
| **0 - 100ms** | Instantaneous. Action feels directly connected to result. | Direct visual change (color, position, state). No loading indicator needed. |
| **100ms - 1s** | Noticeable delay. Still feels responsive but the system is "thinking." | Show cursor change or subtle animation. No spinner needed yet. |
| **1s - 10s** | Significant delay. User's attention begins to wander. | Show spinner or progress indicator. Keep the user informed that work is happening. |
| **10s - 60s** | Long wait. User may switch tasks. | Show progress bar with percentage or estimated time. Allow the operation to continue in the background. |
| **> 60s** | Very long wait. User may assume failure. | Show progress, elapsed time, and estimated remaining time. Send a notification when complete. Allow the user to navigate away. |

### Response Time by Interaction Type

| Interaction | Expected Response Time | Feedback Strategy |
|-------------|:---------------------:|-------------------|
| Button click | < 100ms | Instant visual state change |
| Form field validation | < 300ms after typing stops | Inline validation message |
| Page navigation | < 1s | Skeleton screen or loading bar |
| Search results | < 2s | Skeleton screen with animated placeholder |
| File upload (small) | 1-5s | Progress bar |
| File upload (large) | 5-60s+ | Progress bar with percentage and cancel button |
| Data export | 10s-5min | Background process with notification on completion |
| Account creation | < 3s | Full-screen success state |

---

## Feedback Patterns by Interaction Type

### Click / Tap Feedback

| State | Visual Feedback | Purpose |
|-------|----------------|---------|
| Hover | Background color change, cursor change | "This is interactive" |
| Active (pressed) | Darker color, slight scale-down | "Your click registered" |
| Loading | Spinner replaces label, or button shows loading state | "Processing your request" |
| Success | Checkmark icon, color change to green, or toast message | "Action completed" |
| Error | Shake animation, red color, or inline error message | "Something went wrong" |

### Form Submission Feedback

| Stage | Feedback | Implementation |
|-------|----------|---------------|
| Validation (inline) | Green checkmark or red error per field | Show as user completes each field |
| Submission initiated | Button shows loading state, form inputs disabled | Prevent duplicate submissions |
| Success | Toast notification, redirect, or inline success message | "Your changes have been saved" |
| Partial success | Yellow warning with details | "Saved, but 2 fields need attention" |
| Failure | Inline errors at fields, summary at top, form data preserved | Never erase user input on error |

### Drag and Drop Feedback

| Stage | Feedback | Purpose |
|-------|----------|---------|
| Drag start | Element lifts (shadow increase), ghost follows cursor | "You are holding this" |
| Drag over valid target | Drop zone highlights (border, background) | "You can drop here" |
| Drag over invalid target | No highlight, or red border, cursor shows "not-allowed" | "You cannot drop here" |
| Drop | Element animates to new position, drop zone returns to normal | "Placed successfully" |
| Cancel (drop outside) | Element animates back to original position | "Action cancelled, nothing changed" |

### Loading State Patterns

| Pattern | Best For | Description |
|---------|----------|-------------|
| **Spinner** | Unknown duration, small area | Rotating circle or dots. Simple but uninformative. |
| **Skeleton screen** | Page or section loads | Gray placeholder shapes matching content layout. Feels faster than a spinner. |
| **Progress bar (determinate)** | Known duration | Fills from left to right. Best when you can calculate progress. |
| **Progress bar (indeterminate)** | Unknown duration, larger area | Bar animates back and forth. Better than spinner for larger regions. |
| **Percentage text** | Long operations | "43% complete" gives precise expectation. |
| **Shimmer effect** | Content cards, lists | Gradient animation flowing across placeholder shapes. |

### Error Feedback

| Principle | Implementation |
|-----------|---------------|
| Say what went wrong | "Your password must be at least 8 characters" not "Invalid input" |
| Say how to fix it | "Add 3 more characters to your password" |
| Do not blame the user | "That email address is not registered" not "You entered a wrong email" |
| Preserve user's work | Never clear a form on error. Show errors inline and let users fix them. |
| Use appropriate severity | Red and bold for blocking errors. Yellow for warnings. Gray for hints. |
| Place errors near the source | Inline errors below the relevant field. Summary at the top for multiple errors. |

### Error Message Template

```
[Icon] [What happened]
[Why it happened - optional, if it helps]
[How to fix it]
[Alternative action - optional]
```

**Example**:
```
[!] We could not process your payment.
Your card was declined by the issuing bank.
Please try a different card or contact your bank.
[Try a different payment method]
```

### Success Feedback

| Pattern | When to Use | Example |
|---------|------------|---------|
| **Toast notification** | Non-critical confirmations | "Settings saved" (auto-dismiss after 4s) |
| **Inline success message** | Form submissions | Green banner: "Your profile has been updated" |
| **Full-screen celebration** | Major milestones | Confetti animation on completing onboarding |
| **Redirect with flash** | After creating something | Redirect to the new item with a "Created successfully" banner |
| **Subtle state change** | Toggle/minor actions | Star icon fills in, count increments |
| **Email/notification** | Background processes | "Your export is ready" email with download link |

---

## Too Much vs. Too Little Feedback

### Too Little Feedback

| Symptom | User Impact | Fix |
|---------|-------------|-----|
| Click produces no visible change | User clicks again, causing duplicates | Add immediate visual state change on click |
| Form submits with no confirmation | User resubmits, or navigates away unsure | Show success toast or redirect to confirmation |
| Background save with no indicator | User manually saves repeatedly | Show "Saved" indicator with timestamp |
| Error fails silently | User believes action succeeded | Always show errors explicitly |
| Long process with no progress | User assumes system is frozen | Show progress indicator for any operation > 1 second |

### Too Much Feedback

| Symptom | User Impact | Fix |
|---------|-------------|-----|
| Alert dialog for every action | User develops "dialog blindness" and clicks OK without reading | Use toasts for non-critical feedback, reserve dialogs for critical confirmations |
| Sound on every click | Annoying, especially in shared spaces | Use sound sparingly, only for important events |
| Animation on every state change | Interface feels hyperactive and distracting | Limit animation to meaningful transitions |
| Multiple notification channels for one event | Email + push + in-app + SMS overwhelms | Let users choose notification channels |
| Confirmation toast that blocks content | User must dismiss it before continuing | Use non-blocking toast that auto-dismisses |

### The Feedback Balance Rule

- Every action needs *some* feedback.
- Not every action needs *prominent* feedback.
- Match feedback prominence to action importance.

| Action Importance | Feedback Prominence |
|:-----------------:|:-------------------:|
| Critical (delete account, payment) | Modal dialog, full-screen confirmation |
| Important (save, submit, send) | Toast notification, inline confirmation |
| Routine (click, select, toggle) | Subtle visual state change |
| Ambient (auto-save, sync) | Tiny indicator, no interruption |

---

## Feedback in Accessibility Context

| User Group | Requirements |
|-----------|-------------|
| **Screen reader** | ARIA live regions for dynamic updates; `role="alert"` for errors; progress announcements; focus moves to new messages |
| **Keyboard-only** | Visible focus rings; focus moves to resulting content after actions; loading states trap focus appropriately |
| **Low-vision** | Color paired with icon and text; animations paired with text messages; WCAG 4.5:1 contrast |
| **Motion-sensitive** | `prefers-reduced-motion` alternatives; no aggressive pulsing; avoid parallax and spinning |

---

## Feedback Audit Checklist

### Presence

- [ ] Every clickable element has a visible response within 100ms.
- [ ] Every form submission produces explicit success or error feedback.
- [ ] Every operation longer than 1 second shows a loading indicator.
- [ ] Every error displays a human-readable message with remediation steps.
- [ ] State changes (toggle, selection, mode) produce visible feedback.

### Timing

- [ ] Direct manipulation feedback is under 100ms.
- [ ] Inline validation fires within 300ms after the user stops typing.
- [ ] Spinners appear within 1 second of starting a long operation.
- [ ] Toast messages auto-dismiss in 4-8 seconds (with a way to dismiss manually or keep visible).
- [ ] Background operations notify the user upon completion.

### Appropriateness

- [ ] Critical actions produce prominent feedback (modal, full-screen).
- [ ] Routine actions produce subtle feedback (state change, micro-animation).
- [ ] No unnecessary alert dialogs for routine confirmations.
- [ ] Sound feedback has a mute option.
- [ ] Feedback does not block the user's primary workflow.

### Accessibility

- [ ] ARIA live regions announce dynamic feedback for screen readers.
- [ ] Focus moves to error messages or success messages as appropriate.
- [ ] Color is not the only feedback channel (icons, text, borders also used).
- [ ] Animations have reduced-motion alternatives.
- [ ] Error messages identify which field has the problem.

### Content

- [ ] Error messages say what went wrong, why, and how to fix it.
- [ ] Success messages confirm what was done.
- [ ] Progress indicators show meaningful advancement (not just spinning).
- [ ] System state is visible at all times (connection status, save status, mode).

---

## Examples of Excellent and Poor Feedback

### Excellent: Gmail Undo Send

After clicking Send, Gmail shows a toast: "Message sent. Undo." The toast persists for a configurable number of seconds. The user has visual confirmation (message sent) and an immediate recovery option (undo). Feedback and error recovery in a single, unobtrusive element.

### Excellent: Stripe Payment Form

As the user types a credit card number, the form identifies the card type (Visa, Mastercard) and displays the logo. Invalid digits are rejected in real-time. The expiration date auto-formats. Errors appear inline below each field. The submit button shows a spinner during processing and a checkmark on success. Every stage of the interaction has clear, immediate feedback.

### Poor: Silent Form Submission

A contact form has a "Submit" button. The user clicks it. Nothing happens for 3 seconds, then the page reloads and the form is empty. Did the message send? The user has no way to know. They may submit again, creating duplicates, or leave without confidence.

### Poor: Aggressive Alert Dialogs

An enterprise application shows an alert dialog for every action: "Are you sure you want to save?" "Save successful!" "Are you sure you want to navigate away?" Users click OK/Yes on every dialog without reading them, which means when a truly important confirmation appears (like permanent deletion), it is dismissed reflexively.

### Poor: Invisible Background Sync

A note-taking app syncs to the cloud in the background but provides no indicator. The user edits a note, closes the app, and opens it on another device expecting to see the changes. The sync had not completed. No feedback was ever given about sync status, so the user had no way to know.

# Human Error: Designing for Mistakes

There is no such thing as human error. There is only bad design. When a person makes an error, the cause is almost always a design flaw: poor feedback, misleading signifiers, bad mappings, missing constraints, or a broken conceptual model. Blaming users for errors is the designer's greatest failure. Instead, design systems that prevent errors, tolerate errors, and make recovery easy.

## Slips vs. Mistakes: The Fundamental Taxonomy

Don Norman divides errors into two categories based on where the failure occurs in the action cycle.

| | Slips | Mistakes |
|---|-------|---------|
| **Definition** | Correct intention, wrong action | Wrong intention, correctly executed |
| **Cause** | Attention failure, motor error, habit | Incorrect mental model, wrong rule, faulty reasoning |
| **Awareness** | User often notices immediately | User may not realize error until consequences appear |
| **Example** | Clicking "Delete" when reaching for "Edit" | Using the wrong formula in a spreadsheet because the user misunderstands the data |
| **Fix approach** | Make actions distinct and recoverable | Build correct conceptual models and provide better information |

---

## Slip Types

### Action-Based Slips

The user intends to perform one action but accidentally performs a similar or adjacent one.

| Subtype | Mechanism | Example | Design Prevention |
|---------|-----------|---------|-------------------|
| **Adjacent target** | Clicking the wrong button because it is too close | Tapping "Delete" instead of "Edit" on mobile | Separate destructive actions from constructive ones by distance and visual style |
| **Similar action** | Performing a habitual action instead of the intended one | Typing your old password after changing it | Provide clear feedback when the old credential is rejected and guide to the new one |
| **Description similarity** | Confusing two objects that look alike | Grabbing the wrong file from a list of similar names | Make distinguishing information prominent (dates, sizes, thumbnails) |

### Memory-Lapse Slips

The user forgets a step in a familiar sequence.

| Subtype | Mechanism | Example | Design Prevention |
|---------|-----------|---------|-------------------|
| **Omitted step** | Skipping a step in a multi-step task | Forgetting to attach a file after writing "see attached" | Detect the omission (Gmail attachment reminder) |
| **Lost place** | Forgetting which step they are on | Returning to a form after an interruption and re-entering data | Persist form state; show progress indicators |
| **Forgotten intention** | Walking to a room and forgetting why | Opening a settings page and forgetting which setting to change | Provide search within settings; show recently changed items |

### Mode Errors

The user performs the correct action for one mode while the system is in a different mode.

| Subtype | Mechanism | Example | Design Prevention |
|---------|-----------|---------|-------------------|
| **Invisible mode** | The current mode is not visually indicated | Typing in all caps because caps lock is on with no indicator | Always show the current mode visually (caps lock indicator, edit/view mode badge) |
| **Unexpected mode change** | The system changed modes without the user noticing | Airplane auto-throttle disengages silently | Announce mode changes with prominent feedback |
| **Cross-application mode** | Different behavior in different apps for the same action | Ctrl+S saves in one app, does something else in another | Follow platform conventions; never repurpose standard shortcuts |

### Capture Errors

A frequently performed action "captures" and overrides the intended less-frequent action.

| Subtype | Mechanism | Example | Design Prevention |
|---------|-----------|---------|-------------------|
| **Habit capture** | Habitual sequence overrides intended deviation | Driving to old workplace instead of new one on autopilot | Insert interruptions at decision points in habitual sequences |
| **Routine capture** | A daily routine overrides a one-time variation | Opening email client instead of the report you intended to work on | Use reminders, task lists, and calendar blocks to interrupt routines |

---

## Mistake Types

### Rule-Based Mistakes

The user applies a correct rule in the wrong situation, or applies a wrong rule that seems correct.

| Subtype | Mechanism | Example | Design Prevention |
|---------|-----------|---------|-------------------|
| **Wrong rule** | Applying a rule from a different context | Using "Reply All" when only "Reply" was appropriate because the user follows a "always reply all" rule | Show recipient count prominently, warn on large recipient lists |
| **Misclassified situation** | Correctly following a rule, but for the wrong problem type | Using the standard password reset flow when the account is actually locked (different issue, different fix) | Diagnose the situation for the user before presenting solutions |
| **Outdated rule** | Following a rule that used to be correct | A nurse giving a medication dose based on an old protocol | Version and timestamp all rules, policies, and procedures visible in the interface |

### Knowledge-Based Mistakes

The user lacks the knowledge or has an incorrect mental model to handle a novel situation.

| Subtype | Mechanism | Example | Design Prevention |
|---------|-----------|---------|-------------------|
| **Incomplete model** | The user's understanding of the system is partial | A user deletes a shared file not knowing it affects other users | Show sharing indicators and warn about impact |
| **Incorrect model** | The user's understanding is actively wrong | User believes setting thermostat to 90 heats the room faster | Redesign system image to teach correct model (show heating rate) |
| **Analogy failure** | Applying a model from one system to a different system | Expecting "undo" to work like a timeline when it actually works as a stack | Make the undo model explicit: show action history |

### Memory-Lapse Mistakes

The user forgets their goal, plan, or evaluation criteria.

| Subtype | Mechanism | Example | Design Prevention |
|---------|-----------|---------|-------------------|
| **Forgotten goal** | Losing track of what they set out to do | Opening the phone to set a timer but getting distracted by notifications | Provide reminders: "You opened Settings. Looking for something?" |
| **Forgotten plan** | Losing track of multi-step plan | Forgetting the third item in a three-item to-do after completing the first two | Show task lists, checklists, and recently started workflows |
| **Forgotten evaluation** | Forgetting what "success" looks like | Adjusting a photo but forgetting the original state to compare against | Provide before/after toggle, history, or comparison view |

---

## Error Prevention Strategies by Type

### Preventing Slips

| Strategy | Implementation | Prevents |
|----------|---------------|----------|
| **Increase target distance** | Separate destructive actions from routine actions by space and visual grouping | Adjacent target slips |
| **Distinctive appearance** | Make destructive buttons red, routine buttons blue | Description similarity slips |
| **Confirmation for irreversible actions** | "Delete this account? This cannot be undone." | Action slips with permanent consequences |
| **Mode indicators** | Always-visible badge showing current mode | Mode errors |
| **Interrupts at decision points** | "You're about to send to 500 people. Continue?" | Capture errors, memory-lapse slips |
| **Auto-detection** | Detect likely omissions and prompt | Memory-lapse slips (Gmail attachment warning) |
| **Constraints** | Disable invalid actions, enforce sequences | Multiple slip types |

### Preventing Mistakes

| Strategy | Implementation | Prevents |
|----------|---------------|----------|
| **Clear conceptual models** | Make system behavior visible and predictable | Knowledge-based mistakes |
| **Contextual information** | Show relevant data at the point of decision | Rule-based mistakes |
| **Undo and exploration** | Let users try things safely | Fear-based inaction (a form of mistake) |
| **Wizards and guides** | Step-by-step assistance for complex tasks | Knowledge-based and rule-based mistakes |
| **Default values** | Pre-fill with the most common or safest option | All mistake types |
| **Checklists** | Visible task lists for multi-step processes | Memory-lapse mistakes |
| **Comparisons** | Show before/after, show alternatives side-by-side | Forgotten-evaluation mistakes |

---

## Error Recovery Patterns

### Undo

| Pattern | Scope | Implementation |
|---------|-------|---------------|
| **Single undo** | Most recent action | Ctrl+Z, "Undo" button |
| **Multi-level undo** | Multiple recent actions | Undo stack with history list |
| **Undo toast** | Time-limited reversal | "Action completed. Undo (5s)" |
| **Version history** | All changes over time | Named versions, autosave snapshots |
| **Soft delete** | Deletion recovery | Trash bin with 30-day retention |

### Confirmation Dialogs

Use confirmation dialogs sparingly and only for high-consequence, irreversible actions.

| Effective Confirmation | Ineffective Confirmation |
|-----------------------|------------------------|
| "Delete 47 files permanently? This cannot be undone." | "Are you sure you want to save?" |
| "Send this email to 1,200 subscribers?" | "Are you sure you want to close this tab?" |
| "Downgrade your account? You will lose access to premium features." | "Are you sure you want to log out?" |

**The confirmation dialog trap**: If you show confirmations for routine actions, users develop "dialog blindness" and click "Yes" without reading. Then the one time the confirmation matters, they click "Yes" again out of habit.

### Autosave

| Feature | Purpose |
|---------|---------|
| Continuous autosave | No work is ever lost due to crash, timeout, or accidental navigation |
| Visible save indicator | "All changes saved" or "Saving..." shows the user the system is working |
| Named save points | Users can create explicit save points for comparison |
| Conflict resolution | When two versions exist, show both and let the user choose |

### Clear Error Messages

**The error message formula**:

```
1. What happened (in plain language)
2. Why it happened (if helpful)
3. How to fix it (specific actionable steps)
4. Alternative path (if available)
```

**Good example**:
```
We couldn't save your changes.
Your internet connection was interrupted.
Check your connection and try again, or download a copy of your work.
[Retry] [Download Copy]
```

**Bad example**:
```
Error 500: Internal Server Error
```

---

## Error Message Design Checklist

### Content

- [ ] Message describes what happened in human language (no error codes as the primary message).
- [ ] Message explains how to fix the problem or what to try next.
- [ ] Message does not blame the user ("We couldn't process" not "You entered incorrectly").
- [ ] Message provides an alternative path when possible.
- [ ] Technical details are available but not prominent (expandable section).

### Presentation

- [ ] Error appears near the source of the error (inline for form fields).
- [ ] Error is visually distinct (red border, error icon) but not alarming (avoid all-caps, exclamation marks).
- [ ] Error does not erase the user's work (form fields retain their values).
- [ ] Error is announced to screen readers (role="alert" or aria-live="assertive").
- [ ] Error is persistent until the user fixes the issue (does not auto-dismiss).

### Recovery

- [ ] A clear action is provided (button, link, or instruction).
- [ ] The user can retry without re-entering information.
- [ ] If the error is systemic (server down), communicate expected resolution time.
- [ ] If the error requires support, provide a direct path to contact support with the error context pre-filled.

---

## Designing for Error Tolerance

Error-tolerant systems assume users will make errors and minimize their consequences.

### Principles of Error Tolerance

| Principle | Implementation |
|-----------|---------------|
| **Reversibility** | Every action can be undone. Deletion is soft. Edits are versioned. |
| **Low cost of experimentation** | Users can try things without fear. Preview modes, sandbox environments, and undo reduce the risk of exploration. |
| **Graduated consequences** | Minor actions have minor consequences. Major consequences require major confirmation. |
| **Data preservation** | The system never discards user data without explicit, confirmed intent. Form data survives errors, navigation, and session timeouts. |
| **Graceful degradation** | When something breaks, the system continues working at reduced capacity rather than failing completely. |

---

## The Swiss Cheese Model of Errors

James Reason's Swiss Cheese Model explains how errors lead to disasters. Each layer of defense has holes (like Swiss cheese). An error becomes a disaster only when the holes in multiple layers align and the error passes through all defenses.

### Layers of Defense in Digital Products

| Layer | Defense | Example |
|-------|---------|---------|
| **Layer 1: UI Constraints** | Prevent the action from being possible | Disabled button, input validation, type-safe inputs |
| **Layer 2: Warnings** | Alert the user before they proceed | "This will delete 47 files. Are you sure?" |
| **Layer 3: Immediate Feedback** | Show the result so the user can catch the error | File count changes, visual confirmation |
| **Layer 4: Undo / Reversal** | Allow the user to reverse the action | "Undo" toast, trash bin, version history |
| **Layer 5: Recovery** | Restore from backup or contact support | 30-day trash retention, admin recovery tools |

For every critical action, ensure at least 3 layers of defense. If any single layer fails, the others catch the error.

---

## Case Studies of Error-Prone Designs and Fixes

| Case | Error | Root Cause | Fix |
|------|-------|-----------|-----|
| **Reply vs Reply All** | Private comment sent to entire organization | Buttons adjacent, identical, equally prominent | Make "Reply" default; show recipient count before sending |
| **Unsaved form on navigation** | User loses form data by clicking a link | No autosave, no navigation warning | Autosave to local storage; warn on navigation; restore on return |
| **Wrong file overwrite** | New file silently replaces existing file | No collision warning, no version history | Detect collision and warn; keep version history |
| **Medication dosage** | Nurse enters 10mg instead of 1.0mg | Free-text input, no range validation, small targets | Pre-set dose dropdown; range validation; large targets |

---

## Error Audit Checklist

### Prevention

- [ ] Destructive actions are visually separated from routine actions.
- [ ] Destructive actions require confirmation (for irreversible actions only).
- [ ] Input constraints prevent invalid data entry (type, range, format).
- [ ] The system detects likely omissions and prompts the user (attachment reminders, required fields).
- [ ] Mode indicators are always visible when modes exist.
- [ ] Default values are set to the safest or most common option.

### Detection

- [ ] Every action produces visible feedback within 100ms.
- [ ] Error messages appear inline near the source of the error.
- [ ] Error messages describe what happened, why, and how to fix it.
- [ ] Error messages do not blame the user.
- [ ] System state is visible at all times (saved/unsaved, connected/disconnected).

### Recovery

- [ ] Undo is available for all non-destructive actions.
- [ ] Deleted items go to a recoverable trash/archive.
- [ ] Form data is preserved on error (fields are not cleared).
- [ ] Autosave prevents data loss from crashes and timeouts.
- [ ] Version history allows reverting to previous states.
- [ ] Session recovery restores work after accidental closure.

### Systemic

- [ ] Errors are logged and analyzed for design improvement (not user blame).
- [ ] The most common user errors are tracked and addressed in design iterations.
- [ ] New features are tested for common slip and mistake patterns before launch.
- [ ] Error rate is a tracked product metric alongside task completion and satisfaction.

# Mappings: Connecting Controls to Outcomes

A mapping is the relationship between a control and its effect. When the mapping is natural, the connection between the two is obvious and immediate. When the mapping is arbitrary, users must memorize or guess which control does what. Natural mappings exploit spatial analogies, cultural conventions, and logical relationships to make products intuitive without instruction.

## Natural Mapping Principles

Natural mapping means the layout of the controls corresponds to the layout of the things being controlled. The best mappings require zero explanation.

### The Spectrum of Mapping Quality

| Quality | Characteristics | Learning Effort | Example |
|---------|----------------|-----------------|---------|
| **Natural / Direct** | Control IS the thing | None | Touchscreen: tap directly on the element to manipulate it |
| **Spatial analog** | Control layout mirrors output layout | Minimal | Car seat adjustment shaped like a miniature seat |
| **Cultural convention** | Learned but universally known | Low (one-time) | Red = stop, green = go |
| **Labeled arbitrary** | No inherent connection, but labeled | Moderate | Labeled switches on a panel |
| **Unlabeled arbitrary** | No inherent connection, no label | High (memorization) | Unmarked row of identical switches |

---

## Spatial Mapping: Controls Match Layout of Output

Spatial mapping is the most powerful type. When controls are arranged in the same physical pattern as the things they control, users do not need to think.

### Principles

1. **Layout correspondence**: If the controlled objects are arranged in a 2x2 grid, arrange the controls in a 2x2 grid.
2. **Direction correspondence**: Moving a control up should make something go up. Moving it right should make something go right.
3. **Proximity**: Each control should be physically close to the thing it affects.

### Real-World Examples

| Product | Spatial Mapping | Why It Works |
|---------|----------------|-------------|
| Car seat adjuster (Mercedes style) | A miniature seat shape that you tilt, slide, or raise | The control IS a spatial model of the seat |
| Elevator buttons arranged vertically | Higher button = higher floor | Spatial direction matches physical direction |
| Car side mirrors with a joystick | Push joystick left = mirror angles left | Direction of control matches direction of result |
| Crosswalk button facing the street it controls | Button faces the direction of the crosswalk | Proximity and orientation match |

### Digital Spatial Mapping

| Pattern | Spatial Relationship | Example |
|---------|---------------------|---------|
| Inline editing | Click on the content itself to edit it | Click a table cell to edit the value directly |
| WYSIWYG editors | What you see on screen matches the output | Document editors where formatting is visible |
| Drag-to-reorder | Move items to their new position directly | Drag a list item from position 3 to position 1 |
| Map controls | Pan the map by dragging the map itself | Google Maps, Figma canvas |
| Layout builders | Drag components to their spatial position | Website builders, dashboard editors |

---

## Proximity Mapping: Controls Near What They Affect

When a control is placed next to the thing it affects, the relationship is self-evident.

### Principles

1. **Adjacent placement**: The edit button should be next to the content it edits.
2. **Grouping**: Related controls should be grouped visually.
3. **Context menus**: Show actions in the context of the object they affect.

### Digital Proximity Patterns

| Pattern | Implementation | Benefit |
|---------|---------------|---------|
| Inline action buttons | Edit, delete, and copy icons appear on hover within each row | No ambiguity about which item the action affects |
| Contextual toolbars | Text formatting toolbar appears directly above selected text | Toolbar is clearly associated with the selection |
| Section-level controls | An "Add item" button at the bottom of the section it adds to | Users see where the new item will appear |
| Form-field validation | Error message appears directly below the field with the error | No confusion about which field is problematic |
| Tooltip/popover on element | Information appears next to the element that triggered it | Spatial proximity creates clear association |

### Proximity Failures

| Failure | Problem | Fix |
|---------|---------|-----|
| Global action bar far from content | Users cannot tell which content the actions apply to | Move actions inline or use clear selection indicators |
| Settings in a separate page | Users cannot see the effect of their changes | Show a live preview next to the settings |
| Error summary at the top of a form | Users must scroll to find the problematic field | Show errors inline at each field AND in a summary |

---

## Cultural Mapping: Conventions and Expectations

Cultural mappings are not inherently spatial or logical. They are learned conventions that most users in a culture share.

### Common Cultural Conventions

| Convention | Meaning | Scope |
|-----------|---------|-------|
| Red = danger / stop / error | Negative, cautionary | Near-universal |
| Green = safe / go / success | Positive, permissive | Near-universal |
| Left-to-right reading order | Sequence flows left to right | Western, many Asian |
| Right-to-left reading order | Sequence flows right to left | Arabic, Hebrew |
| Top-to-bottom = primary-to-secondary | Importance decreases downward | Most web conventions |
| X icon in top-right = close | Dismiss this window or dialog | Desktop and web |
| Floppy disk icon = save | Store the current state | Legacy but persistent |
| Shopping cart icon = purchase collection | Items selected for purchase | E-commerce |

### When Cultural Conventions Conflict

| Scenario | Conflict | Resolution |
|----------|----------|-----------|
| RTL vs LTR navigation arrows | "Forward" arrow points opposite directions | Flip arrow direction based on locale |
| Color meanings across cultures | Red means danger (West) vs. luck (East Asia) | Use icons and text alongside color |
| Date format | MM/DD/YYYY (US) vs DD/MM/YYYY (most of the world) | Use unambiguous format: "10 Feb 2024" or a date picker |
| Scroll direction | Natural scroll (Mac) vs. traditional scroll | Let users configure, but pick a default and commit |

---

## Sequential Mapping: Order Matches Natural Flow

Sequential mapping means the order of controls or steps matches the natural order of the task.

### Principles

1. **Temporal order**: Steps should be presented in the order they are performed.
2. **Reading order**: In LTR cultures, sequences should flow left-to-right or top-to-bottom.
3. **Dependency order**: Steps that depend on prior input should appear after that input.

### Digital Sequential Mapping Patterns

| Pattern | Implementation | Example |
|---------|---------------|---------|
| Multi-step wizard | Steps progress left-to-right in a stepper | Checkout: Shipping > Payment > Review > Confirm |
| Form field order | Fields ordered by task logic | Name > Email > Password > Confirm Password |
| Timeline / activity feed | Most recent at top, oldest at bottom (or reverse) | Consistent chronological direction |
| Breadcrumbs | Left-most is the root, right-most is the current page | Home > Category > Subcategory > Product |

### Sequential Mapping Failures

| Failure | Problem | Fix |
|---------|---------|-----|
| Address form: City before Street | Violates natural writing order | Reorder to match how people write addresses |
| Payment details before cart review | Users commit before seeing what they are paying for | Show cart summary before payment step |
| "Cancel" button before "Submit" | Reading order suggests cancel is the primary action | Place primary action (Submit) at the end of the reading flow |

---

## Mapping Evaluation Framework

Use this framework to evaluate the mapping quality of any control-to-outcome relationship.

### Mapping Quality Scorecard

| Criterion | Score (1-5) | Notes |
|-----------|:-----------:|-------|
| **Spatial correspondence**: Does the control layout mirror the output layout? | | |
| **Proximity**: Is the control near the thing it affects? | | |
| **Direction**: Does the direction of control movement match the direction of effect? | | |
| **Convention**: Does the mapping follow established cultural conventions? | | |
| **Sequence**: Do steps follow the natural task order? | | |
| **Labeling**: When mapping is not natural, are labels clear and complete? | | |
| **Consistency**: Are similar mappings used consistently throughout the product? | | |
| **Total (average)** | | |

### Interpretation

| Average Score | Quality | Action |
|:------------:|---------|--------|
| 4.5 - 5.0 | Excellent natural mapping | Maintain; minor refinements only |
| 3.5 - 4.4 | Good but learnable | Improve labels and proximity |
| 2.5 - 3.4 | Moderate; requires some learning | Redesign layout to improve spatial and sequential mapping |
| 1.0 - 2.4 | Poor; arbitrary mapping | Fundamental redesign required |

---

## Classic Mapping Failures

### The Stovetop Knob Problem

**Setup**: Four burners arranged in a 2x2 grid. Four knobs arranged in a 1x4 row.

**Problem**: Users cannot tell which knob controls which burner without reading labels, because the linear arrangement of knobs does not match the grid arrangement of burners.

**Fix**: Arrange knobs in a 2x2 grid matching the burner layout, or place each knob directly adjacent to its burner.

### The Light Switch Panel

**Setup**: A row of 6 identical switches controlling lights in different parts of a room.

**Problem**: No spatial correspondence between switch position and light position. Users flip switches randomly.

**Fix**: Arrange switches on a floor plan diagram, or label each switch with the zone it controls, or use smart lighting with per-fixture controls.

### The Elevator Button Panel

**Setup**: Two columns of buttons for floors 1-20.

**Problem**: Is floor 3 in the left column or the right column? Does the left column go up or does the right column? Convention varies between buildings.

**Fix**: A single vertical column where higher buttons correspond to higher floors. Simple, unambiguous spatial mapping.

### The Hotel Shower

**Setup**: A single unmarked knob that controls both temperature and flow.

**Problem**: Users cannot predict whether turning the knob will make the water hotter, colder, or change the pressure. The mapping of rotation direction to outcome is not signified.

**Fix**: Separate temperature and flow controls. Mark hot and cold directions with color (red/blue) and use a consistent rotation convention.

---

## Digital Mapping Patterns

### Settings Panels

| Pattern | Mapping Quality | Why |
|---------|:--------------:|-----|
| Settings grouped by feature, with live preview | High | Proximity to affected feature, immediate feedback |
| Alphabetical settings list | Low | No correspondence between position and function |
| Settings organized by user task | Medium-High | Sequential mapping aligned with task flow |
| Tabbed settings with icons | Medium | Grouping helps, but icon-only tabs can be ambiguous |

### Form Layouts

| Pattern | Mapping Quality | Why |
|---------|:--------------:|-----|
| Single column, top-to-bottom | High | Matches reading order and task sequence |
| Two-column with related fields side by side | Medium-High | Spatial grouping of related fields (First Name / Last Name) |
| Multi-column with unrelated fields | Low | Reading path is ambiguous (left-to-right then down? Or top-to-bottom then right?) |
| Accordion sections | Medium | Groups are clear, but hidden sections break spatial awareness |

### Navigation

| Pattern | Mapping Quality | Why |
|---------|:--------------:|-----|
| Tab bar with current tab highlighted | High | Position indicates section, highlight indicates current state |
| Sidebar matching page structure | High | Spatial hierarchy mirrors content hierarchy |
| Hamburger menu hiding all navigation | Low | No persistent spatial reference; user must open menu to see options |
| Breadcrumbs with clickable segments | High | Sequential mapping showing path from root to current page |

---

## Mapping Improvement Exercises

### Exercise 1: Map the Controls

Choose a screen in your product. Draw two sketches:
1. The layout of the controls (buttons, inputs, toggles).
2. The layout of the things they affect (content areas, settings, outputs).

Draw lines connecting each control to its effect. Ask:
- Do the lines cross? (If yes, the spatial mapping is poor.)
- Are the lines short? (Short lines = good proximity.)
- Does the spatial arrangement match? (Mirror layout = good spatial mapping.)

### Exercise 2: The Label Removal Test

Remove all labels from your interface mockup. Can a user still tell which control affects which element based on spatial position and proximity alone? Where the answer is no, the mapping depends on labels and could be improved with spatial redesign.

### Exercise 3: Sequential Task Walkthrough

List every step of a user task in chronological order. Now list the controls the user must interact with in the order they encounter them on screen. Do these two lists match? Where they diverge, the sequential mapping is broken.

### Exercise 4: Convention Audit

For each control-to-outcome mapping in your product, classify it as:
- **Spatial** (layout matches output)
- **Cultural** (follows a known convention)
- **Labeled** (arbitrary but clearly labeled)
- **Unlabeled arbitrary** (needs memorization)

Any "unlabeled arbitrary" mapping is a design failure. Convert it to spatial, cultural, or at minimum labeled.

# The Seven Stages of Action

Don Norman's Seven Stages of Action is a model of how humans interact with products. Every interaction, from flipping a light switch to completing an online checkout, follows the same seven-stage cycle. Understanding these stages lets designers identify exactly where users get stuck and apply targeted fixes. The model divides neatly into two sides: execution (stages 1-4, bridging the Gulf of Execution) and evaluation (stages 5-7, bridging the Gulf of Evaluation).


## Table of Contents
1. [The Seven Stages in Detail](#the-seven-stages-in-detail)
2. [Stage 1: Goal Formation](#stage-1-goal-formation)
3. [Stage 2: Plan Formation](#stage-2-plan-formation)
4. [Stage 3: Specification of Action](#stage-3-specification-of-action)
5. [Stage 4: Execution (Perform)](#stage-4-execution-perform)
6. [Stage 5: Perception](#stage-5-perception)
7. [Stage 6: Interpretation](#stage-6-interpretation)
8. [Stage 7: Comparison](#stage-7-comparison)
9. [Using the Seven Stages as an Evaluation Tool](#using-the-seven-stages-as-an-evaluation-tool)
10. [Worked Examples](#worked-examples)
11. [Seven Stages Audit Worksheet](#seven-stages-audit-worksheet)

---

## The Seven Stages in Detail

```
                        1. GOAL
                     "What do I want?"
                          |
              +-----------+-----------+
              |     EXECUTION         |     EVALUATION
              |                       |
         2. PLAN                 7. COMPARE
    "How can I do it?"      "Is this what I wanted?"
              |                       |
         3. SPECIFY              6. INTERPRET
    "What specific action?"  "What does this mean?"
              |                       |
         4. PERFORM              5. PERCEIVE
    "Do the action"          "What happened?"
              |                       |
              +--- THE WORLD / SYSTEM +
```

---

## Stage 1: Goal Formation

**Question the user asks**: "What do I want to accomplish?"

The user forms a high-level intention. Goals can be precise ("Set the alarm for 7:00 AM") or vague ("Make this presentation look better").

### Where Users Get Stuck

| Problem | Example | Design Cause |
|---------|---------|-------------|
| Goal is vague | "I want to fix this document" | The system does not help refine or clarify goals |
| Goal conflicts with system capabilities | "I want to merge these two accounts" (not supported) | Feature does not exist or is not discoverable |
| Goal is forgotten mid-task | User opens settings, forgets which setting they wanted | Complex navigation, many distractions |

### Design Solutions for Stage 1

| Solution | Implementation |
|----------|---------------|
| **Suggest goals** | Home screen with common tasks: "Create a document", "Schedule a meeting" |
| **Make capabilities visible** | Dashboard showing all available features at a glance |
| **Support vague goals** | Search that accepts natural language: "make text bigger" |
| **Maintain goal context** | Show breadcrumbs, page titles, and task descriptions that remind users why they are here |

---

## Stage 2: Plan Formation

**Question the user asks**: "How can I do this? What approach should I take?"

### Where Users Get Stuck

| Problem | Example | Design Cause |
|---------|---------|-------------|
| No obvious path | "How do I share this?" (no share button visible) | Missing signifiers, hidden features |
| Multiple possible paths, unclear which is correct | "Should I use Export, Save As, or Download?" | Overlapping features with unclear distinctions |
| Plan requires knowledge the user lacks | "I need to configure the API webhook" (what is a webhook?) | Technical jargon, no progressive disclosure |

### Design Solutions for Stage 2

| Solution | Implementation |
|----------|---------------|
| **Clear signifiers** | Visible labels for every available action |
| **Guided workflows** | Step-by-step wizards for complex tasks |
| **Reduce choices** | Offer the most common path prominently; hide alternatives |
| **Contextual help** | "How do I...?" link that opens task-specific guidance |
| **Templates and presets** | Pre-configured starting points that skip planning |

---

## Stage 3: Specification of Action

**Question the user asks**: "What specific action do I need to perform?"

### Where Users Get Stuck

| Problem | Example | Design Cause |
|---------|---------|-------------|
| Cannot find the control | "Where is the save button?" | Poor visual hierarchy, inconsistent placement |
| Cannot identify the correct control | "Is this the right dropdown?" | Ambiguous labels, icon-only controls |
| Action requires non-obvious sequence | "Click here, then hold Shift, then click there" | Complex interaction that is not signified |

### Design Solutions for Stage 3

| Solution | Implementation |
|----------|---------------|
| **Consistent placement** | Primary actions always in the same location across screens |
| **Clear labels** | Every control has a text label (not just an icon) |
| **Affordances** | Interactive elements look interactive (buttons look clickable) |
| **Keyboard shortcuts visible** | Show shortcut in tooltip or menu alongside the action name |
| **Command palette** | Searchable list of all actions for users who know what they want |

---

## Stage 4: Execution (Perform)

**Question the user asks**: "I'm doing it. Is this working?"

### Where Users Get Stuck

| Problem | Example | Design Cause |
|---------|---------|-------------|
| Click does not register | Tap target too small on mobile | Touch target below 44pt minimum |
| Action is physically difficult | Precise drag-and-drop on a touchscreen | Interaction not optimized for input device |
| Accidental action | Tapping the wrong button because targets overlap | Insufficient spacing between targets |
| Action is slow or tedious | Selecting 50 items one by one | No bulk selection or "Select All" option |

### Design Solutions for Stage 4

| Solution | Implementation |
|----------|---------------|
| **Adequate target sizes** | Minimum 44x44pt touch targets, 24x24px desktop |
| **Input optimization** | Match interaction to device (tap on mobile, click on desktop) |
| **Spacing** | Sufficient distance between interactive targets |
| **Shortcuts** | Bulk actions, keyboard shortcuts, gesture shortcuts |
| **Forgiveness** | Undo for accidental actions, confirmation for destructive ones |

---

## Stage 5: Perception

**Question the user asks**: "What happened? What changed?"

### Where Users Get Stuck

| Problem | Example | Design Cause |
|---------|---------|-------------|
| No visible change | Click a button and nothing happens | No feedback implemented |
| Change is too subtle | A small number changed in a corner of the screen | Low visual prominence of the feedback |
| Change is too fast | A toast message appeared and disappeared in 1 second | Insufficient display duration |
| Change is off-screen | The effect happened below the fold | No scroll-to or highlight behavior |

### Design Solutions for Stage 5

| Solution | Implementation |
|----------|---------------|
| **Immediate feedback** | Every action produces visible response within 100ms |
| **Prominent changes** | Use animation, color, and position to draw attention to what changed |
| **Sufficient duration** | Toast messages visible for 4-8 seconds with manual dismiss option |
| **Scroll to change** | Automatically scroll to or highlight the part of the interface that changed |
| **Multi-channel feedback** | Combine visual + auditory + haptic for important events |

---

## Stage 6: Interpretation

**Question the user asks**: "What does this mean?"

### Where Users Get Stuck

| Problem | Example | Design Cause |
|---------|---------|-------------|
| Feedback is ambiguous | A number changed from 3 to 4 but user does not know what it represents | Unclear labels or missing context |
| Feedback uses jargon | "Error: ECONNREFUSED" | Technical language not translated to human language |
| Feedback is misleading | Green checkmark appears but the action actually failed partially | Incorrect or premature success signal |
| Multiple changes at once | Several parts of the screen update simultaneously | No visual hierarchy to guide attention |

### Design Solutions for Stage 6

| Solution | Implementation |
|----------|---------------|
| **Plain language** | All feedback in human-readable terms with no jargon |
| **Context** | Include enough information to interpret the feedback ("3 items deleted" not just "Done") |
| **Accurate status** | Only show success when the action truly succeeded end-to-end |
| **Single focus** | Sequence changes or highlight the most important one |
| **Error explanations** | Describe what happened, why, and how to fix it |

---

## Stage 7: Comparison

**Question the user asks**: "Is this what I wanted? Did I achieve my goal?"

The user compares the interpreted result against their original goal from Stage 1.

### Where Users Get Stuck

| Problem | Example | Design Cause |
|---------|---------|-------------|
| Cannot confirm goal was achieved | "Did my email actually send?" | No explicit confirmation |
| Goal partially achieved | Three of four settings were saved but one failed silently | Partial success not communicated |
| Unexpected side effects | "I changed my username but now my old links are broken" | Consequences not explained before action |
| Cannot compare before and after | "Did the color actually change?" | No reference point for comparison |

### Design Solutions for Stage 7

| Solution | Implementation |
|----------|---------------|
| **Explicit confirmation** | "Your email has been sent to alice@example.com" |
| **Complete status reporting** | "3 of 4 settings saved. 'Display name' could not be updated because..." |
| **Consequence preview** | "Changing your username will break existing links. Continue?" |
| **Before/after comparison** | Toggle or side-by-side view showing previous and current state |
| **Summary screens** | After multi-step processes, show a summary of everything that was done |

---

## Using the Seven Stages as an Evaluation Tool

The Seven Stages of Action is one of the most practical evaluation tools available. For any user task, walk through each stage and ask: "What could go wrong here?"

### Walkthrough Template

For each task you want to evaluate, fill in this table.

| Stage | Question | Current Design Support | Gap / Problem | Severity (H/M/L) | Proposed Fix |
|:-----:|----------|----------------------|--------------|:-----------------:|-------------|
| 1. Goal | Can the user form a clear goal? | | | | |
| 2. Plan | Can the user figure out an approach? | | | | |
| 3. Specify | Can the user identify the right control? | | | | |
| 4. Perform | Can the user execute the action easily? | | | | |
| 5. Perceive | Can the user see what happened? | | | | |
| 6. Interpret | Can the user understand what it means? | | | | |
| 7. Compare | Can the user confirm the goal was achieved? | | | | |

Attempt the task as a new user. At each stage, note what supports and what hinders. Rate severity (H/M/L) and propose a fix.

---

## Worked Examples

### Example 1: Booking a Flight

| Stage | User Experience | Design Analysis |
|:-----:|----------------|-----------------|
| 1. Goal | "I want to fly from New York to London on March 15" | Goal is clear and specific |
| 2. Plan | "I'll search for flights on this booking site" | Plan is straightforward |
| 3. Specify | User must find origin, destination, date, and passenger fields | Fields are labeled and use autocomplete for cities: good |
| 4. Perform | User types "New York", selects from dropdown, picks date from calendar | Autocomplete and date picker reduce errors: good |
| 5. Perceive | Search results appear below | Results load with skeleton screens: good |
| 6. Interpret | User sees prices, times, airlines, and stops | Information is well-organized but "1 stop" does not say where or how long: gap |
| 7. Compare | User compares results to find the best option | Sort and filter available, but no "best value" indicator: minor gap |

**Key fixes**: Show layover details (city, duration) inline. Add a "Best value" tag for flights that balance price and convenience.

### Example 2: Using a Thermostat

| Stage | User Experience | Design Analysis |
|:-----:|----------------|-----------------|
| 1. Goal | "I want the room to be warmer" | Goal is vague: how much warmer? |
| 2. Plan | "I'll turn up the thermostat" | Simple plan |
| 3. Specify | User looks for the up arrow or dial | Control is visible: adequate |
| 4. Perform | User presses up repeatedly or turns dial to a high number | User sets to 85 hoping for faster heating: conceptual model failure |
| 5. Perceive | Display shows "85" | Number changed: perceived |
| 6. Interpret | User believes the house will now heat faster | Interpretation is wrong because the system image does not explain the on/off mechanism |
| 7. Compare | Room is not noticeably warmer after 5 minutes | User is frustrated, may turn it up further |

**Key fixes**: Show current temperature AND target. Show "Heating..." indicator. Show estimated time to reach target. Explain that the heating rate is constant regardless of the target setting.

### Example 3: Completing an E-Commerce Checkout

| Stage | User Experience | Design Analysis |
|:-----:|----------------|-----------------|
| 1. Goal | "I want to buy this item" | Clear goal |
| 2. Plan | "I'll go through checkout" | User expects a standard flow |
| 3. Specify | User must find "Checkout" or "Buy Now" button | Button is prominent and well-labeled: good |
| 4. Perform | User clicks the button | Proceeds to checkout: good |
| 5. Perceive | Checkout page loads with shipping, payment, and review sections | Clear step indicator "Step 1 of 3": good |
| 6. Interpret | User understands they must fill in shipping first | Labels are clear, fields are ordered logically: good |
| 7. Compare | After placing order, user sees confirmation with order number and expected delivery date | Explicit confirmation with all details: excellent |

**Key observation**: E-commerce checkout is one of the most optimized seven-stage flows because conversion directly impacts revenue.

---

## Seven Stages Audit Worksheet

Rate each stage 1-5 (1 = users consistently fail, 5 = zero friction).

| Stage | Rating (1-5) | What Works | What Fails | Priority Fix |
|:-----:|:------------:|-----------|-----------|-------------|
| 1. Goal | | | | |
| 2. Plan | | | | |
| 3. Specify | | | | |
| 4. Perform | | | | |
| 5. Perceive | | | | |
| 6. Interpret | | | | |
| 7. Compare | | | | |

### Summary

- **Weakest stage**: ___
- **Side with more issues**: Execution (stages 1-4) / Evaluation (stages 5-7)
- **Total issues found**: ___
- **Top 3 fixes by impact**:
  1. ___
  2. ___
  3. ___

### Follow-Up Actions

- [ ] Design and prototype fixes for top-priority issues
- [ ] Test with 3-5 users using a think-aloud protocol
- [ ] Re-score each stage after implementing fixes
- [ ] Track improvement in task completion rate and time

# Signifiers: Communicating Where and How to Act

Signifiers are perceivable cues that tell people where to act and how to act. While affordances define what actions are possible, signifiers are what users actually rely on to discover and use those affordances. A door handle affords pulling, but the "Pull" label is the signifier. A button affords clicking, but its raised shape and color are the signifiers. In practice, signifiers matter more than affordances because they are what users actually see.

## Signifier Types

### Deliberate Signifiers

Signals intentionally placed by the designer to communicate interaction possibilities.

| Signifier | What It Communicates | Context |
|-----------|---------------------|---------|
| "Push" / "Pull" label on a door | Direction of action | Physical product |
| Placeholder text in an input field | What data to enter | Web and mobile forms |
| Tooltip on hover | Purpose of a control | Desktop applications |
| Chevron icon on a dropdown | "This expands" | Any UI |
| Plus icon on a button | "Add new item" | Any UI |
| Breadcrumb trail | "You are here, and you came from there" | Web navigation |
| Step indicator (1 of 4) | "This is a sequence; you are at step 1" | Multi-step flows |

### Accidental Signifiers

Signals not designed intentionally but used by people to guide their behavior.

| Signifier | What It Communicates | Context |
|-----------|---------------------|---------|
| Worn path across a lawn | "People walk here" | Physical environment |
| Fingerprints on a touchscreen | "Touch this area" | Kiosks, shared tablets |
| Scratches around a keyhole | "The key goes here" | Physical locks |
| Browser back-button frequency | "Users get lost on this page" | Web analytics as accidental signifier for designers |
| Scroll position heatmaps | "Most people stop reading here" | Analytics informing design |

### Social Signifiers

Signals derived from observing other people's behavior.

| Signifier | What It Communicates | Context |
|-----------|---------------------|---------|
| A queue of people | "This is where you line up" | Physical spaces |
| Star ratings and review counts | "Other people chose this and rated it" | E-commerce, app stores |
| "1,204 people are viewing this" | "This is popular, act quickly" | Booking websites |
| Comment count on a post | "This sparked discussion" | Social media |
| "Trending" or "Popular" badges | "Many users are engaging with this" | Content platforms |
| Typing indicator in chat | "The other person is composing a response" | Messaging apps |

---

## Digital Signifier Catalog

### Cursor Changes

| Cursor | Signifier Meaning | CSS Value |
|--------|------------------|-----------|
| Arrow | Default, non-interactive area | `default` |
| Pointer (hand) | Clickable element | `pointer` |
| Text beam | Text is selectable or editable | `text` |
| Grab (open hand) | Element is draggable | `grab` |
| Grabbing (closed hand) | Element is being dragged | `grabbing` |
| Resize arrows | Edge or corner is resizable | `ew-resize`, `ns-resize`, `nwse-resize` |
| Wait / spinner | System is processing | `wait` |
| Not-allowed | Action is unavailable | `not-allowed` |
| Crosshair | Precision selection area | `crosshair` |

### Hover States

| Pattern | What It Signals | Best For |
|---------|----------------|----------|
| Background color change | "This entire area is interactive" | Cards, list items, table rows |
| Underline appearance | "This text is a link" | Inline text links |
| Shadow elevation increase | "This element lifts up when interactive" | Cards, buttons |
| Border color change | "This container responds to interaction" | Input fields, selection areas |
| Opacity change | "This element is interactive" | Icons, images, secondary actions |
| Scale transform (slight) | "This element is alive" | Thumbnails, avatar images |

### Placeholder Text and Labels

| Signifier Element | Purpose | Best Practice |
|------------------|---------|---------------|
| Field label | Identifies the field permanently | Always visible, above or beside the field |
| Placeholder text | Shows format or example | Disappears on focus; never replace a label with a placeholder |
| Helper text | Provides constraints or guidance | Below the field, always visible |
| Character counter | Shows remaining capacity | "23 / 280" for length-limited fields |
| Required indicator | Marks mandatory fields | Asterisk (*) or "(required)" text |

### Icons as Signifiers

| Icon | Universal Meaning | Potential Ambiguity |
|------|------------------|-------------------|
| Magnifying glass | Search | Could mean "zoom" in image contexts |
| Gear / cog | Settings | Could mean "processing" or "tools" |
| Pencil | Edit | Could mean "compose" or "draw" |
| Trash can | Delete | Clear vs. delete distinction may be unclear |
| Heart | Like / favorite | Could mean "health" in medical apps |
| Bell | Notifications | Could mean "alerts" or "alarms" |
| Share (arrow from box) | Share content | Platform-specific: different icons on iOS vs. Android |

**Rule**: When an icon's meaning is even slightly ambiguous, pair it with a text label.

### Color as Signifier

| Color | Common Signification | Caution |
|-------|---------------------|---------|
| Blue | Clickable / interactive / link | Must not be used for non-interactive text |
| Red | Error / danger / destructive action | Cultural variation: red means luck in China |
| Green | Success / safe / positive action | Do not rely on color alone (color blindness) |
| Yellow / amber | Warning / caution | Low contrast on white backgrounds |
| Gray | Disabled / inactive / secondary | Can also mean "subtle" rather than "disabled" |

### Position as Signifier

| Position | What It Signals | Convention |
|----------|----------------|------------|
| Top-left | Logo / home link | Almost universal on web |
| Top-right | User account, settings, cart | Strong web convention |
| Bottom of screen (mobile) | Primary navigation | iOS tab bar, Android bottom nav |
| Top-right of a card or modal | Close button | X icon in corner |
| Bottom-right of a form | Primary action button | "Submit", "Save", "Next" |
| Inline, right of content | Edit or action for that content | Pencil icon next to a heading |

---

## Signifier Hierarchy: When Multiple Signifiers Compete

When a screen contains many signifiers, they compete for attention. A hierarchy prevents visual overload and guides users to the most important actions first.

### Establishing Hierarchy

| Level | Treatment | Use For |
|-------|-----------|---------|
| **Primary** | Large, high-contrast, filled color, prominent position | The single most important action (e.g., "Buy Now") |
| **Secondary** | Medium size, outlined or muted color | Supporting actions (e.g., "Add to Wishlist") |
| **Tertiary** | Small, text-only or icon-only, low contrast | Minor actions (e.g., "Share", "Report") |
| **Ambient** | Subtle, always-present, low visual weight | Navigation, status indicators, breadcrumbs |

### Common Hierarchy Mistakes

- **Multiple primary buttons on one screen**: Users cannot tell which action matters most. Limit to one primary button per view.
- **Competing colors**: Using red, blue, green, and orange buttons on the same screen creates visual noise. Use one accent color for primary actions.
- **Equal-weight labels**: When every label is the same size and weight, nothing stands out and users scan randomly.

---

## Cultural Signifiers and Localization

Signifiers carry cultural meaning that does not always translate across regions.

| Signifier | Western Interpretation | Alternate Interpretation |
|-----------|----------------------|------------------------|
| Red color | Danger, error, stop | Luck, prosperity (East Asia) |
| Green color | Success, go, safe | Islam, nature (Middle East) |
| Thumbs up icon | Approval, "like" | Offensive in some Middle Eastern cultures |
| Checkmark | Correct, done | Can mean "incorrect" in Japan and Korea |
| Owl icon | Wisdom, knowledge | Bad luck, death omen (some Asian cultures) |
| Left-to-right arrow | Forward, next | Means "back" in RTL languages (Arabic, Hebrew) |

### Localization Checklist

- [ ] Review all icons for cultural sensitivity in target markets.
- [ ] Ensure directional signifiers (arrows, progress bars) adapt to RTL layouts.
- [ ] Do not rely solely on color to convey meaning.
- [ ] Test signifier comprehension with users from target cultures.
- [ ] Provide text labels alongside icons in localized versions.

---

## Over-Signifying vs. Under-Signifying

### Under-Signifying

Too few cues. Users cannot find features or realize elements are interactive. Symptoms: "What do I do here?", low discovery rates, support tickets for features that exist, clicks on non-interactive elements.

### Over-Signifying

Too many cues. Visual noise overwhelms users and nothing stands out. Symptoms: users feel overwhelmed, task completion time increases, interface described as "cluttered", primary actions missed.

### Finding the Balance

| Principle | Implementation |
|-----------|---------------|
| Signal-to-noise ratio | Every signifier should earn its place. Remove any that do not directly help users complete a task. |
| Progressive disclosure | Show essential signifiers first; reveal advanced ones on demand. |
| Consistent patterns | When users learn one signifier pattern, they apply it everywhere. Fewer unique patterns needed. |
| Whitespace as signifier | Empty space around an element signals importance. Let key elements breathe. |

---

## Signifier Design Patterns by Component Type

### Navigation

- Use text labels, not just icons, for primary navigation items.
- Highlight the current page or section with color, underline, or bold weight.
- Show the user's position in the hierarchy (breadcrumbs, highlighted nav item).
- Use a chevron or arrow to indicate dropdowns and expandable sections.

### Forms

- Label every field (above or to the left).
- Mark required fields with an asterisk and explain the convention.
- Show validation state inline (green check, red X) as the user fills in fields.
- Use helper text below fields for format requirements ("MM/DD/YYYY").
- Group related fields with visible section headers.

### Data Tables

- Make sortable columns obvious with a sort icon (arrows up/down).
- Show which column is currently sorted with a filled or highlighted icon.
- Use row hover states to signal that rows are interactive.
- Provide column header tooltips for abbreviated labels.

### Modals and Dialogs

- Always include a visible close button (X in top-right corner).
- Dim the background to signify the modal is the active layer.
- Label action buttons clearly ("Delete Account" not just "OK").
- Use a destructive color (red) for irreversible action buttons.

---

## Testing Signifier Effectiveness

### Five-Second Test

Show the interface to a user for exactly 5 seconds, then hide it. Ask:
1. What was this page about?
2. What could you do on this page?
3. What would you click first?

If users cannot answer these questions, signifiers are insufficient.

### First-Click Test

Give users a task and record where they click first. If fewer than 70% of users click the correct target on the first attempt, the signifier for that target is too weak.

### Think-Aloud Walkthrough

Ask users to complete a task while narrating their thought process. Listen for:
- "I'm not sure what to click."
- "Is this a button?"
- "What does this icon mean?"
- "I didn't notice that."

Each statement identifies a signifier failure.

---

## Signifier Audit Checklist

### Visibility

- [ ] Every interactive element has at least one visible signifier.
- [ ] Primary actions have the strongest visual signifiers (size, color, position).
- [ ] Secondary actions are visually subordinate to primary actions.
- [ ] System state is visible at all times (logged in, unsaved changes, current mode).

### Clarity

- [ ] Icons are paired with text labels (or tooltips at minimum).
- [ ] Color is not the sole signifier for any piece of information.
- [ ] Cursor changes are implemented for all interactive elements (desktop).
- [ ] Placeholder text does not replace labels.

### Consistency

- [ ] The same signifier pattern means the same thing everywhere in the product.
- [ ] Interactive elements are visually consistent (all buttons look like buttons).
- [ ] Position conventions are maintained (close in top-right, primary action in bottom-right).
- [ ] Color meanings are consistent (red always means error/danger, green always means success).

### Accessibility

- [ ] Signifiers work without color (underline, border, icon, or shape also used).
- [ ] Focus indicators are visible for keyboard navigation.
- [ ] Screen reader users receive equivalent signifier information via ARIA labels and roles.
- [ ] Animation-based signifiers have non-animated alternatives.

---

## Before/After Examples

### Example 1: Unlabeled Icon Toolbar

**Before**: A toolbar with 8 monochrome icons and no text. New users hover over each icon one by one to discover tooltips. Many icons are ambiguous (what does the diamond icon do?).

**After**: Each icon has a small text label beneath it. The most-used 5 icons are always visible; 3 less-used icons are grouped under a "More" menu. Users find features 3x faster.

### Example 2: Invisible Toggle

**Before**: A settings page lists options with a small circular dot next to each. The dot is the toggle, but it looks like a bullet point. Users do not know the settings are changeable.

**After**: Each option has a standard toggle switch (track with a sliding circle) using green/gray color states. Users immediately understand they can turn options on and off.

### Example 3: Mystery Status Indicator

**Before**: A colored circle in the header changes from green to yellow to red. No legend or tooltip explains what the colors mean. Users speculate about its meaning.

**After**: The circle is replaced with a text badge: "All Systems Operational" (green), "Degraded Performance" (yellow), "Outage Detected" (red). The meaning is immediately clear.

# The Two Gulfs: Execution and Evaluation

Every human-product interaction involves crossing two psychological chasms. The Gulf of Execution separates what the user wants to do from the actions the product requires. The Gulf of Evaluation separates what the product did from the user's understanding of what happened. Narrowing these gulfs is the central challenge of interaction design.

## Gulf of Execution: The Gap Between Intent and Action

The Gulf of Execution exists whenever a user has a goal but cannot figure out how to achieve it. The wider the gulf, the more effort users must expend translating their intentions into physical actions.

### What Makes the Gulf Wide

| Factor | Description | Example |
|--------|-------------|---------|
| Hidden controls | Actions exist but users cannot find them | Swipe gestures with no visual indicator |
| Unfamiliar vocabulary | Labels use jargon or internal terminology | "Reconcile ledger" instead of "Match payments" |
| Non-obvious sequences | Multiple steps required with no guidance | Configuring a router through 7 unlabeled screens |
| Mismatched mappings | Controls don't correspond to outcomes | A row of identical switches controlling different zones |
| Missing affordances | Interactive elements look static | A clickable text block with no hover state, underline, or color |

### What Narrows the Gulf

| Strategy | How It Works | Example |
|----------|-------------|---------|
| Clear signifiers | Visual cues reveal available actions | Placeholder text reading "Search by name or email..." |
| Natural mappings | Controls spatially match outputs | Volume slider oriented vertically, up means louder |
| Constraints | Only valid actions are possible | Date picker prevents invalid date entry |
| Familiar patterns | Use conventions users already know | Shopping cart icon in the top-right corner |
| Progressive disclosure | Show relevant options at the right time | Payment fields appear only after "Checkout" is clicked |

### Gulf of Execution in Web Applications

Web apps frequently widen the Gulf of Execution by burying functionality. Common offenders:

- **Hamburger menus on desktop**: Users cannot see what actions are available without clicking an icon that many people do not recognize.
- **Icon-only toolbars**: Without labels, users must guess what each icon does. A floppy disk icon means "save" only to users who have seen floppy disks.
- **Right-click dependent actions**: Any action that requires right-clicking is invisible to most users.
- **Keyboard-shortcut-only features**: Power users love them, but they are undiscoverable without signifiers.

### Gulf of Execution in Mobile Apps

- **Gesture-only navigation**: Swipe-to-delete, pull-to-refresh, and pinch-to-zoom all have wide execution gulfs for new users.
- **Hidden bottom sheets**: Content tucked behind a drag handle that looks decorative.
- **Long-press menus**: No visual indicator that holding down on an element reveals additional options.

### Gulf of Execution in Physical Products

- **Flat push-plates on doors that need to be pulled**: The plate affords pushing, but the door requires pulling.
- **Stove knobs in a row**: Four knobs in a line controlling burners in a 2x2 grid. Users cannot tell which knob maps to which burner.
- **Shower controls with unmarked handles**: Hot, cold, and diverter valves with no labels or color coding.

---

## Gulf of Evaluation: The Gap Between System State and Understanding

The Gulf of Evaluation exists whenever a user has performed an action but cannot determine what happened, whether it worked, or what state the system is now in.

### What Makes the Gulf Wide

| Factor | Description | Example |
|--------|-------------|---------|
| No feedback | Action produces no visible response | Clicking a button with no loading indicator or confirmation |
| Delayed feedback | Response comes seconds or minutes later | Email sent with no confirmation; user wonders if it went |
| Ambiguous feedback | Something changed but meaning is unclear | A number changed from 3 to 4 with no explanation |
| Hidden state | System state is not visible | Background sync happening with no indicator |
| Technical error messages | Error text is not human-readable | "Error 0x80070005: Access denied" |

### What Narrows the Gulf

| Strategy | How It Works | Example |
|----------|-------------|---------|
| Immediate feedback | Visual response within 100ms | Button depresses and changes color on click |
| State indicators | Persistent display of current state | "Draft" / "Published" badge on documents |
| Progress communication | Show advancement toward goal | "Step 3 of 5" with a progress bar |
| Clear error messages | Explain what happened and how to fix it | "That email is already registered. Try logging in instead." |
| Meaningful transitions | Animations that explain change | A deleted item sliding off-screen to the trash |

### Gulf of Evaluation in Web Applications

- **Silent saves**: Auto-save is excellent, but without a "Saved" indicator, users repeatedly click save.
- **Pagination with no count**: Users cannot tell how much content exists or where they are in the set.
- **Background processing**: File uploads, exports, or calculations with no progress indicator.
- **Form submission without redirect or toast**: Users click "Submit" and nothing visibly changes.

### Gulf of Evaluation in Kiosks and Public Terminals

- **Airport check-in kiosks**: Users scan their passport but receive no confirmation for 3-5 seconds. Many scan again, causing errors.
- **Parking meters**: Payment accepted but the display returns to the default screen before the user reads the confirmation.
- **Self-checkout machines**: Weight sensor errors display cryptic messages, and the machine locks until an attendant arrives.

---

## Gulf Analysis Exercise Template

Use this template to analyze any interface by examining both gulfs for a specific user task.

### Step 1: Define the Task

| Field | Entry |
|-------|-------|
| **Product / Interface** | |
| **User goal** | |
| **Target user profile** | |
| **Context of use** | |

### Step 2: Analyze the Gulf of Execution

| Question | Assessment (1-5) | Notes |
|----------|:-----------------:|-------|
| Can the user identify what actions are available? | | |
| Are the correct controls visible and discoverable? | | |
| Do the controls use familiar patterns and vocabulary? | | |
| Is the mapping between controls and outcomes clear? | | |
| Are impossible or irrelevant actions constrained? | | |
| Is the required sequence of steps obvious? | | |
| **Execution Gulf Score (average)** | | |

### Step 3: Analyze the Gulf of Evaluation

| Question | Assessment (1-5) | Notes |
|----------|:-----------------:|-------|
| Does the system provide immediate feedback on actions? | | |
| Can the user determine the current system state? | | |
| Is the feedback informative and understandable? | | |
| Are error states clearly communicated with recovery steps? | | |
| Can the user confirm the goal was achieved? | | |
| Are transitions and state changes visible? | | |
| **Evaluation Gulf Score (average)** | | |

### Step 4: Identify Improvements

| Gulf | Problem Found | Severity (H/M/L) | Proposed Fix |
|------|--------------|:-----------------:|-------------|
| Execution | | | |
| Execution | | | |
| Evaluation | | | |
| Evaluation | | | |

---

## Measuring Gulf Width: A Heuristic Evaluation Approach

Gulf width is not a single number. It varies by user expertise, context, and task. Use these heuristics to estimate relative width.

### Execution Gulf Width Indicators

| Width | Characteristics |
|-------|----------------|
| **Narrow** | User completes the action on first attempt without hesitation. Controls are visible, labeled, and follow conventions. |
| **Medium** | User pauses, scans the interface, then finds the correct action. Minor exploration required. |
| **Wide** | User tries incorrect actions before finding the right one, or gives up and seeks help. |
| **Very wide** | User cannot complete the task without external instruction (manual, tutorial, another person). |

### Evaluation Gulf Width Indicators

| Width | Characteristics |
|-------|----------------|
| **Narrow** | User immediately understands what happened and confirms the result. No uncertainty. |
| **Medium** | User notices a change but takes a moment to interpret it. Brief confusion, then clarity. |
| **Wide** | User is unsure whether the action succeeded. May repeat the action or navigate away to verify. |
| **Very wide** | User has no idea what the system did. Cannot determine current state. Abandons or calls support. |

---

## Design Patterns That Widen Each Gulf

### Patterns That Widen the Execution Gulf

- **Mystery meat navigation**: Links or icons with no labels that reveal their purpose only on hover or click.
- **Modes without indicators**: The interface behaves differently depending on an invisible mode (edit mode vs. view mode with no visual distinction).
- **Nested menus beyond two levels**: Users must remember a path through multiple levels to reach a function.
- **Inconsistent action locations**: "Save" is in the toolbar on one screen, in the footer on another, and in a menu on a third.
- **Custom scrollbars that hide**: Disappearing scrollbars on content that is not obviously scrollable.

### Patterns That Widen the Evaluation Gulf

- **Toasts that disappear too quickly**: Success or error messages that vanish in under 2 seconds before users read them.
- **Silent failures**: An action fails but the interface shows no error, giving the impression of success.
- **Optimistic UI without correction**: The interface shows success immediately but never corrects if the server rejects the action.
- **Identical states**: A toggle switch where "on" and "off" look nearly the same.
- **Aggregate indicators**: A single status badge that combines multiple states (e.g., "3 issues" with no breakdown).

---

## Patterns That Narrow Each Gulf

### Patterns That Narrow the Execution Gulf

- **Visible toolbars with text labels**: Every action is one click away with a clear label.
- **Contextual actions**: Relevant actions appear near the content they affect (inline edit buttons, contextual menus on selection).
- **Command palettes**: A searchable list of all available actions, bridging the gap for users who know what they want but not where it is.
- **Onboarding spotlights**: First-time highlights that point out key controls.
- **Consistent layout grids**: Users learn where to look for actions because they are always in the same place.

### Patterns That Narrow the Evaluation Gulf

- **Persistent status bars**: Always-visible indicators of system state (connection status, save status, user role).
- **Inline validation**: Real-time feedback on form fields as the user types.
- **Undo toasts with timers**: "Message sent. Undo (5s)" gives confirmation and a recovery window simultaneously.
- **State-change animations**: Smooth transitions that show how the old state became the new state.
- **Confirmation screens**: A summary of what was just done with the option to modify.

---

## Worksheet: Analyze Any Interface Through the Two Gulfs

Use this quick-reference worksheet for a 15-minute audit of any product or feature.

### Instructions

1. Choose a specific task the user wants to accomplish.
2. Attempt the task yourself as if you were a new user.
3. At each moment of hesitation, note which gulf is too wide.
4. Fill in the table below.

| Step | What I Wanted to Do | What I Actually Did | Gulf Issue (Execution / Evaluation) | Severity | Fix |
|:----:|---------------------|--------------------|------------------------------------|:--------:|-----|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
| 4 | | | | | |
| 5 | | | | | |

### Summary

- **Total execution issues found**: ___
- **Total evaluation issues found**: ___
- **Widest gulf moment**: ___
- **Highest-priority fix**: ___
- **Overall gulf assessment**: The [execution / evaluation] gulf is the bigger problem for this task.

### Follow-Up Actions

- [ ] Prioritize fixes by severity
- [ ] Sketch improved designs for the widest gulf moments
- [ ] Test improved designs with 3-5 users
- [ ] Re-evaluate gulf width after changes