# 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)

1. Display Wednesday's storyboard (photo or whiteboard)
2. Number each frame
3. Assign frames to Makers: "You take frames 1-4, you take frames 5-8, you take frames 9-12"
4. Confirm the Stitcher knows the assembly plan
5. Writer begins drafting copy for all frames simultaneously
6. 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)

1. Stitcher assembles all screens into the final prototype
2. Add clickable hotspots and transitions
3. Ensure the flow follows the storyboard sequence exactly
4. Fill any gaps (missing screens, broken links)

### Step 4: Team Review (3:00 - 3:30)

1. The entire team sits together
2. The Stitcher walks through the prototype, click by click
3. Compare each screen to the storyboard frame
4. Note issues on sticky notes: missing content, broken links, confusing flow
5. 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)

1. Find someone not on the sprint team (a colleague from another department)
2. The Interviewer conducts a practice interview using the prototype
3. 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?
4. 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.
