| 1 | # Persona-Based Design Testing |
| 2 | |
| 3 | Test 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 | |
| 148 | Choose 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 | |
| 163 | If `AGENTS.md` contains a `## Design Context` section (generated by `impeccable teach`), derive 1–2 additional personas from the audience and brand information: |
| 164 | |
| 165 | 1. Read the target audience description |
| 166 | 2. Identify the primary user archetype not covered by the 5 predefined personas |
| 167 | 3. 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 | |
| 179 | Only 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. |
| 180 |