Files of Thursday: Build the Prototype
wondelai/
thursday.md
Show the full text293 lines
Thursday: Build the Prototype
Thursday is about execution. The team transforms Wednesday's storyboard into a realistic prototype that customers can react to on Friday. The mantra for the day: fake it. You are not building a product. You are building a facade that looks real enough to provoke honest reactions.
Schedule Overview
| Time | Activity | Duration |
|---|---|---|
| 10:00 - 10:30 | Assign roles and divide storyboard | 30 min |
| 10:30 - 1:00 | Build: Makers create, Writer writes, Collector gathers | 150 min |
| 1:00 - 1:30 | Lunch (staggered if needed) | 30 min |
| 1:30 - 3:00 | Stitch: Assemble all pieces into a single prototype | 90 min |
| 3:00 - 3:30 | Review: Walk through the full prototype as a team | 30 min |
| 3:30 - 4:00 | Fix: Address gaps and polish rough spots | 30 min |
| 4:00 - 4:30 | Trial run with someone outside the team | 30 min |
| 4:30 - 5:00 | Interview script review and Friday prep | 30 min |
The Prototype Mindset
Fake It
The prototype does not need to work. It needs to look like it works. Users will click through screens, see realistic content, and form opinions based on appearance, not functionality.
| Real Product | Sprint Prototype |
|---|---|
| Database stores user data | Fake data hard-coded into screens |
| Algorithm generates recommendations | Hand-picked recommendations placed in the design |
| Payment processing | A screen that says "Payment successful" |
| Search functionality | Pre-built results page for one specific query |
| User authentication | Skip login or show a "Welcome, Sarah" screen |
Why Faking Works
Users do not evaluate the code behind a screen. They evaluate:
- Does this make sense?
- Do I trust this?
- Can I figure out what to do?
- Does this solve my problem?
A well-crafted facade answers all of these questions just as effectively as a working product.
Goldilocks Quality
The prototype must sit in a narrow quality band. Too rough, and customers cannot react realistically. Too polished, and you waste precious time on details that do not affect the test.
Quality Spectrum
| Too Low (Avoid) | Just Right (Target) | Too High (Avoid) |
|---|---|---|
| Wireframes with gray boxes | Realistic screens with real content | Pixel-perfect design with animations |
| Handwritten labels | Typed text in a clean font | Custom typography and brand guidelines |
| Placeholder images | Stock photos or screenshots | Professional photography or illustrations |
| No color | Basic color palette | Full brand color system |
| Paper prototype | Digital click-through | Working code with real backend |
| "Lorem ipsum" text | Real headlines and descriptions | Copywriter-polished marketing copy |
The Test: Show a screen to someone outside the team for 5 seconds
- If they say "Is this a wireframe?" — too low
- If they say "When did you build this?" — too high (or just right)
- If they say "Oh, interesting, what is this?" — just right
Role Assignments
Makers (2-3 people)
Responsibility: Build the individual screens or components of the prototype.
Best suited for: Designers, front-end developers, or anyone comfortable with visual tools.
What they do:
- Take assigned storyboard frames
- Create realistic-looking screens
- Follow the storyboard exactly (no improvising)
- Use real content, not placeholders
Stitcher (1 person)
Responsibility: Assemble all screens into a single, navigable prototype.
Best suited for: The most experienced designer or someone who knows the prototyping tool well.
What they do:
- Combine screens from Makers into one prototype
- Add transitions and hotspots (clickable areas)
- Ensure the flow matches the storyboard sequence
- Test every click path before the team review
Writer (1 person)
Responsibility: Write all text that appears in the prototype.
Best suited for: Marketer, product manager, or anyone with strong writing skills.
What they do:
- Write headlines, subheadlines, body copy
- Write button labels, form field labels, navigation items
- Write error messages and confirmation messages
- Keep copy concise and realistic
Writer's checklist:
- Every screen has a clear headline
- Button labels describe the action ("Start free trial" not "Submit")
- No placeholder text remains
- Copy matches the tone of a real product (not overly formal or casual)
- Key value propositions are clear
Collector (1-2 people)
Responsibility: Gather all visual assets needed by the Makers.
What they do:
- Find stock photos (Unsplash, Pexels)
- Collect icons (Noun Project, Feather Icons)
- Screenshot competitor interfaces for reference
- Source logos, avatars, and sample data
- Organize assets in a shared folder
Interviewer (1 person)
Responsibility: Prepare for Friday's user interviews.
What they do (while others build):
- Write the interview script (see Friday reference)
- Prepare context questions
- Plan tasks for users to complete with the prototype
- Practice the interview with a colleague
- Set up the interview room
Prototyping Tools by Product Type
Web and Mobile Apps
| Tool | Best For | Learning Curve | Fidelity |
|---|---|---|---|
| Figma | Most common choice. Teams often already use it | Medium | High |
| Keynote / PowerPoint | Quick click-through with linked slides | Low | Medium |
| InVision | Uploading static screens with hotspots | Low | Medium |
| Framer | Interactive prototypes with real components | High | Very high |
Physical Products
| Approach | When to Use |
|---|---|
| Video walkthrough | Show someone using a mockup or 3D print |
| Modified existing product | Tape labels, add stickers, rearrange components |
| 3D-printed shell | When form factor matters for the test |
| Wizard of Oz | Human behind the curtain simulating the product's behavior |
Services and Experiences
| Approach | When to Use |
|---|---|
| Role-play video | Film a scripted interaction with actors |
| Brochure or one-pager | Test the value proposition before building |
| Fake landing page | Test whether people click "Sign up" |
| Concierge prototype | Deliver the service manually to see if customers value it |
AI and Data Products
| Approach | When to Use |
|---|---|
| Pre-scripted responses | Show what the AI "would" say for specific queries |
| Curated results page | Hand-pick the "algorithm's" recommendations |
| Before/after comparison | Show input and output without the actual processing |
Step-by-Step Prototype Building
Step 1: Divide the Storyboard (10:00 - 10:30)
- Display Wednesday's storyboard (photo or whiteboard)
- Number each frame
- Assign frames to Makers: "You take frames 1-4, you take frames 5-8, you take frames 9-12"
- Confirm the Stitcher knows the assembly plan
- Writer begins drafting copy for all frames simultaneously
- Collector starts gathering assets immediately
Step 2: Build in Parallel (10:30 - 1:00)
Makers:
- Build screens for assigned frames
- Follow the storyboard exactly
- Use the Writer's copy as it becomes available
- Use the Collector's assets
- Ask the Stitcher about sizing, layout conventions, and shared elements
Stitcher:
- Set up the master file (Figma project, Keynote deck)
- Define shared elements: header, footer, navigation, button styles
- Begin assembling screens as Makers finish them
- Build the clickable flow
Coordination check-ins: Every 45 minutes, the Sprint Master does a quick standing check-in: "What is done? What is blocked? What do you need?"
Step 3: Stitch Together (1:30 - 3:00)
- Stitcher assembles all screens into the final prototype
- Add clickable hotspots and transitions
- Ensure the flow follows the storyboard sequence exactly
- Fill any gaps (missing screens, broken links)
Step 4: Team Review (3:00 - 3:30)
- The entire team sits together
- The Stitcher walks through the prototype, click by click
- Compare each screen to the storyboard frame
- Note issues on sticky notes: missing content, broken links, confusing flow
- Prioritize fixes: critical (blocks the test) vs. nice-to-have
Step 5: Fix and Polish (3:30 - 4:00)
- Fix critical issues only
- Do not add new features or screens
- Do not perfect the visual design
- Focus on: can a user complete the tasks we will assign on Friday?
Step 6: Trial Run (4:00 - 4:30)
- Find someone not on the sprint team (a colleague from another department)
- The Interviewer conducts a practice interview using the prototype
- The team watches and notes:
- Where does the trial user get confused?
- Are there broken links or dead ends?
- Does the prototype flow match what we want to test?
- Fix any issues the trial run reveals
Interview Script Writing Guide
While the team builds, the Interviewer writes the script for Friday. The script should cover:
Script Structure
| Section | Duration | Content |
|---|---|---|
| Welcome | 2 min | Introduction, consent for recording, think-aloud instructions |
| Background | 5 min | Questions about the participant's current behavior and context |
| First impression | 3 min | Show the first screen, ask "What is this? What would you do?" |
| Task completion | 15 min | 2-3 specific tasks to complete using the prototype |
| Debrief | 5 min | Overall impressions, who is this for, what worked, what confused |
Task Writing Tips
Good tasks are:
- Open-ended: "Find a project management tool that fits your team" (not "Click the blue button")
- Scenario-based: "Imagine you just got an email from a colleague recommending this tool"
- Specific enough to test the sprint questions: "You have a team of 5 and a budget of $100/month"
Thursday Checklist
- Roles assigned: Makers, Stitcher, Writer, Collector, Interviewer
- Storyboard frames divided among Makers
- All copy written by the Writer
- All assets gathered by the Collector
- Screens assembled into a clickable prototype by the Stitcher
- Full team review completed
- Critical issues fixed
- Trial run completed with someone outside the team
- Interview script written and reviewed
- Interview room set up (laptop, chairs, recording)
- Participants confirmed for Friday (check with recruiter)
Common Thursday Mistakes
Prototyping Features Not in the Storyboard
Problem: A Maker adds a clever feature that was not in the storyboard because "users might ask about it." Fix: Build only what is in the storyboard. Anything else wastes time and muddies the test. If the feature is missing and a user asks, that is useful data.
Over-Polishing Visual Design
Problem: The team spends 2 hours choosing the right shade of blue. Fix: Pick a simple, clean style and move on. Users react to the concept and flow, not the color palette. Use a pre-made UI kit or template to skip design decisions.
The Stitcher Becomes the Bottleneck
Problem: Makers finish screens but the Stitcher cannot assemble fast enough. Fix: The Stitcher should set up the master file and shared elements first thing. Makers should build in the shared format so assembly is drag-and-drop.
No Trial Run
Problem: The team skips the trial run because they ran out of time. Fix: The trial run is not optional. Cut polish time instead. A broken prototype on Friday wastes the entire week. Even a 15-minute trial run catches critical issues.
The Writer Writes Perfect Copy
Problem: The Writer agonizes over every word, slowing the entire team. Fix: Thursday copy is "good enough" copy. It needs to be clear and realistic, not award-winning. If the concept works, you will write better copy later.
Ignoring the Interview Script
Problem: The Interviewer writes a script at 4:55 PM or wings it on Friday. Fix: The Interviewer should spend the full day on script preparation and practice. A bad interview wastes a participant. The Interviewer should do at least one full practice run by 4:00 PM.
| 1 | # Thursday: Build the Prototype |
| 2 | |
| 3 | Thursday is about execution. The team transforms Wednesday's storyboard into a realistic prototype that customers can react to on Friday. The mantra for the day: fake it. You are not building a product. You are building a facade that looks real enough to provoke honest reactions. |
| 4 | |
| 5 | ## Schedule Overview |
| 6 | |
| 7 | | Time | Activity | Duration | |
| 8 | |------|----------|----------| |
| 9 | | 10:00 - 10:30 | Assign roles and divide storyboard | 30 min | |
| 10 | | 10:30 - 1:00 | Build: Makers create, Writer writes, Collector gathers | 150 min | |
| 11 | | 1:00 - 1:30 | Lunch (staggered if needed) | 30 min | |
| 12 | | 1:30 - 3:00 | Stitch: Assemble all pieces into a single prototype | 90 min | |
| 13 | | 3:00 - 3:30 | Review: Walk through the full prototype as a team | 30 min | |
| 14 | | 3:30 - 4:00 | Fix: Address gaps and polish rough spots | 30 min | |
| 15 | | 4:00 - 4:30 | Trial run with someone outside the team | 30 min | |
| 16 | | 4:30 - 5:00 | Interview script review and Friday prep | 30 min | |
| 17 | |
| 18 | ## The Prototype Mindset |
| 19 | |
| 20 | ### Fake It |
| 21 | |
| 22 | The prototype does not need to work. It needs to look like it works. Users will click through screens, see realistic content, and form opinions based on appearance, not functionality. |
| 23 | |
| 24 | | Real Product | Sprint Prototype | |
| 25 | |-------------|-----------------| |
| 26 | | Database stores user data | Fake data hard-coded into screens | |
| 27 | | Algorithm generates recommendations | Hand-picked recommendations placed in the design | |
| 28 | | Payment processing | A screen that says "Payment successful" | |
| 29 | | Search functionality | Pre-built results page for one specific query | |
| 30 | | User authentication | Skip login or show a "Welcome, Sarah" screen | |
| 31 | |
| 32 | ### Why Faking Works |
| 33 | |
| 34 | Users do not evaluate the code behind a screen. They evaluate: |
| 35 | Does this make sense? |
| 36 | Do I trust this? |
| 37 | Can I figure out what to do? |
| 38 | Does this solve my problem? |
| 39 | |
| 40 | A well-crafted facade answers all of these questions just as effectively as a working product. |
| 41 | |
| 42 | ## Goldilocks Quality |
| 43 | |
| 44 | The prototype must sit in a narrow quality band. Too rough, and customers cannot react realistically. Too polished, and you waste precious time on details that do not affect the test. |
| 45 | |
| 46 | ### Quality Spectrum |
| 47 | |
| 48 | | Too Low (Avoid) | Just Right (Target) | Too High (Avoid) | |
| 49 | |-----------------|--------------------|--------------------| |
| 50 | | Wireframes with gray boxes | Realistic screens with real content | Pixel-perfect design with animations | |
| 51 | | Handwritten labels | Typed text in a clean font | Custom typography and brand guidelines | |
| 52 | | Placeholder images | Stock photos or screenshots | Professional photography or illustrations | |
| 53 | | No color | Basic color palette | Full brand color system | |
| 54 | | Paper prototype | Digital click-through | Working code with real backend | |
| 55 | | "Lorem ipsum" text | Real headlines and descriptions | Copywriter-polished marketing copy | |
| 56 | |
| 57 | ### The Test: Show a screen to someone outside the team for 5 seconds |
| 58 | |
| 59 | If they say "Is this a wireframe?" — too low |
| 60 | If they say "When did you build this?" — too high (or just right) |
| 61 | If they say "Oh, interesting, what is this?" — just right |
| 62 | |
| 63 | ## Role Assignments |
| 64 | |
| 65 | ### Makers (2-3 people) |
| 66 | |
| 67 | **Responsibility:** Build the individual screens or components of the prototype. |
| 68 | |
| 69 | **Best suited for:** Designers, front-end developers, or anyone comfortable with visual tools. |
| 70 | |
| 71 | **What they do:** |
| 72 | Take assigned storyboard frames |
| 73 | Create realistic-looking screens |
| 74 | Follow the storyboard exactly (no improvising) |
| 75 | Use real content, not placeholders |
| 76 | |
| 77 | ### Stitcher (1 person) |
| 78 | |
| 79 | **Responsibility:** Assemble all screens into a single, navigable prototype. |
| 80 | |
| 81 | **Best suited for:** The most experienced designer or someone who knows the prototyping tool well. |
| 82 | |
| 83 | **What they do:** |
| 84 | Combine screens from Makers into one prototype |
| 85 | Add transitions and hotspots (clickable areas) |
| 86 | Ensure the flow matches the storyboard sequence |
| 87 | Test every click path before the team review |
| 88 | |
| 89 | ### Writer (1 person) |
| 90 | |
| 91 | **Responsibility:** Write all text that appears in the prototype. |
| 92 | |
| 93 | **Best suited for:** Marketer, product manager, or anyone with strong writing skills. |
| 94 | |
| 95 | **What they do:** |
| 96 | Write headlines, subheadlines, body copy |
| 97 | Write button labels, form field labels, navigation items |
| 98 | Write error messages and confirmation messages |
| 99 | Keep copy concise and realistic |
| 100 | |
| 101 | **Writer's checklist:** |
| 102 | [ ] Every screen has a clear headline |
| 103 | [ ] Button labels describe the action ("Start free trial" not "Submit") |
| 104 | [ ] No placeholder text remains |
| 105 | [ ] Copy matches the tone of a real product (not overly formal or casual) |
| 106 | [ ] Key value propositions are clear |
| 107 | |
| 108 | ### Collector (1-2 people) |
| 109 | |
| 110 | **Responsibility:** Gather all visual assets needed by the Makers. |
| 111 | |
| 112 | **What they do:** |
| 113 | Find stock photos (Unsplash, Pexels) |
| 114 | Collect icons (Noun Project, Feather Icons) |
| 115 | Screenshot competitor interfaces for reference |
| 116 | Source logos, avatars, and sample data |
| 117 | Organize assets in a shared folder |
| 118 | |
| 119 | ### Interviewer (1 person) |
| 120 | |
| 121 | **Responsibility:** Prepare for Friday's user interviews. |
| 122 | |
| 123 | **What they do (while others build):** |
| 124 | Write the interview script (see Friday reference) |
| 125 | Prepare context questions |
| 126 | Plan tasks for users to complete with the prototype |
| 127 | Practice the interview with a colleague |
| 128 | Set up the interview room |
| 129 | |
| 130 | ## Prototyping Tools by Product Type |
| 131 | |
| 132 | ### Web and Mobile Apps |
| 133 | |
| 134 | | Tool | Best For | Learning Curve | Fidelity | |
| 135 | |------|----------|---------------|----------| |
| 136 | | Figma | Most common choice. Teams often already use it | Medium | High | |
| 137 | | Keynote / PowerPoint | Quick click-through with linked slides | Low | Medium | |
| 138 | | InVision | Uploading static screens with hotspots | Low | Medium | |
| 139 | | Framer | Interactive prototypes with real components | High | Very high | |
| 140 | |
| 141 | ### Physical Products |
| 142 | |
| 143 | | Approach | When to Use | |
| 144 | |----------|------------| |
| 145 | | Video walkthrough | Show someone using a mockup or 3D print | |
| 146 | | Modified existing product | Tape labels, add stickers, rearrange components | |
| 147 | | 3D-printed shell | When form factor matters for the test | |
| 148 | | Wizard of Oz | Human behind the curtain simulating the product's behavior | |
| 149 | |
| 150 | ### Services and Experiences |
| 151 | |
| 152 | | Approach | When to Use | |
| 153 | |----------|------------| |
| 154 | | Role-play video | Film a scripted interaction with actors | |
| 155 | | Brochure or one-pager | Test the value proposition before building | |
| 156 | | Fake landing page | Test whether people click "Sign up" | |
| 157 | | Concierge prototype | Deliver the service manually to see if customers value it | |
| 158 | |
| 159 | ### AI and Data Products |
| 160 | |
| 161 | | Approach | When to Use | |
| 162 | |----------|------------| |
| 163 | | Pre-scripted responses | Show what the AI "would" say for specific queries | |
| 164 | | Curated results page | Hand-pick the "algorithm's" recommendations | |
| 165 | | Before/after comparison | Show input and output without the actual processing | |
| 166 | |
| 167 | ## Step-by-Step Prototype Building |
| 168 | |
| 169 | ### Step 1: Divide the Storyboard (10:00 - 10:30) |
| 170 | |
| 171 | Display Wednesday's storyboard (photo or whiteboard) |
| 172 | Number each frame |
| 173 | Assign frames to Makers: "You take frames 1-4, you take frames 5-8, you take frames 9-12" |
| 174 | Confirm the Stitcher knows the assembly plan |
| 175 | Writer begins drafting copy for all frames simultaneously |
| 176 | Collector starts gathering assets immediately |
| 177 | |
| 178 | ### Step 2: Build in Parallel (10:30 - 1:00) |
| 179 | |
| 180 | **Makers:** |
| 181 | Build screens for assigned frames |
| 182 | Follow the storyboard exactly |
| 183 | Use the Writer's copy as it becomes available |
| 184 | Use the Collector's assets |
| 185 | Ask the Stitcher about sizing, layout conventions, and shared elements |
| 186 | |
| 187 | **Stitcher:** |
| 188 | Set up the master file (Figma project, Keynote deck) |
| 189 | Define shared elements: header, footer, navigation, button styles |
| 190 | Begin assembling screens as Makers finish them |
| 191 | Build the clickable flow |
| 192 | |
| 193 | **Coordination check-ins:** Every 45 minutes, the Sprint Master does a quick standing check-in: "What is done? What is blocked? What do you need?" |
| 194 | |
| 195 | ### Step 3: Stitch Together (1:30 - 3:00) |
| 196 | |
| 197 | Stitcher assembles all screens into the final prototype |
| 198 | Add clickable hotspots and transitions |
| 199 | Ensure the flow follows the storyboard sequence exactly |
| 200 | Fill any gaps (missing screens, broken links) |
| 201 | |
| 202 | ### Step 4: Team Review (3:00 - 3:30) |
| 203 | |
| 204 | The entire team sits together |
| 205 | The Stitcher walks through the prototype, click by click |
| 206 | Compare each screen to the storyboard frame |
| 207 | Note issues on sticky notes: missing content, broken links, confusing flow |
| 208 | Prioritize fixes: critical (blocks the test) vs. nice-to-have |
| 209 | |
| 210 | ### Step 5: Fix and Polish (3:30 - 4:00) |
| 211 | |
| 212 | Fix critical issues only |
| 213 | Do not add new features or screens |
| 214 | Do not perfect the visual design |
| 215 | Focus on: can a user complete the tasks we will assign on Friday? |
| 216 | |
| 217 | ### Step 6: Trial Run (4:00 - 4:30) |
| 218 | |
| 219 | Find someone not on the sprint team (a colleague from another department) |
| 220 | The Interviewer conducts a practice interview using the prototype |
| 221 | The team watches and notes: |
| 222 | Where does the trial user get confused? |
| 223 | Are there broken links or dead ends? |
| 224 | Does the prototype flow match what we want to test? |
| 225 | Fix any issues the trial run reveals |
| 226 | |
| 227 | ## Interview Script Writing Guide |
| 228 | |
| 229 | While the team builds, the Interviewer writes the script for Friday. The script should cover: |
| 230 | |
| 231 | ### Script Structure |
| 232 | |
| 233 | | Section | Duration | Content | |
| 234 | |---------|----------|---------| |
| 235 | | Welcome | 2 min | Introduction, consent for recording, think-aloud instructions | |
| 236 | | Background | 5 min | Questions about the participant's current behavior and context | |
| 237 | | First impression | 3 min | Show the first screen, ask "What is this? What would you do?" | |
| 238 | | Task completion | 15 min | 2-3 specific tasks to complete using the prototype | |
| 239 | | Debrief | 5 min | Overall impressions, who is this for, what worked, what confused | |
| 240 | |
| 241 | ### Task Writing Tips |
| 242 | |
| 243 | Good tasks are: |
| 244 | Open-ended: "Find a project management tool that fits your team" (not "Click the blue button") |
| 245 | Scenario-based: "Imagine you just got an email from a colleague recommending this tool" |
| 246 | Specific enough to test the sprint questions: "You have a team of 5 and a budget of $100/month" |
| 247 | |
| 248 | ## Thursday Checklist |
| 249 | |
| 250 | [ ] Roles assigned: Makers, Stitcher, Writer, Collector, Interviewer |
| 251 | [ ] Storyboard frames divided among Makers |
| 252 | [ ] All copy written by the Writer |
| 253 | [ ] All assets gathered by the Collector |
| 254 | [ ] Screens assembled into a clickable prototype by the Stitcher |
| 255 | [ ] Full team review completed |
| 256 | [ ] Critical issues fixed |
| 257 | [ ] Trial run completed with someone outside the team |
| 258 | [ ] Interview script written and reviewed |
| 259 | [ ] Interview room set up (laptop, chairs, recording) |
| 260 | [ ] Participants confirmed for Friday (check with recruiter) |
| 261 | |
| 262 | ## Common Thursday Mistakes |
| 263 | |
| 264 | ### Prototyping Features Not in the Storyboard |
| 265 | |
| 266 | **Problem:** A Maker adds a clever feature that was not in the storyboard because "users might ask about it." |
| 267 | **Fix:** Build only what is in the storyboard. Anything else wastes time and muddies the test. If the feature is missing and a user asks, that is useful data. |
| 268 | |
| 269 | ### Over-Polishing Visual Design |
| 270 | |
| 271 | **Problem:** The team spends 2 hours choosing the right shade of blue. |
| 272 | **Fix:** Pick a simple, clean style and move on. Users react to the concept and flow, not the color palette. Use a pre-made UI kit or template to skip design decisions. |
| 273 | |
| 274 | ### The Stitcher Becomes the Bottleneck |
| 275 | |
| 276 | **Problem:** Makers finish screens but the Stitcher cannot assemble fast enough. |
| 277 | **Fix:** The Stitcher should set up the master file and shared elements first thing. Makers should build in the shared format so assembly is drag-and-drop. |
| 278 | |
| 279 | ### No Trial Run |
| 280 | |
| 281 | **Problem:** The team skips the trial run because they ran out of time. |
| 282 | **Fix:** The trial run is not optional. Cut polish time instead. A broken prototype on Friday wastes the entire week. Even a 15-minute trial run catches critical issues. |
| 283 | |
| 284 | ### The Writer Writes Perfect Copy |
| 285 | |
| 286 | **Problem:** The Writer agonizes over every word, slowing the entire team. |
| 287 | **Fix:** Thursday copy is "good enough" copy. It needs to be clear and realistic, not award-winning. If the concept works, you will write better copy later. |
| 288 | |
| 289 | ### Ignoring the Interview Script |
| 290 | |
| 291 | **Problem:** The Interviewer writes a script at 4:55 PM or wings it on Friday. |
| 292 | **Fix:** The Interviewer should spend the full day on script preparation and practice. A bad interview wastes a participant. The Interviewer should do at least one full practice run by 4:00 PM. |
| 293 |
Discussion
Alternatives
Make UI/UX better of an already Created ApplicationGenerate a comprehensive, actionable development plan to enhance the existing web application.UX researcherUse this agent when you need to design user research plans, analyze user-supplied data (interview transcripts, analytics, notes/transcripts from session recordings you provide), and generate actionable insights to validate design decisions and uncover user needs. Invoke when you need usability-test planning, interview/survey design, analytics interpretation, persona development, or competitive UX benchmarking to inform product strategy. Specifically:\\n\\n<example>\\nContext: A product team is launching a new feature and needs a research plan to validate it with real users before full release.\\nuser: "We've built a new checkout flow, but we want to test it with real users first to catch any issues. Can you help us plan usability testing?"\\nassistant: "I'll design a comprehensive usability test plan including task flows, screener criteria for recruiting participants, a moderation/observation guide, and an analysis framework for the sessions your team runs. Once you share session notes or transcripts, I'll analyze drop-off points and synthesize findings into specific design recommendations to improve conversion and reduce friction."\\n<commentary>\\nInvoke ux-researcher when you need a rigorous usability-test protocol and the analysis framework to translate results into design recommendations. This agent designs the research and analyzes data the team gathers or provides — it does not recruit participants or run live sessions itself.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: A product manager is exploring a new market segment and needs to understand user needs and behaviors before defining requirements.\\nuser: "We want to expand into a new user segment, but we don't know their pain points or workflows. How can we understand what they need?"\\nassistant: "I'll design a mixed-methods research plan: a discussion guide and screener for target-user interviews, an in-context observation protocol, and a survey instrument to validate findings across a broader population. Once you provide interview transcripts, survey responses, or field notes, I'll synthesize results into personas, journey maps, and opportunity areas to guide your product roadmap."\\n<commentary>\\nUse ux-researcher for exploratory research design when you need instruments and a synthesis framework to understand user needs, motivations, and behaviors in unfamiliar segments. The agent designs the protocols and analyzes the data you supply.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: Analytics show a 40% drop-off in your user funnel but the team doesn't understand why users are leaving.\\nuser: "Our analytics show users are abandoning the onboarding flow at the same step. What's causing this and how do we fix it?"\\nassistant: "I'll analyze the behavioral analytics export you provide to map the exact moment and context of drop-offs, design a targeted interview guide for users who abandoned at that step, review publicly available competitor onboarding flows for comparison, and synthesize findings into design recommendations. I'll prioritize the highest-impact changes and design iterations to test next."\\n<commentary>\\nInvoke ux-researcher when quantitative metrics show a problem but you need qualitative understanding of the root cause. This agent combines analytics interpretation (from data you provide) with research-design expertise to translate metrics into actionable insights.\\n</commentary>\\n</example>UX researcher designerUX research and design toolkit for Senior UX Designer/Researcher including data-driven persona generation, journey mapping, usability testing frameworks, and research synthesis. Use for user research, persona creation, journey mapping, and design validation.
Cs UX researcherUX research agent for research planning, persona generation, journey mapping, and usability test analysis. Use when product decisions need user evidence — e.g., planning interview scripts and recruiting criteria for a discovery study, or synthesizing usability-test sessions into prioritized findings and updated personas.
Cs UX researcherUX research agent for research planning, persona generation, journey mapping, and usability test analysis. Use when product decisions need user evidence — e.g., planning interview scripts and recruiting criteria for a discovery study, or synthesizing usability-test sessions into prioritized findings and updated personas.Browse more free Claude skills or everything in Design.