1# Persona-Based Design Testing
  2
  3Test the interface through the eyes of 5 distinct user archetypes. Each persona exposes different failure modes that a single "design director" perspective would miss.
  4
  5**How to use**: Select 2–3 personas most relevant to the interface being critiqued. Walk through the primary user action as each persona. Report specific red flags — not generic concerns.
  6
  7---
  8
  9## 1. Impatient Power User — "Alex"
 10
 11**Profile**: Expert with similar products. Expects efficiency, hates hand-holding. Will find shortcuts or leave.
 12
 13**Behaviors**:
 14- Skips all onboarding and instructions
 15- Looks for keyboard shortcuts immediately
 16- Tries to bulk-select, batch-edit, and automate
 17- Gets frustrated by required steps that feel unnecessary
 18- Abandons if anything feels slow or patronizing
 19
 20**Test Questions**:
 21- Can Alex complete the core task in under 60 seconds?
 22- Are there keyboard shortcuts for common actions?
 23- Can onboarding be skipped entirely?
 24- Do modals have keyboard dismiss (Esc)?
 25- Is there a "power user" path (shortcuts, bulk actions)?
 26
 27**Red Flags** (report these specifically):
 28- Forced tutorials or unskippable onboarding
 29- No keyboard navigation for primary actions
 30- Slow animations that can't be skipped
 31- One-item-at-a-time workflows where batch would be natural
 32- Redundant confirmation steps for low-risk actions
 33
 34---
 35
 36## 2. Confused First-Timer — "Jordan"
 37
 38**Profile**: Never used this type of product. Needs guidance at every step. Will abandon rather than figure it out.
 39
 40**Behaviors**:
 41- Reads all instructions carefully
 42- Hesitates before clicking anything unfamiliar
 43- Looks for help or support constantly
 44- Misunderstands jargon and abbreviations
 45- Takes the most literal interpretation of any label
 46
 47**Test Questions**:
 48- Is the first action obviously clear within 5 seconds?
 49- Are all icons labeled with text?
 50- Is there contextual help at decision points?
 51- Does terminology assume prior knowledge?
 52- Is there a clear "back" or "undo" at every step?
 53
 54**Red Flags** (report these specifically):
 55- Icon-only navigation with no labels
 56- Technical jargon without explanation
 57- No visible help option or guidance
 58- Ambiguous next steps after completing an action
 59- No confirmation that an action succeeded
 60
 61---
 62
 63## 3. Accessibility-Dependent User — "Sam"
 64
 65**Profile**: Uses screen reader (VoiceOver/NVDA), keyboard-only navigation. May have low vision, motor impairment, or cognitive differences.
 66
 67**Behaviors**:
 68- Tabs through the interface linearly
 69- Relies on ARIA labels and heading structure
 70- Cannot see hover states or visual-only indicators
 71- Needs adequate color contrast (4.5:1 minimum)
 72- May use browser zoom up to 200%
 73
 74**Test Questions**:
 75- Can the entire primary flow be completed keyboard-only?
 76- Are all interactive elements focusable with visible focus indicators?
 77- Do images have meaningful alt text?
 78- Is color contrast WCAG AA compliant (4.5:1 for text)?
 79- Does the screen reader announce state changes (loading, success, errors)?
 80
 81**Red Flags** (report these specifically):
 82- Click-only interactions with no keyboard alternative
 83- Missing or invisible focus indicators
 84- Meaning conveyed by color alone (red = error, green = success)
 85- Unlabeled form fields or buttons
 86- Time-limited actions without extension option
 87- Custom components that break screen reader flow
 88
 89---
 90
 91## 4. Deliberate Stress Tester — "Riley"
 92
 93**Profile**: Methodical user who pushes interfaces beyond the happy path. Tests edge cases, tries unexpected inputs, and probes for gaps in the experience.
 94
 95**Behaviors**:
 96- Tests edge cases intentionally (empty states, long strings, special characters)
 97- Submits forms with unexpected data (emoji, RTL text, very long values)
 98- Tries to break workflows by navigating backwards, refreshing mid-flow, or opening in multiple tabs
 99- Looks for inconsistencies between what the UI promises and what actually happens
100- Documents problems methodically
101
102**Test Questions**:
103- What happens at the edges (0 items, 1000 items, very long text)?
104- Do error states recover gracefully or leave the UI in a broken state?
105- What happens on refresh mid-workflow? Is state preserved?
106- Are there features that appear to work but produce broken results?
107- How does the UI handle unexpected input (emoji, special chars, paste from Excel)?
108
109**Red Flags** (report these specifically):
110- Features that appear to work but silently fail or produce wrong results
111- Error handling that exposes technical details or leaves UI in a broken state
112- Empty states that show nothing useful ("No results" with no guidance)
113- Workflows that lose user data on refresh or navigation
114- Inconsistent behavior between similar interactions in different parts of the UI
115
116---
117
118## 5. Distracted Mobile User — "Casey"
119
120**Profile**: Using phone one-handed on the go. Frequently interrupted. Possibly on a slow connection.
121
122**Behaviors**:
123- Uses thumb only — prefers bottom-of-screen actions
124- Gets interrupted mid-flow and returns later
125- Switches between apps frequently
126- Has limited attention span and low patience
127- Types as little as possible, prefers taps and selections
128
129**Test Questions**:
130- Are primary actions in the thumb zone (bottom half of screen)?
131- Is state preserved if the user leaves and returns?
132- Does it work on slow connections (3G)?
133- Can forms leverage autocomplete and smart defaults?
134- Are touch targets at least 44×44pt?
135
136**Red Flags** (report these specifically):
137- Important actions positioned at the top of the screen (unreachable by thumb)
138- No state persistence — progress lost on tab switch or interruption
139- Large text inputs required where selection would work
140- Heavy assets loading on every page (no lazy loading)
141- Tiny tap targets or targets too close together
142
143---
144
145## Selecting Personas
146
147Choose personas based on the interface type:
148
149| Interface Type | Primary Personas | Why |
150|---------------|-----------------|-----|
151| Landing page / marketing | Jordan, Riley, Casey | First impressions, trust, mobile |
152| Dashboard / admin | Alex, Sam | Power users, accessibility |
153| E-commerce / checkout | Casey, Riley, Jordan | Mobile, edge cases, clarity |
154| Onboarding flow | Jordan, Casey | Confusion, interruption |
155| Data-heavy / analytics | Alex, Sam | Efficiency, keyboard nav |
156| Form-heavy / wizard | Jordan, Sam, Casey | Clarity, accessibility, mobile |
157
158---
159
160## Project-Specific Personas
161
162If `{{config_file}}` contains a `## Design Context` section (generated by `impeccable teach`), derive 1–2 additional personas from the audience and brand information:
163
1641. Read the target audience description
1652. Identify the primary user archetype not covered by the 5 predefined personas
1663. Create a persona following this template:
167
168```
169### [Role] — "[Name]"
170
171**Profile**: [2-3 key characteristics derived from Design Context]
172
173**Behaviors**: [3-4 specific behaviors based on the described audience]
174
175**Red Flags**: [3-4 things that would alienate this specific user type]
176```
177
178Only generate project-specific personas when real Design Context data is available. Don't invent audience details — use the 5 predefined personas when no context exists.