personas.md

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