| 1 | # The Seven Stages of Action |
| 2 | |
| 3 | 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). |
| 4 | |
| 5 | |
| 6 | ## Table of Contents |
| 7 | 1. [The Seven Stages in Detail](#the-seven-stages-in-detail) |
| 8 | 2. [Stage 1: Goal Formation](#stage-1-goal-formation) |
| 9 | 3. [Stage 2: Plan Formation](#stage-2-plan-formation) |
| 10 | 4. [Stage 3: Specification of Action](#stage-3-specification-of-action) |
| 11 | 5. [Stage 4: Execution (Perform)](#stage-4-execution-perform) |
| 12 | 6. [Stage 5: Perception](#stage-5-perception) |
| 13 | 7. [Stage 6: Interpretation](#stage-6-interpretation) |
| 14 | 8. [Stage 7: Comparison](#stage-7-comparison) |
| 15 | 9. [Using the Seven Stages as an Evaluation Tool](#using-the-seven-stages-as-an-evaluation-tool) |
| 16 | 10. [Worked Examples](#worked-examples) |
| 17 | 11. [Seven Stages Audit Worksheet](#seven-stages-audit-worksheet) |
| 18 | |
| 19 | --- |
| 20 | |
| 21 | ## The Seven Stages in Detail |
| 22 | |
| 23 | ``` |
| 24 | 1. GOAL |
| 25 | "What do I want?" |
| 26 | | |
| 27 | +-----------+-----------+ |
| 28 | | EXECUTION | EVALUATION |
| 29 | | | |
| 30 | 2. PLAN 7. COMPARE |
| 31 | "How can I do it?" "Is this what I wanted?" |
| 32 | | | |
| 33 | 3. SPECIFY 6. INTERPRET |
| 34 | "What specific action?" "What does this mean?" |
| 35 | | | |
| 36 | 4. PERFORM 5. PERCEIVE |
| 37 | "Do the action" "What happened?" |
| 38 | | | |
| 39 | +--- THE WORLD / SYSTEM + |
| 40 | ``` |
| 41 | |
| 42 | --- |
| 43 | |
| 44 | ## Stage 1: Goal Formation |
| 45 | |
| 46 | **Question the user asks**: "What do I want to accomplish?" |
| 47 | |
| 48 | 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"). |
| 49 | |
| 50 | ### Where Users Get Stuck |
| 51 | |
| 52 | | Problem | Example | Design Cause | |
| 53 | |---------|---------|-------------| |
| 54 | | Goal is vague | "I want to fix this document" | The system does not help refine or clarify goals | |
| 55 | | Goal conflicts with system capabilities | "I want to merge these two accounts" (not supported) | Feature does not exist or is not discoverable | |
| 56 | | Goal is forgotten mid-task | User opens settings, forgets which setting they wanted | Complex navigation, many distractions | |
| 57 | |
| 58 | ### Design Solutions for Stage 1 |
| 59 | |
| 60 | | Solution | Implementation | |
| 61 | |----------|---------------| |
| 62 | | **Suggest goals** | Home screen with common tasks: "Create a document", "Schedule a meeting" | |
| 63 | | **Make capabilities visible** | Dashboard showing all available features at a glance | |
| 64 | | **Support vague goals** | Search that accepts natural language: "make text bigger" | |
| 65 | | **Maintain goal context** | Show breadcrumbs, page titles, and task descriptions that remind users why they are here | |
| 66 | |
| 67 | --- |
| 68 | |
| 69 | ## Stage 2: Plan Formation |
| 70 | |
| 71 | **Question the user asks**: "How can I do this? What approach should I take?" |
| 72 | |
| 73 | ### Where Users Get Stuck |
| 74 | |
| 75 | | Problem | Example | Design Cause | |
| 76 | |---------|---------|-------------| |
| 77 | | No obvious path | "How do I share this?" (no share button visible) | Missing signifiers, hidden features | |
| 78 | | Multiple possible paths, unclear which is correct | "Should I use Export, Save As, or Download?" | Overlapping features with unclear distinctions | |
| 79 | | Plan requires knowledge the user lacks | "I need to configure the API webhook" (what is a webhook?) | Technical jargon, no progressive disclosure | |
| 80 | |
| 81 | ### Design Solutions for Stage 2 |
| 82 | |
| 83 | | Solution | Implementation | |
| 84 | |----------|---------------| |
| 85 | | **Clear signifiers** | Visible labels for every available action | |
| 86 | | **Guided workflows** | Step-by-step wizards for complex tasks | |
| 87 | | **Reduce choices** | Offer the most common path prominently; hide alternatives | |
| 88 | | **Contextual help** | "How do I...?" link that opens task-specific guidance | |
| 89 | | **Templates and presets** | Pre-configured starting points that skip planning | |
| 90 | |
| 91 | --- |
| 92 | |
| 93 | ## Stage 3: Specification of Action |
| 94 | |
| 95 | **Question the user asks**: "What specific action do I need to perform?" |
| 96 | |
| 97 | ### Where Users Get Stuck |
| 98 | |
| 99 | | Problem | Example | Design Cause | |
| 100 | |---------|---------|-------------| |
| 101 | | Cannot find the control | "Where is the save button?" | Poor visual hierarchy, inconsistent placement | |
| 102 | | Cannot identify the correct control | "Is this the right dropdown?" | Ambiguous labels, icon-only controls | |
| 103 | | Action requires non-obvious sequence | "Click here, then hold Shift, then click there" | Complex interaction that is not signified | |
| 104 | |
| 105 | ### Design Solutions for Stage 3 |
| 106 | |
| 107 | | Solution | Implementation | |
| 108 | |----------|---------------| |
| 109 | | **Consistent placement** | Primary actions always in the same location across screens | |
| 110 | | **Clear labels** | Every control has a text label (not just an icon) | |
| 111 | | **Affordances** | Interactive elements look interactive (buttons look clickable) | |
| 112 | | **Keyboard shortcuts visible** | Show shortcut in tooltip or menu alongside the action name | |
| 113 | | **Command palette** | Searchable list of all actions for users who know what they want | |
| 114 | |
| 115 | --- |
| 116 | |
| 117 | ## Stage 4: Execution (Perform) |
| 118 | |
| 119 | **Question the user asks**: "I'm doing it. Is this working?" |
| 120 | |
| 121 | ### Where Users Get Stuck |
| 122 | |
| 123 | | Problem | Example | Design Cause | |
| 124 | |---------|---------|-------------| |
| 125 | | Click does not register | Tap target too small on mobile | Touch target below 44pt minimum | |
| 126 | | Action is physically difficult | Precise drag-and-drop on a touchscreen | Interaction not optimized for input device | |
| 127 | | Accidental action | Tapping the wrong button because targets overlap | Insufficient spacing between targets | |
| 128 | | Action is slow or tedious | Selecting 50 items one by one | No bulk selection or "Select All" option | |
| 129 | |
| 130 | ### Design Solutions for Stage 4 |
| 131 | |
| 132 | | Solution | Implementation | |
| 133 | |----------|---------------| |
| 134 | | **Adequate target sizes** | Minimum 44x44pt touch targets, 24x24px desktop | |
| 135 | | **Input optimization** | Match interaction to device (tap on mobile, click on desktop) | |
| 136 | | **Spacing** | Sufficient distance between interactive targets | |
| 137 | | **Shortcuts** | Bulk actions, keyboard shortcuts, gesture shortcuts | |
| 138 | | **Forgiveness** | Undo for accidental actions, confirmation for destructive ones | |
| 139 | |
| 140 | --- |
| 141 | |
| 142 | ## Stage 5: Perception |
| 143 | |
| 144 | **Question the user asks**: "What happened? What changed?" |
| 145 | |
| 146 | ### Where Users Get Stuck |
| 147 | |
| 148 | | Problem | Example | Design Cause | |
| 149 | |---------|---------|-------------| |
| 150 | | No visible change | Click a button and nothing happens | No feedback implemented | |
| 151 | | Change is too subtle | A small number changed in a corner of the screen | Low visual prominence of the feedback | |
| 152 | | Change is too fast | A toast message appeared and disappeared in 1 second | Insufficient display duration | |
| 153 | | Change is off-screen | The effect happened below the fold | No scroll-to or highlight behavior | |
| 154 | |
| 155 | ### Design Solutions for Stage 5 |
| 156 | |
| 157 | | Solution | Implementation | |
| 158 | |----------|---------------| |
| 159 | | **Immediate feedback** | Every action produces visible response within 100ms | |
| 160 | | **Prominent changes** | Use animation, color, and position to draw attention to what changed | |
| 161 | | **Sufficient duration** | Toast messages visible for 4-8 seconds with manual dismiss option | |
| 162 | | **Scroll to change** | Automatically scroll to or highlight the part of the interface that changed | |
| 163 | | **Multi-channel feedback** | Combine visual + auditory + haptic for important events | |
| 164 | |
| 165 | --- |
| 166 | |
| 167 | ## Stage 6: Interpretation |
| 168 | |
| 169 | **Question the user asks**: "What does this mean?" |
| 170 | |
| 171 | ### Where Users Get Stuck |
| 172 | |
| 173 | | Problem | Example | Design Cause | |
| 174 | |---------|---------|-------------| |
| 175 | | Feedback is ambiguous | A number changed from 3 to 4 but user does not know what it represents | Unclear labels or missing context | |
| 176 | | Feedback uses jargon | "Error: ECONNREFUSED" | Technical language not translated to human language | |
| 177 | | Feedback is misleading | Green checkmark appears but the action actually failed partially | Incorrect or premature success signal | |
| 178 | | Multiple changes at once | Several parts of the screen update simultaneously | No visual hierarchy to guide attention | |
| 179 | |
| 180 | ### Design Solutions for Stage 6 |
| 181 | |
| 182 | | Solution | Implementation | |
| 183 | |----------|---------------| |
| 184 | | **Plain language** | All feedback in human-readable terms with no jargon | |
| 185 | | **Context** | Include enough information to interpret the feedback ("3 items deleted" not just "Done") | |
| 186 | | **Accurate status** | Only show success when the action truly succeeded end-to-end | |
| 187 | | **Single focus** | Sequence changes or highlight the most important one | |
| 188 | | **Error explanations** | Describe what happened, why, and how to fix it | |
| 189 | |
| 190 | --- |
| 191 | |
| 192 | ## Stage 7: Comparison |
| 193 | |
| 194 | **Question the user asks**: "Is this what I wanted? Did I achieve my goal?" |
| 195 | |
| 196 | The user compares the interpreted result against their original goal from Stage 1. |
| 197 | |
| 198 | ### Where Users Get Stuck |
| 199 | |
| 200 | | Problem | Example | Design Cause | |
| 201 | |---------|---------|-------------| |
| 202 | | Cannot confirm goal was achieved | "Did my email actually send?" | No explicit confirmation | |
| 203 | | Goal partially achieved | Three of four settings were saved but one failed silently | Partial success not communicated | |
| 204 | | Unexpected side effects | "I changed my username but now my old links are broken" | Consequences not explained before action | |
| 205 | | Cannot compare before and after | "Did the color actually change?" | No reference point for comparison | |
| 206 | |
| 207 | ### Design Solutions for Stage 7 |
| 208 | |
| 209 | | Solution | Implementation | |
| 210 | |----------|---------------| |
| 211 | | **Explicit confirmation** | "Your email has been sent to [email protected]" | |
| 212 | | **Complete status reporting** | "3 of 4 settings saved. 'Display name' could not be updated because..." | |
| 213 | | **Consequence preview** | "Changing your username will break existing links. Continue?" | |
| 214 | | **Before/after comparison** | Toggle or side-by-side view showing previous and current state | |
| 215 | | **Summary screens** | After multi-step processes, show a summary of everything that was done | |
| 216 | |
| 217 | --- |
| 218 | |
| 219 | ## Using the Seven Stages as an Evaluation Tool |
| 220 | |
| 221 | 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?" |
| 222 | |
| 223 | ### Walkthrough Template |
| 224 | |
| 225 | For each task you want to evaluate, fill in this table. |
| 226 | |
| 227 | | Stage | Question | Current Design Support | Gap / Problem | Severity (H/M/L) | Proposed Fix | |
| 228 | |:-----:|----------|----------------------|--------------|:-----------------:|-------------| |
| 229 | | 1. Goal | Can the user form a clear goal? | | | | | |
| 230 | | 2. Plan | Can the user figure out an approach? | | | | | |
| 231 | | 3. Specify | Can the user identify the right control? | | | | | |
| 232 | | 4. Perform | Can the user execute the action easily? | | | | | |
| 233 | | 5. Perceive | Can the user see what happened? | | | | | |
| 234 | | 6. Interpret | Can the user understand what it means? | | | | | |
| 235 | | 7. Compare | Can the user confirm the goal was achieved? | | | | | |
| 236 | |
| 237 | 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. |
| 238 | |
| 239 | --- |
| 240 | |
| 241 | ## Worked Examples |
| 242 | |
| 243 | ### Example 1: Booking a Flight |
| 244 | |
| 245 | | Stage | User Experience | Design Analysis | |
| 246 | |:-----:|----------------|-----------------| |
| 247 | | 1. Goal | "I want to fly from New York to London on March 15" | Goal is clear and specific | |
| 248 | | 2. Plan | "I'll search for flights on this booking site" | Plan is straightforward | |
| 249 | | 3. Specify | User must find origin, destination, date, and passenger fields | Fields are labeled and use autocomplete for cities: good | |
| 250 | | 4. Perform | User types "New York", selects from dropdown, picks date from calendar | Autocomplete and date picker reduce errors: good | |
| 251 | | 5. Perceive | Search results appear below | Results load with skeleton screens: good | |
| 252 | | 6. Interpret | User sees prices, times, airlines, and stops | Information is well-organized but "1 stop" does not say where or how long: gap | |
| 253 | | 7. Compare | User compares results to find the best option | Sort and filter available, but no "best value" indicator: minor gap | |
| 254 | |
| 255 | **Key fixes**: Show layover details (city, duration) inline. Add a "Best value" tag for flights that balance price and convenience. |
| 256 | |
| 257 | ### Example 2: Using a Thermostat |
| 258 | |
| 259 | | Stage | User Experience | Design Analysis | |
| 260 | |:-----:|----------------|-----------------| |
| 261 | | 1. Goal | "I want the room to be warmer" | Goal is vague: how much warmer? | |
| 262 | | 2. Plan | "I'll turn up the thermostat" | Simple plan | |
| 263 | | 3. Specify | User looks for the up arrow or dial | Control is visible: adequate | |
| 264 | | 4. Perform | User presses up repeatedly or turns dial to a high number | User sets to 85 hoping for faster heating: conceptual model failure | |
| 265 | | 5. Perceive | Display shows "85" | Number changed: perceived | |
| 266 | | 6. Interpret | User believes the house will now heat faster | Interpretation is wrong because the system image does not explain the on/off mechanism | |
| 267 | | 7. Compare | Room is not noticeably warmer after 5 minutes | User is frustrated, may turn it up further | |
| 268 | |
| 269 | **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. |
| 270 | |
| 271 | ### Example 3: Completing an E-Commerce Checkout |
| 272 | |
| 273 | | Stage | User Experience | Design Analysis | |
| 274 | |:-----:|----------------|-----------------| |
| 275 | | 1. Goal | "I want to buy this item" | Clear goal | |
| 276 | | 2. Plan | "I'll go through checkout" | User expects a standard flow | |
| 277 | | 3. Specify | User must find "Checkout" or "Buy Now" button | Button is prominent and well-labeled: good | |
| 278 | | 4. Perform | User clicks the button | Proceeds to checkout: good | |
| 279 | | 5. Perceive | Checkout page loads with shipping, payment, and review sections | Clear step indicator "Step 1 of 3": good | |
| 280 | | 6. Interpret | User understands they must fill in shipping first | Labels are clear, fields are ordered logically: good | |
| 281 | | 7. Compare | After placing order, user sees confirmation with order number and expected delivery date | Explicit confirmation with all details: excellent | |
| 282 | |
| 283 | **Key observation**: E-commerce checkout is one of the most optimized seven-stage flows because conversion directly impacts revenue. |
| 284 | |
| 285 | --- |
| 286 | |
| 287 | ## Seven Stages Audit Worksheet |
| 288 | |
| 289 | Rate each stage 1-5 (1 = users consistently fail, 5 = zero friction). |
| 290 | |
| 291 | | Stage | Rating (1-5) | What Works | What Fails | Priority Fix | |
| 292 | |:-----:|:------------:|-----------|-----------|-------------| |
| 293 | | 1. Goal | | | | | |
| 294 | | 2. Plan | | | | | |
| 295 | | 3. Specify | | | | | |
| 296 | | 4. Perform | | | | | |
| 297 | | 5. Perceive | | | | | |
| 298 | | 6. Interpret | | | | | |
| 299 | | 7. Compare | | | | | |
| 300 | |
| 301 | ### Summary |
| 302 | |
| 303 | - **Weakest stage**: ___ |
| 304 | - **Side with more issues**: Execution (stages 1-4) / Evaluation (stages 5-7) |
| 305 | - **Total issues found**: ___ |
| 306 | - **Top 3 fixes by impact**: |
| 307 | 1. ___ |
| 308 | 2. ___ |
| 309 | 3. ___ |
| 310 | |
| 311 | ### Follow-Up Actions |
| 312 | |
| 313 | - [ ] Design and prototype fixes for top-priority issues |
| 314 | - [ ] Test with 3-5 users using a think-aloud protocol |
| 315 | - [ ] Re-score each stage after implementing fixes |
| 316 | - [ ] Track improvement in task completion rate and time |
| 317 | |