# Design Sprint Case Studies

These case studies illustrate how real teams used the design sprint process to solve critical business problems. Each study follows the five-day structure and highlights what worked, what did not, and what lessons emerged. The companies range from well-funded startups to large enterprises to nonprofits.

## Case Study 1: Slack - Onboarding New Teams

### Company

Slack, the workplace messaging platform. At the time of this sprint, Slack was growing rapidly but facing a critical problem: many teams signed up but never became active users.

### Challenge

New teams would create a Slack workspace, invite a few colleagues, and then go quiet within 48 hours. The data showed that teams who sent 2,000 messages within the first week had a 93% retention rate, but most teams never reached that threshold. The sprint question: "How might we get new teams to their first 2,000 messages faster?"

### Sprint Process

**Monday:** The team mapped the journey from "admin creates workspace" to "team sends 2,000 messages." They identified a critical gap: after the admin invited colleagues, those colleagues received a generic email that did not explain why they should join or what to do first. The target became the first 30 minutes after a team member accepts the invitation.

**Tuesday:** Lightning Demos included how Duolingo gets users to complete their first lesson within 60 seconds and how multiplayer games create immediate social interactions. The team sketched solutions ranging from a guided onboarding wizard to a bot that would prompt conversation topics.

**Wednesday:** The winning sketch was "Slackbot Welcome," a concept where an AI bot would greet each new team member, ask them a fun question, and post their answer in the general channel, creating immediate social activity.

**Thursday:** The team prototyped a click-through showing the invitation email (redesigned with a clear value proposition), the first login experience, and the Slackbot interaction. They used Figma for the app screens and rewrote the email copy to emphasize team connection rather than product features.

**Friday:** 5 participants (team leads at small companies) walked through the prototype. 4 out of 5 said they would respond to the Slackbot question. 3 out of 5 said the redesigned email made them significantly more likely to click through compared to the existing email.

### Results

The redesigned invitation email increased click-through rates by 30% in subsequent A/B testing. The Slackbot conversation starter was refined over several iterations and became part of the default onboarding flow.

### Lessons

- The biggest opportunity was not in the product interface but in the email that brought people to the product
- Social interaction (not feature discovery) was the key driver of early retention
- The team's initial assumption that users needed a "product tour" was wrong; users needed a reason to talk

## Case Study 2: Blue Bottle Coffee - Online Store

### Company

Blue Bottle Coffee, a specialty coffee roaster known for its carefully curated in-store experience. They wanted to translate that experience to e-commerce.

### Challenge

Blue Bottle's existing online store looked and felt like every other e-commerce site: grid of products, add to cart, checkout. It did not communicate their brand's emphasis on freshness, origin, and craft. The sprint question: "Can we create an online buying experience that feels as personal as visiting a Blue Bottle cafe?"

### Sprint Process

**Monday:** The team mapped the in-store experience alongside the online experience. In-store, a barista asks what flavors you like and recommends a coffee. Online, customers stared at 40 bags of coffee with no guidance. The target: the moment a new customer decides which coffee to buy.

**Tuesday:** Lightning Demos included how Stitch Fix uses a style quiz to personalize recommendations, how wine apps describe flavor profiles visually, and how the Blue Bottle barista script actually works in stores. Solution sketches ranged from a "coffee quiz" to a curated subscription to a visual flavor map.

**Wednesday:** The Decider chose a combination: a simple 3-question quiz ("What do you usually drink? How do you brew? What flavors do you like?") followed by a personalized recommendation with tasting notes and origin story.

**Thursday:** The prototype was built in Keynote with linked slides. Each quiz answer led to a different recommendation page. The team wrote detailed copy for 4 different coffee recommendations, including origin stories, roast dates, and brewing tips.

**Friday:** 5 participants (regular online coffee buyers who had never tried Blue Bottle) tested the prototype. All 5 completed the quiz. 4 out of 5 said the recommendation felt personal and trustworthy. 3 out of 5 said they would pay a premium because the quiz made them feel confident in the choice. 1 participant said "This is like having a barista in my phone."

### Results

Blue Bottle launched a version of the coffee quiz on their website. It became one of the highest-converting entry points for new customers and was later adapted for their mobile app.

### Lessons

- Translating a physical experience to digital requires identifying the core emotional value, not just the functional steps
- A quiz format transforms a passive catalog into an interactive experience
- Customers will pay more when they feel guided rather than overwhelmed by choice

## Case Study 3: Savioke - Robot Hotel Delivery

### Company

Savioke, a robotics startup building autonomous delivery robots for hotels. Their robot, Relay, delivered items like toothbrushes and snacks from the front desk to guest rooms.

### Challenge

The robot worked technically, but hotels were hesitant to adopt it. The sprint question: "Will hotel guests react positively to a robot delivering items to their room, and will hotels see it as a brand enhancer rather than a gimmick?"

### Sprint Process

**Monday:** The team mapped the guest experience from calling the front desk to receiving the item. They identified two critical moments: the guest's first sight of the robot in the hallway and the handoff at the guest room door. The target: the doorway interaction when the robot arrives.

**Tuesday:** Lightning Demos included how Disney designs character interactions at theme parks (anticipation, surprise, delight), how Amazon delivery confirms successful drop-off, and how vending machines provide instant gratification. Sketches explored different robot behaviors: should it make sounds? Display a screen? Wait for the guest to open the door?

**Wednesday:** The winning concept featured a robot that calls the guest's room phone to announce arrival, displays a friendly message on its screen, opens its lid for the guest to retrieve the item, and does a happy wiggle when the lid closes. The team debated the wiggle extensively, but the Decider approved it.

**Thursday:** The team could not prototype a physical robot interaction digitally, so they used a Wizard of Oz approach: they programmed the actual Relay robot with the new behaviors and prepared to have real guests interact with it at a partner hotel.

**Friday:** Instead of a standard screen-based prototype test, the team set up at a hotel. 5 guests who had called the front desk for items were surprised by the robot delivery. The team observed from the security camera feed and debriefed guests immediately after. All 5 guests smiled or laughed when the robot arrived. 4 out of 5 pulled out their phones to take a photo or video. The wiggle generated the strongest positive reaction, with 3 guests saying "That's adorable" or similar. 0 guests expressed discomfort or concern.

### Results

Savioke refined the interaction based on the sprint findings and deployed Relay in multiple hotel chains. The wiggle became a signature behavior. Hotels reported that robot deliveries generated social media posts from guests, providing free marketing.

### Lessons

- Physical product sprints can use Wizard of Oz prototyping instead of screen mockups
- Emotional design details (the wiggle) can be the difference between a gimmick and a beloved experience
- Testing in context (a real hotel, not a lab) provided higher-quality reactions
- The sprint question was answered definitively in one day: guests love robot delivery

## Case Study 4: Flatiron Health - Cancer Research Data

### Company

Flatiron Health, a healthcare technology company building software to organize cancer research data from electronic health records. Their users were oncologists and clinical researchers.

### Challenge

Oncologists needed to find eligible patients for clinical trials, but the process involved manually searching through medical records. Flatiron had the data but the interface was designed for data scientists, not doctors. The sprint question: "Can we build a clinical trial matching tool that oncologists will actually use during patient appointments?"

### Sprint Process

**Monday:** The team included two oncologists, a data scientist, a designer, and a product manager. The expert interviews revealed that oncologists have approximately 15 minutes per patient appointment and will not use any tool that takes more than 30 seconds to deliver a result. The target: the moment when an oncologist wonders "Is there a clinical trial for this patient?"

**Tuesday:** Lightning Demos included how Google Flights shows results instantly with progressive detail, how dating apps use simple yes/no swiping to reduce decision fatigue, and how an existing internal tool (complex but accurate) surfaced matches. Sketches ranged from a fully automated notification system to a single-search-box interface.

**Wednesday:** The winning sketch was a "one-click match" concept: the oncologist clicks a button next to the patient's name in the EHR, and within seconds sees a ranked list of eligible trials with a confidence score and one-line summary for each.

**Thursday:** The team built a Figma prototype with realistic patient data (anonymized). They created 3 patient scenarios with pre-populated trial results. The prototype looked like it was embedded in the existing EHR interface, which was critical for realism.

**Friday:** 5 oncologists tested the prototype between real patient appointments. All 5 understood the interface immediately. 4 out of 5 said they would use it during appointments. The key finding: oncologists cared more about the "why" (why this patient matches this trial) than the "what" (which trials matched). The confidence score was not sufficient; they needed to see the specific matching criteria.

### Results

Flatiron redesigned the matching display to show specific eligibility criteria alongside each trial recommendation. The tool was launched as part of their clinical platform and increased clinical trial enrollment rates at partner hospitals.

### Lessons

- Domain experts (oncologists) on the sprint team prevented the designers from building something technically elegant but clinically useless
- The constraint of 30 seconds per interaction forced ruthless simplicity
- The sprint revealed a critical insight (show "why" not just "what") that would have taken months to discover through traditional development

## Case Study 5: Harvest - Time Tracking for Freelancers

### Company

Harvest, a time tracking and invoicing tool. They noticed that freelancers signed up but abandoned the product before sending their first invoice.

### Challenge

Freelancers found time tracking tedious and rarely did it consistently. Without tracked time, they could not generate invoices, which was the product's core value. The sprint question: "Can we make time tracking effortless enough that freelancers actually do it every day?"

### Sprint Process

**Monday:** The team mapped the freelancer's day from waking up to sending an end-of-month invoice. They discovered that freelancers did not think in terms of "projects" and "time entries" (Harvest's mental model) but in terms of "clients" and "what I did today." The target: the daily habit of recording time.

**Tuesday:** Lightning Demos included how fitness apps use daily streaks to build habits, how Uber shows a trip summary after each ride (passive time tracking), and how journaling apps prompt reflection at the end of the day. The team sketched solutions including an end-of-day prompt, automatic time detection from calendar events, and a simplified mobile interface.

**Wednesday:** The Decider chose a "daily digest" concept: at 5 PM, Harvest sends a notification that says "What did you work on today?" The freelancer taps to see their calendar events pre-filled as time entries. They confirm, adjust, or add entries in under 60 seconds.

**Thursday:** The prototype was a series of mobile screens in Figma showing the notification, the pre-filled daily digest, and the one-tap confirmation flow. The Writer created realistic calendar data for a fictional freelance designer.

**Friday:** 5 freelancers tested the prototype. All 5 said the end-of-day prompt was significantly better than opening the app and manually starting timers. 3 out of 5 said the pre-filled entries from calendar data would save them the most time. The biggest complaint: 2 out of 5 did not use a calendar for all their work, so the pre-fill was incomplete.

### Results

Harvest launched a simplified end-of-day tracking feature that reduced the average time-tracking effort from 5 minutes per day to under 1 minute. Calendar integration became a premium feature.

### Lessons

- The product's mental model (projects, time entries) did not match the user's mental model (clients, what I did today)
- Passive data collection (calendar events) dramatically reduced user effort
- The sprint revealed that the core problem was not the interface but the workflow: users needed a prompt, not a better stopwatch

## Case Study 6: Code for America - Government Benefits Application

### Company

Code for America, a nonprofit that works with government agencies to improve public services through technology. They were redesigning the application process for government benefits (food assistance, healthcare, childcare subsidies).

### Challenge

The existing application form was 40 pages long, required documentation that applicants often did not have, and took an average of 3 hours to complete. Many eligible people abandoned the application. The sprint question: "Can we reduce the application from 3 hours to under 20 minutes while still collecting the information the government needs?"

### Sprint Process

**Monday:** The team included a benefits caseworker, a policy expert, two designers, and a developer. Expert interviews revealed that 60% of form fields were either redundant, rarely used for eligibility determination, or could be verified through existing government databases. The target: the first 10 minutes of the application, which had the highest abandonment rate.

**Tuesday:** Lightning Demos included how TurboTax turns a complex tax form into a conversational Q&A, how UK.gov reduced government forms to plain language, and how mobile banking apps use progressive disclosure. Sketches included a chatbot-style application, a "tell us about yourself" conversational form, and a staged approach that collects only essential information first.

**Wednesday:** The winning concept was a staged application: Stage 1 collects only what is needed for a preliminary eligibility check (5 questions), Stage 2 completes the full application only if the applicant qualifies. This meant applicants who were not eligible learned within 2 minutes instead of investing 3 hours.

**Thursday:** The team built a mobile-first prototype with clear, plain-language questions, large buttons, and a progress indicator. They included a Spanish language option for 3 of the 5 screens.

**Friday:** 5 participants were recruited from a community center that assists benefits applicants. 4 out of 5 completed Stage 1 in under 3 minutes. All 5 said the language was clearer than the existing form. 3 out of 5 expressed relief at learning their eligibility early: "I wish all government forms started by telling you if you qualify." 1 participant who was not tech-savvy needed help navigating the mobile interface.

### Results

The staged application approach was adopted by several counties in California. Initial data showed a 40% reduction in application abandonment and a 25% increase in completed applications.

### Lessons

- Government services benefit enormously from design sprints because the user experience is often decades behind the private sector
- Involving a policy expert on the sprint team prevented the designers from cutting fields that were legally required
- The biggest insight was structural (staged vs. linear) not visual (better buttons or colors)
- Testing with actual benefits applicants (not proxies) was essential for realistic feedback

## Case Study 7: Grind Coffee - Subscription Model

### Company

Grind, a London-based coffee company with physical cafes exploring a direct-to-consumer subscription for home coffee delivery.

### Challenge

Grind had strong brand recognition from their cafes but no online subscription presence. They did not know if their cafe customers would pay for a home delivery subscription or what the subscription experience should look like. The sprint question: "Will Grind cafe customers subscribe to home coffee delivery, and what do they need to see to commit?"

### Sprint Process

**Monday:** The team mapped two journeys: the existing cafe visit and the hypothetical subscription sign-up. They discovered that cafe loyalty was emotional (community, baristas, atmosphere) while subscription would need to be practical (convenience, freshness, value). The target: the subscription landing page where a cafe customer decides whether to subscribe.

**Tuesday:** Lightning Demos included Dollar Shave Club's viral landing page, how Nespresso creates a luxury unboxing experience, and how HelloFresh explains subscription flexibility (skip, pause, cancel). Solution sketches explored different value propositions: freshness guarantee, exclusive blends, customization, and environmental impact.

**Wednesday:** The Decider chose a landing page concept that led with freshness ("Roasted on Monday, at your door by Wednesday") combined with a simple quiz to match the customer's taste profile. The key differentiator: each delivery would include a handwritten-style note from the roaster.

**Thursday:** The team built a Keynote click-through prototype of the landing page, taste quiz, subscription configuration (frequency, grind type, quantity), and confirmation page. They used real product photography from Grind's existing marketing materials.

**Friday:** 5 Grind cafe regulars tested the prototype. All 5 understood the value proposition immediately. 4 out of 5 said they would subscribe. The freshness angle ("roasted on Monday") was the most compelling element, cited by all 5 participants. The roaster's note was cited by 3 out of 5 as a differentiator from generic subscriptions. Pricing was the main concern: 2 participants said they would need to see a clear comparison to their current cafe spending.

### Results

Grind launched their subscription service using the freshness-first messaging and taste quiz validated in the sprint. The subscription business grew to become a significant revenue stream alongside their physical cafes.

### Lessons

- Existing customers are the best first audience for a new product line, but their motivations may differ from what the team assumes
- A concrete detail ("roasted on Monday, at your door by Wednesday") is more persuasive than an abstract claim ("fresh coffee delivered")
- The sprint identified a gap (pricing comparison) that the team had not considered, leading them to add a "cost per cup" calculator to the final landing page

## Cross-Cutting Patterns

Looking across all seven case studies, several patterns emerge:

### The Target Is Rarely Where You Expect

In 5 out of 7 cases, the Monday target ended up in a different part of the journey than the team initially expected. Slack thought the problem was in-app onboarding; it was in the invitation email. Harvest thought the problem was the timer UI; it was the daily workflow.

### Simplicity Wins

Every successful sprint prototype was simpler than the team's initial instinct. Flatiron went from a complex dashboard to a one-click button. Code for America went from a 40-page form to 5 questions. The design sprint's time constraint forces simplicity.

### Friday Reveals Surprises

In every case, at least one significant Friday finding was unexpected. Savioke did not expect the wiggle to be the standout feature. Flatiron did not expect oncologists to prioritize "why" over "what." Blue Bottle did not expect customers to pay a premium based on quiz-driven confidence.

### Domain Experts Are Essential

The most successful sprints (Flatiron, Code for America) included domain experts as full team members, not just Monday interviewees. Their constraints and insights prevented the team from designing solutions that were technically elegant but practically useless.

### Real Users, Real Context

Savioke tested in a real hotel. Code for America recruited from a community center. The closer the test environment matches reality, the more reliable the results.

### One Week Is Enough

Every team started the sprint week doubting they could prototype and test in 5 days. Every team ended the week with actionable insights they would not have had for months under a normal development process.

# Facilitation Guide for Sprint Masters

The Sprint Master makes or breaks the design sprint. This role is equal parts timekeeper, therapist, traffic cop, and energy manager. A great facilitator creates the conditions for the team's best thinking while preventing the dysfunction that derails most group work.


## Table of Contents
1. [The Sprint Master Role](#the-sprint-master-role)
2. [Time-Boxing Techniques](#time-boxing-techniques)
3. [Energy Management](#energy-management)
4. [Dealing with Difficult Participants](#dealing-with-difficult-participants)
5. [Decision-Making Protocols](#decision-making-protocols)
6. [Room Setup and Materials Checklist](#room-setup-and-materials-checklist)
7. [Day-by-Day Facilitation Tips](#day-by-day-facilitation-tips)
8. [Logistics: Music, Snacks, and Breaks](#logistics-music-snacks-and-breaks)

---

## The Sprint Master Role

### Core Responsibilities

| Responsibility | What It Looks Like |
|---------------|-------------------|
| Time management | Starting and ending exercises on time, using visible timers |
| Process enforcement | Ensuring each exercise follows the correct format |
| Energy management | Reading the room, calling breaks, adjusting pace |
| Neutrality | Not advocating for any particular solution |
| Conflict resolution | Defusing tension without taking sides |
| Documentation | Ensuring all outputs are captured (photos, notes) |
| Logistics | Room setup, supplies, meals, technology |

### Who Should Be the Sprint Master

**Good candidates:**
- Product manager with facilitation experience
- Design lead who can resist designing during the sprint
- External facilitator or consultant
- Scrum master or agile coach

**Poor candidates:**
- The CEO or founder (they should be the Decider, not the facilitator)
- Someone who has a strong opinion about the solution (they will push it)
- The most junior person in the room (they lack the authority to enforce time)
- Someone who has never run a meeting before (start smaller)

### Key Principle: The Sprint Master Does Not Contribute Solutions

During sketching, voting, and deciding, the Sprint Master participates only as a facilitator. If they have a strong solution idea, they should sketch it like everyone else but not advocate for it during critique. The moment a facilitator pushes their own idea, they lose neutrality and the team defers to them.

## Time-Boxing Techniques

### Why Time-Boxing Matters

Without time limits, every exercise expands to fill the available time. Long-term goal becomes a 2-hour strategy debate. Lightning Demos become 15-minute presentations. The storyboard never finishes.

### Tools for Time-Boxing

| Tool | When to Use |
|------|------------|
| Time Timer (visual countdown) | Every exercise. Place it where everyone can see it |
| Phone timer with loud alarm | Backup timer. Set it 1 minute before the end as a warning |
| Music playlist | Play during silent work. When the music stops, time is up |
| Written schedule on wall | Post the full day schedule so everyone can see what is coming |

### The Two-Minute Warning

For every exercise, announce "Two minutes remaining" when the timer hits the mark. This gives people time to wrap up their thought without the jarring surprise of a sudden stop.

### When to Extend Time

Extend time only when:
- The team is clearly making productive progress (not just talking)
- The exercise output is incomplete and critical for the next step
- The Decider explicitly asks for more time

Never extend time because:
- The discussion is "interesting" (interesting discussions are infinite)
- One person is not finished (they can catch up during the break)
- The team "wants to explore this more" (the schedule exists for a reason)

### Time-Boxing by Day

**Monday:**

| Exercise | Budgeted Time | Strict or Flexible |
|----------|--------------|-------------------|
| Long-term goal | 30 min | Strict. The Decider breaks ties |
| Sprint questions | 45 min | Flexible +15 min if new questions are emerging |
| Customer journey map | 60 min | Strict. Keep the map simple |
| Ask the Experts | 20 min per expert | Strict. Thank the expert and move on |
| HMW voting | 30 min | Strict. Voting should not require discussion |
| Target selection | 30 min | Strict. Decider makes the call |

**Tuesday:**

| Exercise | Budgeted Time | Strict or Flexible |
|----------|--------------|-------------------|
| Lightning Demos | 3 min per demo | Strict. Use a timer for each demo |
| Notes | 20 min | Strict |
| Ideas | 20 min | Strict |
| Crazy 8s | 8 min | Strict. 1 minute per panel, no exceptions |
| Solution Sketch | 90 min | Flexible +15 min. This is the most important output |

**Wednesday:**

| Exercise | Budgeted Time | Strict or Flexible |
|----------|--------------|-------------------|
| Art Museum | 30 min | Strict |
| Speed Critique | 3 min per sketch | Strict. Use a timer for each sketch |
| Straw Poll | 15 min | Strict |
| Supervote | 15 min | Strict. The Decider knows what they want |
| Storyboard | 150 min | Flexible +30 min if gaps remain |

**Thursday:**

| Exercise | Budgeted Time | Strict or Flexible |
|----------|--------------|-------------------|
| Role assignment | 30 min | Strict |
| Building | 150 min | Flexible. Prioritize completion over polish |
| Stitching | 90 min | Strict. Must finish to allow trial run |
| Team review | 30 min | Strict |
| Trial run | 30 min | Strict. Must happen before end of day |

**Friday:**

| Exercise | Budgeted Time | Strict or Flexible |
|----------|--------------|-------------------|
| Each interview | 45 min | Strict. Respect participant's time |
| Between-interview breaks | 30 min | Flexible. Can shorten to 15 if running late |
| Debrief | 75 min | Flexible +30 min. This is the payoff |

## Energy Management

### Energy Management Tactics

| Tactic | When to Use |
|--------|------------|
| Stand-up exercises | After lunch, during storyboarding, any time energy drops |
| Change of scenery | Take a 10-minute walk break outside the sprint room |
| Music during silent work | Background music keeps energy up during individual exercises |
| Snack table | Protein-heavy snacks available all day (avoid sugar crashes) |
| Celebrate small wins | End each day by naming what the team accomplished |
| Physical movement | Move to a different wall, rearrange chairs, change the room layout |

### Afternoon Slump Protocol

Every day between 2:00 and 3:00 PM, energy typically drops. Plan for it:

1. Schedule a 10-minute break at 2:00 PM
2. Provide coffee and high-protein snacks
3. Start the next exercise with a brief standing activity
4. If possible, schedule active exercises (voting, building) for this time slot rather than passive ones (listening, reviewing)

## Dealing with Difficult Participants

### The HiPPO (Highest-Paid Person's Opinion)

**Behavior:** Dominates discussion, others defer to their authority.
**Tactic:** Use the structured exercises as designed. Silent voting, anonymous sketches, and individual work prevent the HiPPO from overriding the group. If the HiPPO is the Decider, remind them that their power comes at the Supervote, not during open discussion.

### The Skeptic

**Behavior:** Vocally doubts the process. "This is a waste of time." "This will never work."
**Tactic:** Acknowledge their concern briefly: "I hear you. Let's see how the week goes. If we are not getting value by Wednesday, we can adjust." Then redirect to the exercise. Most skeptics become converts by Wednesday when they see the storyboard take shape.

### The Talker

**Behavior:** Fills every silence with commentary. Derails exercises with tangents.
**Tactic:** Use the timer as your ally: "We have 2 minutes left, so let's get back to the exercise." During silent phases, gently say "Remember, this part is individual and quiet." If needed, speak privately during a break.

### The Perfectionist

**Behavior:** Cannot move on until every detail is resolved.
**Tactic:** Use the phrase "We will address that later in the sprint" or "Let's note it and move on." Put unresolved details on a parking lot sticky note. The perfectionist needs to see that their concern is captured, even if it is not resolved now.

### The Quiet Participant

**Behavior:** Rarely speaks up, defers to others, may seem disengaged.
**Tactic:** The sprint's silent exercises (sketching, dot voting) naturally give quiet people a voice. During discussions, use round-robin: "Let's hear from everyone. [Name], what do you think?" During breaks, check in privately: "How is it going? Anything you want to raise?"

### The Multi-Tasker

**Behavior:** Checks phone, works on email, takes calls during the sprint.
**Tactic:** Set the rule on Monday morning: no devices during exercises. Place a phone basket at the door. If someone violates, say "Let's put phones away for this exercise. We have a break in 30 minutes." If they persist, talk privately during a break about the commitment.

## Decision-Making Protocols

### When the Team Decides

Dot voting and straw polls are used for:
- HMW prioritization
- Art Museum heat maps
- Straw poll preferences

These are input for the Decider, not final decisions.

### When the Decider Decides

The Decider has final authority on:
- Long-term goal
- Target selection
- Supervote (which solution to prototype)
- Rumble vs All-in-One
- Any tie-breaking situation

### When the Sprint Master Decides

The Sprint Master has authority over:
- Time management (when to end an exercise)
- Process (which exercise comes next)
- Room logistics
- Whether to extend time on an exercise

## Room Setup and Materials Checklist

### Room Requirements

- [ ] Large room with floor-to-ceiling whiteboard (or multiple whiteboards)
- [ ] No glass walls (privacy for discussions)
- [ ] Door that closes (quiet from outside noise)
- [ ] Power outlets for laptops (Thursday prototyping)
- [ ] Separate observation room for Friday (or a quiet corner with headphones)

### Materials Checklist

**Writing and drawing:**
- [ ] Thick black markers (Sharpie or similar), 1 per person
- [ ] Fine-tip markers for detail work, 1 per person
- [ ] Letter-size blank paper, 50+ sheets
- [ ] Whiteboard markers (black, blue, red, green)
- [ ] Whiteboard eraser and spray

**Sticky notes and voting:**
- [ ] Standard sticky notes (3x3), 5 pads in various colors
- [ ] Large sticky notes (5x8), 2 pads
- [ ] Small dot stickers (1/4 inch), 100+
- [ ] Large dot stickers (3/4 inch), 2 per person plus 3 for the Decider
- [ ] Painter's tape for hanging sketches

**Technology:**
- [ ] Time Timer or visible countdown timer
- [ ] Laptop for Thursday prototyping
- [ ] TV or monitor for Friday interview observation
- [ ] Video conferencing setup if remote participants join for Friday
- [ ] Camera for recording Friday interviews

**Comfort:**
- [ ] Snacks: nuts, fruit, protein bars, crackers
- [ ] Drinks: water, coffee, tea
- [ ] Lunch plan for each day (order in or nearby restaurant with fast service)

## Day-by-Day Facilitation Tips

### Monday

- Start with introductions if not everyone knows each other
- Write the schedule on the whiteboard so everyone sees the plan
- Enforce the "no solutions yet" rule: Monday is about understanding, not solving
- Take a photo of every whiteboard before erasing
- End the day by reading the target aloud and getting a verbal confirmation from everyone

### Tuesday

- Begin with a recap of Monday's target (2 minutes)
- Keep Lightning Demos moving fast; use the timer visibly
- During the Four-Step Sketch, your job is to keep the room silent
- Walk around during Crazy 8s and say "Switch" every minute
- Collect sketches at the end without looking at them

### Wednesday

- Arrive early to tape sketches to the wall for the Art Museum
- During Speed Critique, stand next to each sketch and point as you narrate
- Keep a running list of standout ideas on the whiteboard
- After the Supervote, thank the team for their work and honor the Decider's choice
- During storyboarding, ask "What happens next?" to keep the team moving

### Thursday

- Do a quick standing check-in at 10:30, 12:00, and 2:00
- Walk around and look at progress; flag problems early
- Protect the Interviewer's time for script writing
- Insist on the trial run even if the team resists

### Friday

- Arrive 30 minutes early to set up rooms
- Brief the team: "Watch, listen, and take notes. Do not react out loud."
- Between interviews, lead a 5-minute "What did we see?" discussion
- At the debrief, write findings on the whiteboard as the team discusses
- End the sprint by thanking the team and scheduling a follow-up meeting

## Logistics: Music, Snacks, and Breaks

### Music

- Play low-volume instrumental music during silent work phases (sketching, dot voting)
- No lyrics (they distract from thinking)
- Good options: lo-fi beats, jazz, ambient electronic, classical
- Turn music off during discussions and presentations

### Breaks

| Type | Frequency | Duration |
|------|-----------|----------|
| Micro break | Every 60-90 min | 5 min (stand, stretch, refill water) |
| Full break | Mid-morning and mid-afternoon | 15 min (leave the room, check phone) |
| Lunch | Daily | 45-60 min (eat away from the sprint room if possible) |

### End-of-Day Rituals

End each day with:
1. Sprint Master reads aloud what was accomplished
2. Quick round: each person names one thing they are excited about
3. Confirm tomorrow's start time
4. Remind everyone: no outside work on sprint topics tonight (fresh eyes matter)

# Friday: Test with Real Users

Friday is the payoff. Five customers interact with the prototype while the team watches, listens, and takes notes. By the end of the day, the team will have clear evidence of what works, what fails, and what to do next. The quality of Friday depends entirely on the quality of the interviews and the discipline of the observation.


## Table of Contents
1. [Schedule Overview](#schedule-overview)
2. [The Five-Act Interview Script](#the-five-act-interview-script)
3. [Interviewer Techniques](#interviewer-techniques)
4. [Observation Room Setup](#observation-room-setup)
5. [Pattern Recognition](#pattern-recognition)
6. [End-of-Sprint Debrief](#end-of-sprint-debrief)
7. [Templates](#templates)
8. [Common Friday Mistakes](#common-friday-mistakes)

---

## Schedule Overview

| Time | Activity | Duration |
|------|----------|----------|
| 9:00 - 9:30 | Setup interview and observation rooms | 30 min |
| 9:30 - 9:45 | Interviewer warm-up and team briefing | 15 min |
| 9:45 - 10:30 | Interview 1 | 45 min |
| 10:30 - 11:00 | Break and team discussion | 30 min |
| 11:00 - 11:45 | Interview 2 | 45 min |
| 11:45 - 12:15 | Break and team discussion | 30 min |
| 12:15 - 1:00 | Interview 3 | 45 min |
| 1:00 - 1:45 | Lunch | 45 min |
| 1:45 - 2:30 | Interview 4 | 45 min |
| 2:30 - 3:00 | Break and team discussion | 30 min |
| 3:00 - 3:45 | Interview 5 | 45 min |
| 3:45 - 5:00 | Pattern recognition and debrief | 75 min |

## The Five-Act Interview Script

### Act 1: Friendly Welcome (5 minutes)

**Goal:** Make the participant comfortable, set expectations, get consent.

**Script:**

"Hi, thanks for coming in today. My name is [name] and I will be walking you through some things we are working on. Before we begin, I want to make sure you know there are no right or wrong answers. We are testing the product, not you. If something is confusing, that is our fault, not yours.

I am going to ask you to think aloud as you go. Just tell me what you are looking at, what you are trying to do, and what you are thinking. This is really helpful for us.

We have a few people from the team watching in another room so they can hear your feedback directly. And with your permission, we would like to record the session so we can review it later. Is that okay?

Great. Do you have any questions before we start?"

### Act 2: Context Questions (5 minutes)

**Goal:** Understand the participant's background, current behavior, and mindset before showing the prototype.

**Example questions by product type:**

| Product Type | Context Questions |
|-------------|-------------------|
| Project management tool | "Tell me about how you currently keep track of projects at work. What tools do you use? What is frustrating about your current setup?" |
| E-commerce | "When was the last time you bought [category] online? Walk me through how you found and chose what to buy." |
| Healthcare app | "How do you currently manage your [condition]? What does a typical week look like?" |
| B2B platform | "Tell me about your role. When you need to [task], how do you handle that today?" |

### Act 3: Introduce the Prototype (5 minutes)

**Goal:** Show the entry point and observe the first impression without explaining anything.

**Script:**

"Now I am going to show you something we have been working on. Some parts might work, some might not. That is totally normal. I did not design this, so please be honest. You will not hurt my feelings.

[Show the first screen of the prototype]

Take a look at this. Without clicking anything, tell me: what is this? What do you think you can do here? Who do you think this is for?"

**Critical rule:** Do not explain the prototype. If they are confused, that is data. Let the silence sit. Resist the urge to help.

### Act 4: Tasks and Nudges (15 minutes)

**Goal:** Watch the participant attempt realistic tasks with the prototype.

**Setting up tasks:**

"Great. Now I would like you to try a few things. Remember, think aloud as you go."

**Task format:**

Use scenario-based tasks, not instructions:

| Weak Task (Avoid) | Strong Task (Use) |
|-------------------|-------------------|
| "Click the signup button" | "You heard about this from a friend and want to try it" |
| "Go to the pricing page" | "You are interested but need to figure out if it fits your budget" |
| "Create a new project" | "You just joined this tool and want to set up your first project for your marketing team" |
| "Find the search bar" | "You are looking for a specific type of [product]. How would you find it?" |

**Nudge techniques when the participant gets stuck:**

| Situation | Nudge |
|-----------|-------|
| Participant goes silent | "What are you thinking right now?" |
| Participant is stuck | "What would you expect to happen?" |
| Participant asks for help | "What would you try if I were not here?" |
| Participant clicks a dead end | "Interesting. In a real version, that would work. For now, let me take you to the next screen." |
| Participant goes off the path | "That is great feedback. For the next task, let me show you this screen." |

### Act 5: Debrief (5 minutes)

**Goal:** Capture the participant's overall impressions and ask targeted follow-up questions.

**Debrief questions:**

1. "What was your overall impression?"
2. "What stood out to you, either positively or negatively?"
3. "Who do you think this is for?"
4. "Would you use this? Why or why not?"
5. "How does this compare to what you use today?"
6. "If you could change one thing, what would it be?"

Also ask follow-up questions tied to your specific sprint questions. Close by asking if there is anything else they would like to share and thanking them for their time.

## Interviewer Techniques

### Staying Neutral

| Do | Do Not |
|----|--------|
| Nod and say "mm-hmm" | Say "great job" or "that is right" |
| Ask "tell me more about that" | Say "actually, you are supposed to click here" |
| Pause and let silence work | Fill silence with explanations |
| Mirror their words: "You said it felt confusing?" | Defend the design: "Well, the idea is that..." |
| Take notes on a pad | Type loudly on a laptop |

### The Power of Silence

When a participant pauses, wait at least 5 seconds before speaking. Most people will fill the silence with their thoughts, which are the most valuable data you can collect.

### Handling Difficult Moments

| Moment | Response |
|--------|----------|
| Participant says "I hate this" | "Tell me more. What specifically is not working for you?" |
| Participant gives only positive feedback | "If a friend asked you about this, what would you warn them about?" |
| Participant asks "Am I doing this right?" | "There is no right or wrong. What would you try?" |
| Participant is clearly frustrated | "I can see this is frustrating. That is really useful feedback. Let's move to the next thing." |
| Participant finishes too quickly | "Let's go back to [screen]. What were you thinking when you saw this?" |

## Observation Room Setup

### The Note-Taking Grid

Draw this on the whiteboard before the first interview:

```
                | Customer 1 | Customer 2 | Customer 3 | Customer 4 | Customer 5 |
|---------------|------------|------------|------------|------------|------------|
| First impression |         |            |            |            |            |
| [Screen/Task 1]  |        |            |            |            |            |
| [Screen/Task 2]  |        |            |            |            |            |
| [Screen/Task 3]  |        |            |            |            |            |
| [Key question 1] |        |            |            |            |            |
| [Key question 2] |        |            |            |            |            |
| Overall reaction |         |            |            |            |            |
```

**Row labels** come from the storyboard frames and sprint questions. Add 7-10 rows that correspond to the key moments you want to test.

### How to Take Notes

1. Each team member writes observations on sticky notes during the interview
2. Use one color per team member (so you can trace who observed what)
3. After each interview, place sticky notes in the appropriate grid cell
4. Mark each note with a symbol:
   - **Checkmark** for positive reactions, successful completions, or enthusiastic comments
   - **X** for negative reactions, failures, confusion, or complaints
   - **Tilde (~)** for neutral, mixed, or ambiguous reactions

## Pattern Recognition

### After All Five Interviews

1. Step back and look at the entire grid
2. Read across each row: do you see mostly checkmarks, mostly Xs, or a mix?
3. Highlight rows with strong patterns (4-5 of the same symbol)

### Pattern Categories

| Pattern | What It Means | Example |
|---------|--------------|---------|
| 5 checkmarks | Strong validation. This works | All 5 users understood the pricing immediately |
| 4 checkmarks, 1 X | Mostly works, investigate the outlier | 4 of 5 completed onboarding, 1 got stuck on step 3 |
| 3 checkmarks, 2 Xs | Mixed signal, needs refinement | Some users loved the AI suggestions, others did not trust them |
| 2 checkmarks, 3 Xs | Significant problem | Most users could not find the search function |
| 5 Xs | Clear failure. This does not work | Nobody understood the value proposition on the landing page |
| All tildes | Indifference (arguably worse than failure) | Users did not care about the feature either way |

### Minimum Viable Signal

- **3 out of 5** participants showing the same pattern is a meaningful signal
- **5 out of 5** is a strong signal that demands action
- **2 out of 5** is inconclusive and may require further testing

## End-of-Sprint Debrief

### Step 1: Review Sprint Questions (15 minutes)

Return to Monday's sprint questions. For each one:

1. Read the question aloud
2. Review the evidence from the grid
3. Determine the answer: Yes, No, Partially, or Inconclusive

**Template:**

```
Sprint Question: Will first-time users understand what our product does?
Evidence: 4/5 correctly described the product on first impression. 1 was confused by the headline.
Answer: Yes, with minor copy improvements needed.
```

### Step 2: Categorize Findings (20 minutes)

Organize all observations into three columns on the whiteboard:

**What Worked (keep and build on):**
- List specific screens, features, or copy that received consistent positive feedback
- Include direct quotes from participants

**What Failed (fix or remove):**
- List specific moments of confusion, frustration, or failure
- Note whether the failure was universal (5/5) or partial (3/5)

**Mixed Results (investigate further):**
- List elements with split reactions
- Note possible explanations for the split

### Step 3: Decide Next Steps (20 minutes)

| Friday Result | Recommended Next Step |
|--------------|----------------------|
| Core concept validated, minor issues | Build the product. Fix the specific issues identified |
| Core concept validated, major UX issues | Run a follow-up sprint focused on the problematic areas |
| Two concepts tested (Rumble), one won | Build the winner. Document why the other lost |
| Core concept failed, but insights gained | Pivot and run another sprint with a new approach |
| Everything failed | Go back to Monday. Redefine the problem. The week saved you months |
| Inconclusive results | Recruit 5 more users and test again, or rewrite the tasks |

## Templates

### Interview Notes Template (Per Participant)

```
Participant: #[number]    Date/Time: [date, time]

FIRST IMPRESSION
What they said:
Understood the product: [ ] Yes [ ] No [ ] Partially

TASK 1: [Description]
Completed: [ ] Yes [ ] No [ ] With help
Notable quotes:

TASK 2: [Description]
Completed: [ ] Yes [ ] No [ ] With help
Notable quotes:

OVERALL DEBRIEF
Would they use this: [ ] Yes [ ] No [ ] Maybe
Key quote:
```

### Sprint Results Summary Template

```
SPRINT: [Name]    DATE: [Week of]    TARGET: [Monday's target]

SPRINT QUESTIONS AND ANSWERS:
1. [Question] → [Answer with evidence]
2. [Question] → [Answer with evidence]
3. [Question] → [Answer with evidence]

WHAT WORKED:               WHAT FAILED:
- [Finding 1]              - [Finding 1]
- [Finding 2]              - [Finding 2]

NEXT STEPS:
- [ ] [Action item 1] — Owner: [Name] — Due: [Date]
- [ ] [Action item 2] — Owner: [Name] — Due: [Date]
```

## Common Friday Mistakes

### The Interviewer Explains the Prototype

**Problem:** When a user gets confused, the interviewer says "Oh, this is supposed to be a dashboard where you can..."
**Fix:** Practice the phrase "What would you expect to see here?" Let confusion happen. It is the most valuable data.

### The Team Watches Passively

**Problem:** The observation team watches interviews like a movie without taking notes.
**Fix:** Require sticky notes. Each person should produce 5-10 notes per interview. The grid on the whiteboard makes note-taking structured and accountable.

### Skipping the Debrief

**Problem:** After the last interview, the team is exhausted and says "let's process this next week."
**Fix:** The debrief is the most important hour of the entire sprint. Do it while observations are fresh. Waiting even one weekend degrades the team's memory and enthusiasm.

### Recruiting the Wrong Users

**Problem:** The team tests with colleagues, friends, or people who do not match the target customer.
**Fix:** Use a screener survey. Recruit people who match the customer profile defined on Monday. Test with strangers who have no loyalty to the team.

### Over-Indexing on One Participant

**Problem:** One user gave dramatic negative feedback and the team panics.
**Fix:** Wait for patterns. One negative reaction out of five may be an outlier. Three negative reactions out of five is a real signal.

# Monday: Map the Problem

Monday sets the foundation for the entire sprint. By the end of the day, the team will have a shared understanding of the problem, a map of the customer journey, and a clear target for the week. Every minute counts: poor Monday execution means the rest of the sprint drifts without direction.

## Schedule Overview

| Time | Exercise | Duration |
|------|----------|----------|
| 10:00 - 10:15 | Welcome and ground rules | 15 min |
| 10:15 - 10:45 | Long-term goal | 30 min |
| 10:45 - 11:30 | Sprint questions | 45 min |
| 11:30 - 12:30 | Customer journey map | 60 min |
| 12:30 - 1:30 | Lunch | 60 min |
| 1:30 - 3:30 | Ask the Experts | 120 min |
| 3:30 - 4:00 | How Might We organization | 30 min |
| 4:00 - 4:30 | Vote on HMWs | 30 min |
| 4:30 - 5:00 | Pick the target | 30 min |

## Welcome and Ground Rules

Before starting, the Sprint Master should set expectations for the week:

- No laptops or phones during exercises (breaks are fine)
- Silence during individual work phases
- The Decider has final say on all tie-breaking votes
- Timers are strict: when the bell rings, pencils down
- Write on sticky notes in thick marker so everyone can read from a distance
- Every voice matters, but talking happens in structured turns

## Long-Term Goal Exercise

### Purpose

Align the team on what success looks like. The long-term goal creates a north star that keeps every subsequent decision anchored.

### How to Facilitate

1. Hand everyone a sheet of paper
2. Ask: "Imagine it is two years from now. Our sprint was a massive success. What changed? What is true about our product, company, or customers?"
3. Give 5 minutes for individual writing (silence)
4. Go around the room. Each person reads their goal aloud
5. Sprint Master writes each goal on the whiteboard
6. Discuss for 10 minutes: where do we agree, where do we disagree?
7. The Decider picks one goal or combines two

### Example Long-Term Goals

| Company Type | Long-Term Goal |
|-------------|----------------|
| B2B SaaS | "Enterprise customers renew their contracts at 95%+ because the product is indispensable to their daily workflow" |
| E-commerce | "First-time buyers come back within 30 days and recommend us to friends" |
| Healthcare | "Patients manage their chronic conditions without needing to call the clinic" |
| Fintech | "Users trust us enough to consolidate all their finances in one place" |
| Education | "Students complete the full course and can demonstrate the skill in a real job" |

### What Makes a Good Goal

- Focuses on the customer, not internal metrics
- Describes a changed behavior or belief
- Is ambitious but plausible in 2 years
- Can be broken into testable assumptions

## Sprint Questions Exercise

### Purpose

Surface the risks, assumptions, and unknowns that could prevent the long-term goal. Sprint questions flip optimism into productive skepticism.

### How to Facilitate

1. Reframe the prompt: "To reach our goal, what has to be true? What could go wrong? What are we most uncertain about?"
2. Give 5 minutes for individual writing on sticky notes (one question per note)
3. Collect all sticky notes and read them aloud
4. Group similar questions on the whiteboard
5. The team votes (2 dot stickers each) on the most critical questions
6. The Decider selects the top 3 questions for the sprint to address

### Example Sprint Questions

- "Will users understand what our product does within 10 seconds of landing on the page?"
- "Can we convince busy professionals to complete a 5-step onboarding flow?"
- "Will customers pay a premium when a free alternative exists?"
- "Do users trust an AI recommendation enough to act on it?"
- "Can non-technical users configure the product without support?"

### Template

```
We believe [assumption].
If we are wrong, [consequence].
Sprint question: Will [specific user] actually [specific behavior]?
```

## Customer Journey Map

### Purpose

Create a shared visual model of how a customer moves from discovery to success. The map becomes the sprint's playing field.

### Step-by-Step Process

1. **Draw the frame:** A horizontal line across the whiteboard with "Discovery" on the left and "Success" on the right
2. **List the actors:** Write customer types and key players above the map (e.g., "New user," "Admin," "Sales rep")
3. **Map the steps:** The Sprint Master asks the team to call out each step. Write them left to right as simple boxes connected by arrows
4. **Keep it simple:** Aim for 5-15 steps. If it grows beyond 15, you are going too deep
5. **Use plain language:** "Sees an ad" not "Awareness phase targeting via programmatic display"

### Example Map: Project Management Tool

```
Hears from    Visits      Watches     Signs up    Creates      Invites     First       Weekly      Upgrades
colleague --> website --> demo    --> for free --> project  --> team    --> meeting --> routine --> to paid
                         video       trial                    members    review
```

### Common Mapping Mistakes

| Mistake | Problem | Fix |
|---------|---------|-----|
| Too many steps | Map becomes unreadable | Merge similar steps, stay at 5-15 |
| Internal process focus | Map shows your workflow, not the customer's | Always start with a customer action |
| Branching paths | Map becomes a flowchart | Pick one primary path; note alternatives as sticky notes |
| Skipping early steps | Map starts at "uses product" | Include how customers discover and evaluate |

## Ask the Experts

### Purpose

Bring specialized knowledge into the room. Experts share what they know so the team operates from facts, not assumptions.

### Who to Interview

- **CEO/Founder:** Vision, business constraints, strategic bets
- **Sales/Business Development:** What customers say before buying, common objections
- **Customer Support:** What customers complain about, where they get stuck
- **Engineering Lead:** Technical constraints, what is easy vs. hard to build
- **Marketing:** How customers find the product, messaging that resonates
- **External expert (optional):** Industry analyst, advisor, power user

### Interview Format

| Phase | Duration | What Happens |
|-------|----------|-------------|
| Introduction | 2 min | Sprint Master explains what we need from the expert |
| Expert presentation | 10 min | Expert shares their perspective on the challenge |
| Q&A | 10 min | Team asks clarifying questions |
| HMW notes | During all phases | Team writes How Might We notes in real time |

### Good Questions to Ask Experts

- "What is the number one reason customers leave?"
- "What do customers say they want that we do not offer?"
- "What surprised you most about how customers use the product?"
- "If you could fix one thing, what would it be?"
- "What would a competitor need to do to beat us?"

### Tips for the Sprint Master

- Keep each expert to 20 minutes total
- Gently redirect if the expert goes on tangents
- Remind the team to write HMW notes continuously
- Do not let one expert dominate Monday afternoon

## How Might We (HMW) Notes

### Purpose

Transform problems, insights, and complaints into opportunities. HMW notes reframe negatives as design challenges the team can solve.

### How to Write HMW Notes

1. Listen for problems, pain points, and unmet needs during expert interviews
2. Rephrase each one as "How might we...?" on a sticky note
3. Write in thick marker, one idea per note
4. Keep them concise: 5-10 words after "How might we"

### Conversion Examples

| What You Hear | HMW Note |
|--------------|----------|
| "Customers never finish onboarding" | HMW make onboarding feel worth completing? |
| "People don't understand our pricing page" | HMW make pricing instantly clear? |
| "Users create an account but never come back" | HMW give users a reason to return on day 2? |
| "Enterprise buyers need approval from 3 people" | HMW help champions sell internally? |
| "Support tickets spike every Monday" | HMW prevent the Monday confusion? |

### Common HMW Pitfalls

- **Too broad:** "HMW make the product better?" (not actionable)
- **Too narrow:** "HMW add a tooltip to the settings gear icon?" (already a solution)
- **Contains a solution:** "HMW add a chatbot?" (should be "HMW provide instant answers?")
- **Negative framing:** "HMW stop users from leaving?" (reframe: "HMW make users want to stay?")

### Organizing and Voting on HMWs

1. After expert interviews, collect all HMW notes (expect 30-80 notes)
2. Read each one aloud quickly (2-3 seconds each)
3. Organize on the whiteboard by theme (group similar notes together)
4. Place themed groups near the relevant part of the customer journey map
5. Give each person 2 dot stickers
6. Vote silently (no discussion during voting)
7. The Decider gets 4 dot stickers

## Target Selection

### Purpose

Choose the single moment on the customer journey map that the sprint will focus on. Without a target, the team tries to solve everything and solves nothing.

### How to Select the Target

1. Review the map with HMW clusters and vote dots visible
2. Look for the intersection of: high risk + high opportunity + answerable in one week
3. The Sprint Master asks: "Given our goal and our sprint questions, where should we focus?"
4. Brief discussion (10 minutes max, not a debate)
5. The Decider makes the final call

### Target Selection Criteria

| Criteria | Question to Ask |
|----------|----------------|
| Impact | "If we solve this, does it meaningfully move us toward the long-term goal?" |
| Risk | "Is this the area where we are most uncertain?" |
| Feasibility | "Can we prototype and test a solution for this in 4 days?" |
| Learning | "Will testing this answer our most important sprint question?" |

### Example Targets

- "The first 5 minutes after signup: do users understand what to do?"
- "The pricing page: do visitors understand the value and choose a plan?"
- "The handoff from sales demo to first login: do buyers become users?"
- "The weekly report: do managers find it useful enough to keep paying?"

## Monday Checklist

Before leaving for the day, confirm:

- [ ] Long-term goal is written on the whiteboard and agreed upon
- [ ] Top 3 sprint questions are identified and visible
- [ ] Customer journey map is complete (5-15 steps)
- [ ] At least 3 experts have been interviewed
- [ ] HMW notes are organized by theme on the map
- [ ] HMW votes are complete
- [ ] The Decider has chosen a target on the map
- [ ] Everyone knows the target and can explain it
- [ ] Tuesday agenda is confirmed

## Common Monday Mistakes

### Spending Too Long on the Goal

**Problem:** The team debates the long-term goal for 90 minutes, compressing everything else.
**Fix:** Time-box to 30 minutes. The goal does not need to be perfect; it needs to be directional. The Decider breaks ties.

### Mapping Internal Processes Instead of the Customer Journey

**Problem:** The map shows "engineering builds feature" and "QA tests" instead of the customer's experience.
**Fix:** Start every step with a customer verb: "Customer sees," "Customer clicks," "Customer decides."

### Expert Interviews That Turn Into Debates

**Problem:** The team argues with the expert instead of listening.
**Fix:** Sprint Master enforces a "no debating" rule. The team asks questions and writes HMW notes. Disagreements become sprint questions.

### Picking a Target That Is Too Broad

**Problem:** The target is "the entire user experience" or "our go-to-market strategy."
**Fix:** A good target fits on one section of the map. If you cannot prototype and test it in 4 days, narrow it down.

### Skipping HMW Notes

**Problem:** The team listens to experts but does not capture opportunities.
**Fix:** Remind the team every 10 minutes to write HMW notes. Provide sticky notes and markers on the table before interviews start.

### No Decider in the Room

**Problem:** The person with authority is "available by phone" or will "review the decisions tomorrow."
**Fix:** Do not start the sprint. The Decider must be present for all key decisions, especially target selection. Reschedule if necessary.

# User Recruitment for Design Sprints

Recruiting the right participants for Friday's interviews is one of the most important and most underestimated parts of the design sprint. Test with the wrong people and you get misleading feedback. Test with nobody and you wasted the week. Start recruiting at least two weeks before the sprint begins.


## Table of Contents
1. [Recruitment Timeline](#recruitment-timeline)
2. [Defining the Target Participant](#defining-the-target-participant)
3. [Screener Survey](#screener-survey)
4. [Where to Find Participants](#where-to-find-participants)
5. [Incentive Guidelines](#incentive-guidelines)
6. [Scheduling Logistics](#scheduling-logistics)
7. [No-Show Prevention](#no-show-prevention)
8. [Diverse Participant Selection](#diverse-participant-selection)
9. [Legal Considerations](#legal-considerations)
10. [Recruitment Checklist](#recruitment-checklist)

---

## Recruitment Timeline

| When | Action | Owner |
|------|--------|-------|
| Sprint minus 3 weeks | Define target participant profile with the team | Sprint Master + Decider |
| Sprint minus 2.5 weeks | Write screener survey | Sprint Master or Recruiter |
| Sprint minus 2 weeks | Post screener to recruitment channels | Recruiter |
| Sprint minus 10 days | Review screener responses, shortlist candidates | Recruiter |
| Sprint minus 8 days | Invite 8 candidates (6 primary + 2 backup) | Recruiter |
| Sprint minus 5 days | Confirm 6 participants, send calendar invitations | Recruiter |
| Sprint minus 2 days | Send reminder email with logistics (time, location, parking, contact) | Recruiter |
| Sprint minus 1 day | Send SMS reminder | Recruiter |
| Friday 8:00 AM | Send final "See you at [time]" text | Recruiter |

### Why 6 Participants for 5 Slots

Expect a 10-20% no-show rate even with the best recruitment process. Scheduling 6 ensures you hit 5 interviews. If all 6 show up, run the extra interview or pay the backup participant and thank them.

## Defining the Target Participant

### Start with the Sprint Target

The participant profile should match the customer type identified on Monday. Ask:

- Who is the target customer for the part of the journey we are testing?
- What demographics, behaviors, or roles define this person?
- What experience level should they have with the problem space?
- What experience level should they have with your product (if any)?

### Participant Profile Template

```
TARGET PARTICIPANT PROFILE

Role/Title: [e.g., Marketing manager at a company with 50-200 employees]
Experience: [e.g., Has used at least 2 project management tools in the past year]
Behavior: [e.g., Currently manages 3+ active projects simultaneously]
Excluded: [e.g., Not a current customer, not a competitor employee, not in the tech industry]
Nice to have: [e.g., Mix of genders, age 25-55, different company sizes]
```

### Common Participant Types

| Sprint Focus | Ideal Participant |
|-------------|-------------------|
| Consumer app onboarding | People who match the target demographic and have never seen the product |
| B2B SaaS feature | Professionals in the target role who currently use a competitor |
| E-commerce redesign | People who have purchased similar products online in the past 90 days |
| Healthcare product | Patients with the target condition or caregivers who manage it |
| Internal tool | Employees in the target department who would use the tool daily |

## Screener Survey

### Purpose

A screener survey filters applicants so you interview only people who match your target profile. It should take 2-3 minutes to complete and disqualify people who do not fit.

### Screener Survey Template

```
SCREENER SURVEY: [Sprint Name]

Thank you for your interest in participating in a product feedback session.
This survey takes about 2 minutes.

1. What is your current job title?
   [Open text]

2. How many people work at your company?
   ( ) 1-10
   ( ) 11-50
   ( ) 51-200
   ( ) 201-1000
   ( ) 1000+

3. Which of the following tools do you currently use? (Select all that apply)
   [ ] Tool A
   [ ] Tool B
   [ ] Tool C
   [ ] None of the above

4. How often do you [target behavior]?
   ( ) Daily
   ( ) Weekly
   ( ) Monthly
   ( ) Rarely
   ( ) Never

5. Have you used [your product name] before?
   ( ) Yes, currently use it
   ( ) Yes, used it in the past
   ( ) No, never used it
   ( ) I have heard of it but never tried it

6. On a scale of 1-5, how frustrated are you with your current solution for [problem]?
   ( ) 1 - Not at all frustrated
   ( ) 2
   ( ) 3
   ( ) 4
   ( ) 5 - Extremely frustrated

7. Are you available on [Friday date] between [time range] for a 45-minute in-person/video session?
   ( ) Yes
   ( ) No

8. What is the best email address to reach you?
   [Open text]

9. What is your phone number? (for scheduling confirmation only)
   [Open text]
```

### Scoring the Screener

Create a scoring rubric before reviewing responses:

| Question | Ideal Answer | Points |
|----------|-------------|--------|
| Job title | Matches target role | 2 |
| Company size | Matches target segment | 1 |
| Tools used | Uses competitor (not your product) | 2 |
| Behavior frequency | Daily or weekly | 2 |
| Prior product experience | Never used or heard of it | 2 |
| Frustration level | 3 or higher | 1 |
| Availability | Yes | Required (disqualify if no) |

**Threshold:** Invite participants who score 7+ out of 10.

## Where to Find Participants

### B2C Products

| Channel | Pros | Cons | Cost |
|---------|------|------|------|
| Social media ads (Instagram, Facebook) | Fast, targetable | Lower quality, may attract "professional testers" | $50-200 in ad spend |
| Craigslist / local classifieds | Cheap, fast | Unpredictable quality | Free + incentive |
| Community groups (Reddit, Discord, Facebook Groups) | Engaged, relevant | May skew toward power users | Free + incentive |
| Intercept at physical locations (coffee shops, stores) | Real people in natural context | Time-consuming, limited volume | Free + incentive |
| Customer email list (non-current-users segment) | Pre-qualified interest | May bias toward people already favorable | Free + incentive |

### B2B Products

| Channel | Pros | Cons | Cost |
|---------|------|------|------|
| LinkedIn outreach | Highly targetable by role and company | Low response rate (5-10%) | Free + incentive |
| Industry events and meetups | Engaged professionals | Timing dependent | Free + incentive |
| Professional associations | Quality participants | Slow process | Varies |
| Recruitment platforms (see below) | Reliable, pre-screened panels | Expensive | $150-300 per participant |
| Partner introductions | Warm leads, high quality | Favors existing relationships | Free + incentive |
| Sales team referrals (non-customers) | Know the persona well | May introduce bias | Free + incentive |

### Recruitment Platforms

| Platform | Best For | Cost Per Participant | Turnaround |
|----------|----------|---------------------|------------|
| UserTesting | Quick unmoderated studies; also supports moderated | $30-100 (unmoderated), $150+ (moderated) | 1-3 days |
| Respondent.io | B2B and niche audiences | $100-300 (B2B), $50-100 (B2C) | 3-7 days |
| User Interviews | Broad consumer and B2B panels | $50-150 | 2-5 days |
| Ethnio | Intercept recruiting from your own website | $50-100 + subscription | 1-7 days |
| Prolific | Academic-quality panels, diverse demographics | $10-30 | 1-2 days |

## Incentive Guidelines

### How Much to Pay

| Participant Type | Recommended Incentive | Format |
|-----------------|----------------------|--------|
| General consumer | $50-75 for 45 minutes | Gift card (Amazon, Visa) |
| Professional (B2B, mid-level) | $100-150 for 45 minutes | Gift card or direct payment |
| Senior executive (VP+) | $200-300 for 45 minutes | Donation to charity of choice or gift card |
| Medical professional | $200-400 for 45 minutes | Direct payment |
| Hard-to-reach niche | $150-300+ for 45 minutes | Whatever the market demands |

### Incentive Principles

- Pay enough to attract quality participants, not so much that people lie on the screener to qualify
- Pay immediately after the session (do not make them wait for a check in the mail)
- Digital gift cards are the easiest to distribute
- For B2B executives, offering a "donation to the charity of your choice" can be more effective than a personal payment
- Always pay no-shows if they gave 24-hour notice of cancellation (it maintains your reputation)

## Scheduling Logistics

### Time Slot Structure

| Slot | Time | Purpose |
|------|------|---------|
| 1 | 9:45 - 10:30 | Interview 1 |
| Buffer | 10:30 - 11:00 | Team discussion, notes |
| 2 | 11:00 - 11:45 | Interview 2 |
| Buffer | 11:45 - 12:15 | Team discussion, notes |
| 3 | 12:15 - 1:00 | Interview 3 |
| Lunch | 1:00 - 1:45 | Break |
| 4 | 1:45 - 2:30 | Interview 4 |
| Buffer | 2:30 - 3:00 | Team discussion, notes |
| 5 | 3:00 - 3:45 | Interview 5 |
| 6 (backup) | 4:00 - 4:45 | Backup slot if a morning participant no-showed |

### Confirmation Messages

**Initial invitation email:** Thank the participant for completing the survey. Include the date, time, location (or video link), duration (45 minutes), incentive amount, and a request to confirm by reply.

**Reminder (2 days before):** Restate date, time, location, duration, and incentive. Include your phone number. Ask them to let you know if they can no longer make it so you can offer their spot to someone else.

## No-Show Prevention

### Tactics That Reduce No-Shows

| Tactic | Impact |
|--------|--------|
| Require confirmation reply (not just calendar accept) | High |
| Send 3 reminders (confirmation, 2-day, morning-of) | High |
| Include your personal phone number in communications | Medium |
| Offer to reschedule if they have a conflict | Medium |
| Over-recruit by 1-2 participants | High (mitigates no-shows) |
| Ask for their phone number and text the morning of | High |
| Make the incentive attractive enough | Medium |

### What to Do When Someone No-Shows

1. Wait 10 minutes past the scheduled time
2. Send a text: "Hi [Name], we are ready for you at [location]. Are you on your way?"
3. If no response after 5 more minutes, move on
4. Shift the schedule: pull the backup participant into the empty slot
5. If no backup is available, run 4 interviews instead of 5 (still produces patterns)

## Diverse Participant Selection

### Why Diversity Matters

If all 5 participants are 30-year-old tech workers in San Francisco, you are testing with a narrow slice of your potential customer base. Diverse participants reveal a wider range of reactions, accessibility issues, and cultural considerations.

### Diversity Dimensions to Consider

- Age range (not all 25-35)
- Gender balance
- Technical proficiency (mix of tech-savvy and less technical)
- Geographic location (if testing remotely)
- Company size and industry (for B2B)
- Accessibility needs (include at least one participant who uses assistive technology, if relevant)

### Practical Approach

You only have 5 participants, so you cannot represent every dimension. Pick 2-3 diversity factors that are most relevant to your product and ensure variation across those factors.

## Legal Considerations

### Recording Consent

Before recording any interview:

1. Inform the participant that the session will be recorded (audio and video)
2. Explain how the recording will be used (internal review only)
3. Get verbal consent on camera: "Do I have your permission to record this session?"
4. If using a written consent form, have them sign before the interview begins

### Key Legal Points

- **Consent form:** Cover audio/video recording, internal-only use of recordings, right to stop the session at any time, and guaranteed incentive regardless of completion. Have participants sign before the interview begins.
- **NDAs:** Use a simple one-page NDA for pre-launch products. Do not require one for public products. If a participant refuses, pay them and do not show the prototype.
- **Data privacy:** Collect only what is needed, store securely, delete recordings within 30 days, and comply with GDPR/CCPA or relevant local regulations.

## Recruitment Checklist

### 3 Weeks Before Sprint

- [ ] Target participant profile defined
- [ ] Screener survey written and tested
- [ ] Recruitment channels identified
- [ ] Budget approved for incentives and recruitment platform fees

### 2 Weeks Before Sprint

- [ ] Screener posted to recruitment channels
- [ ] Responses are being reviewed daily
- [ ] Shortlist of candidates created

### 1 Week Before Sprint

- [ ] 6 participants confirmed (5 primary + 1 backup)
- [ ] Calendar invitations sent with all logistics
- [ ] Consent forms prepared
- [ ] Incentives purchased (gift cards, etc.)

### 2 Days Before Sprint

- [ ] Reminder emails sent to all participants
- [ ] Backup participant confirmed

### Friday Morning

- [ ] Morning-of text messages sent
- [ ] Interview room set up
- [ ] Consent forms printed
- [ ] Incentives ready to distribute
- [ ] Backup plan in place for no-shows

# Remote Design Sprints

Running a design sprint with a distributed team requires deliberate adaptation of every exercise. The core principles remain the same: time-box, work individually, let the Decider decide, prototype, and test. But the tools, energy management, and communication patterns must change to account for screen fatigue, time zones, and the absence of a shared physical space.


## Table of Contents
1. [Tool Stack](#tool-stack)
2. [Time Zone Considerations](#time-zone-considerations)
3. [Adapting Each Day for Remote](#adapting-each-day-for-remote)
4. [Compressed Schedule Options](#compressed-schedule-options)
5. [Remote-Specific Exercise Adaptations](#remote-specific-exercise-adaptations)
6. [Energy Management for Remote Participants](#energy-management-for-remote-participants)
7. [Async vs Sync Quick Reference](#async-vs-sync-quick-reference)
8. [Remote Prototype Testing Tools](#remote-prototype-testing-tools)
9. [Common Remote Sprint Failures and Fixes](#common-remote-sprint-failures-and-fixes)
10. [Remote Sprint Checklist](#remote-sprint-checklist)

---

## Tool Stack

### Essential Tools

| Purpose | Recommended Tool | Why |
|---------|-----------------|-----|
| Digital whiteboard | Miro or FigJam | Replaces physical whiteboards for mapping, HMWs, voting |
| Video conferencing | Zoom or Google Meet | Screen sharing, breakout rooms, recording |
| Prototyping | Figma | Real-time collaboration, easy sharing for testing |
| Async video | Loom | Lightning Demos, expert interviews that can be watched asynchronously |
| Chat | Slack or Teams | Side channel for logistics, questions, and sharing links |
| Timer | Cuckoo.team or Toggl Timer | Shared visible timer that all participants see |
| File sharing | Google Drive or Notion | Central place for templates, assets, and outputs |

### Miro/FigJam Board Setup

Create a single board for the entire sprint with clearly labeled sections:

```
+-------------------+-------------------+-------------------+
|     MONDAY        |     TUESDAY       |    WEDNESDAY      |
| - Long-term goal  | - Lightning Demos | - Art Museum      |
| - Sprint questions| - Sketch uploads  | - Heat map        |
| - Customer map    |                   | - Straw poll      |
| - HMW notes       |                   | - Storyboard      |
| - Target          |                   |                   |
+-------------------+-------------------+-------------------+
|     THURSDAY      |      FRIDAY       |     PARKING LOT   |
| - Prototype link  | - Note-taking     | - Unresolved      |
| - Interview script|   grid            |   questions       |
| - Trial run notes | - Patterns        | - Future ideas    |
|                   | - Next steps      |                   |
+-------------------+-------------------+-------------------+
```

Pre-populate each section with templates, instructions, and placeholder sticky notes before the sprint begins.

## Time Zone Considerations

### Single Time Zone (All Participants Within 2 Hours)

Run the sprint at normal hours for the majority. Adjust start/end times by 30-60 minutes to accommodate the edges.

### Two Time Zones (3-6 Hours Apart)

| Approach | Schedule |
|----------|----------|
| Overlap window | Find the 4-5 hour window where both zones are in working hours. Run all synchronous exercises during this window |
| Extended async | Use 2-3 hours of sync time per day and shift more exercises to async |

**Example: New York (EST) + London (GMT), 5-hour difference:**

| Time (EST) | Time (GMT) | Activity |
|------------|------------|----------|
| 8:00 AM | 1:00 PM | Sync block begins |
| 8:00 - 8:30 | 1:00 - 1:30 | Recap and framing |
| 8:30 - 11:30 | 1:30 - 4:30 | Core exercises (sync) |
| 11:30 - 12:00 | 4:30 - 5:00 | Wrap-up and async assignments |
| 12:00 - 2:00 | 5:00+ (done) | US team does async work |

### Three or More Time Zones (7+ Hours Apart)

A fully synchronous 5-day sprint is impractical. Use compressed schedules (see below), heavy async with short sync check-ins, or extend the sprint across 7-8 calendar days.

## Adapting Each Day for Remote

### Remote Monday: Map

**Sync exercises:**
- Long-term goal (30 min, video call, everyone writes in Miro simultaneously)
- Sprint questions (30 min, same format)
- Customer journey map (45 min, Sprint Master draws in Miro while team directs)

**Async exercises:**
- Expert interviews can be pre-recorded on Loom (10-15 min each, team watches on their own time)
- HMW notes: each person adds sticky notes to the Miro board asynchronously after watching expert videos

**Sync decision:**
- HMW voting (15 min, use Miro's built-in voting feature)
- Target selection with Decider (15 min, video call)

### Remote Tuesday: Sketch

**Sync exercises:**
- Lightning Demos (45 min, each person shares screen for 3 minutes)

**Async exercises:**
- Notes phase (20 min, everyone reviews the Miro board on their own)
- Ideas phase (20 min, individual work)
- Crazy 8s (8 min, individual work, upload photos of paper sketches)
- Solution Sketch (60-90 min, individual work)

**How to handle sketches remotely:**
1. Sketch on paper with a thick marker (same as in-person)
2. Photograph each panel with a phone
3. Upload to the designated Miro area by a set deadline
4. Each sketch gets its own frame in Miro, numbered and anonymous

Set a firm deadline for sketch uploads. The Sprint Master confirms receipt of all sketches. No one views others' sketches until Wednesday.

### Remote Wednesday: Decide

**Sync exercises (these must be synchronous):**
- Art Museum: everyone silently reviews sketches in Miro, placing dot stickers (20 min)
- Speed Critique: Sprint Master shares screen and narrates each sketch (3 min per sketch)
- Straw Poll: everyone places their vote simultaneously in Miro (5 min)
- Supervote: Decider places their votes (5 min)

**Async/sync exercises:**
- Storyboard: can be done with the Sprint Master building in Miro while the team provides direction on a video call, or the Sprint Master can draft it async and get sync approval

**Remote Wednesday tips:**
- The Art Museum works surprisingly well in Miro: participants browse and place dots silently
- During Speed Critique, the Sprint Master must share screen and control the zoom/navigation
- Use a different color dot for each participant to track who voted for what
- The Decider should be present for the entire sync session

### Remote Thursday: Prototype

**Sync exercises:**
- Morning kick-off: assign roles and divide storyboard (30 min)
- Mid-day check-in (15 min)
- End-of-day review: walk through prototype together (30 min)
- Trial run (30 min)

**Async work:**
- Building the prototype (individual or paired work in Figma)
- Writing copy (Writer works independently, shares in Slack)
- Gathering assets (Collector works independently)
- Writing the interview script (Interviewer works independently)

**Remote Thursday tips:**
- Figma's real-time collaboration makes remote prototyping nearly as efficient as in-person
- The Stitcher should set up the Figma file structure before the morning kick-off
- Use a shared Slack channel for quick questions and asset sharing
- The Sprint Master should check in every 90 minutes via a quick standup message

### Remote Friday: Test

**Interview options:**
- Video call interview (Zoom, Google Meet) with the participant sharing their screen
- Unmoderated testing platform (UserTesting.com, Maze) for asynchronous feedback
- Moderated video call is strongly preferred for design sprints

**Observation setup:**
- All observers join a separate "observation" Zoom call
- The Interviewer conducts the interview on the main call
- Screen share from the Interviewer's call is piped to the observation call
- Observers take notes in the shared Miro grid (same format as in-person)
- Use a shared chat channel for observers to flag interesting moments in real time

**Remote Friday tips:**
- Test the video/audio setup 24 hours before the first interview
- Send participants a test link to verify their screen sharing works
- Have a backup plan if a participant cannot share their screen (the Interviewer controls the prototype and asks the participant to direct them)
- Between interviews, do a quick 5-minute debrief on the observation call

## Compressed Schedule Options

### 4-Day Sprint

Combine Monday and Tuesday into a single day by compressing exercises and using async pre-work.

| Day | Activities |
|-----|-----------|
| Pre-work (async) | Expert interviews via Loom, Lightning Demos recorded and shared |
| Day 1 (Mon) | Long-term goal, sprint questions, map, HMW, target + Notes, Ideas, Crazy 8s, Solution Sketch |
| Day 2 (Tue) | Art Museum, Speed Critique, Voting, Storyboard |
| Day 3 (Wed) | Prototype |
| Day 4 (Thu) | Test and debrief |

**4-day sprint trade-offs:**
- Day 1 is very long and intense (8-9 hours of focused work)
- Less time for expert interviews (use async pre-recorded format)
- Solution sketches have less incubation time
- Works best for experienced sprint teams

### 3-Day Sprint

Requires significant async pre-work (expert interviews, Lightning Demos, goal/questions drafts done 1 week before). Day 1 covers finalize/map/sketch/decide. Day 2 is prototyping. Day 3 is testing and debrief. Works for focused problems where the team has deep context. Not recommended for first-time sprints.

## Remote-Specific Exercise Adaptations

### Dot Voting in Miro

1. Create a "voting" frame in the Miro board
2. Give each participant a set number of colored dots (use Miro's sticker feature or small circles)
3. Set a timer (visible to all via the shared timer)
4. Lock the board after voting to prevent late changes
5. Use Miro's "hide cursors" feature during voting to prevent following behavior

### Crazy 8s: Remote Version

Sketch on paper with a thick marker (same as in-person), photograph each panel, and upload to the designated Miro area. The Sprint Master counts down each minute on the video call. Paper and photograph is strongly preferred over digital sketching in Miro because the physical act of folding and drawing creates energy that digital tools cannot replicate.

### Storyboard: Remote Version

The Sprint Master builds the storyboard in Miro while the team provides direction over video call. The Sprint Master shares their screen, draws each frame based on team input, and controls the final layout. Alternatively, assign one person to draft the storyboard async and review sync the next morning.

## Energy Management for Remote Participants

### Screen Fatigue Is Real

Remote sprints are more exhausting than in-person sprints because video calls require more cognitive effort than face-to-face conversation. Plan for it.

### Remote Energy Tactics

| Tactic | Implementation |
|--------|---------------|
| Camera breaks | Turn cameras off during individual work, on during group work |
| Shorter sync blocks | Max 90 minutes of sync time before a break |
| Physical movement | 5-minute stretch break every 60 minutes |
| Async work blocks | Alternate between sync discussion and async individual work |
| Music during silent work | Sprint Master plays music via screen share or shares a playlist link |
| Chat engagement | Use emoji reactions in chat to maintain energy without interrupting |

### Daily Structure for Remote Energy

```
Sync block 1 (90 min) → Break (15 min) → Async work (60 min) →
Sync block 2 (60 min) → Lunch (60 min) → Async work (90 min) →
Sync block 3 (60 min) → Break (15 min) → Wrap-up sync (15 min)
```

This structure limits total sync time to approximately 3.5 hours per day while maintaining 6-7 hours of productive sprint work.

## Async vs Sync Quick Reference

**Must be sync:** Long-term goal discussion, customer journey map, all voting (HMW, Art Museum, straw poll, supervote), speed critique, user interviews, debrief.

**Can be async:** Expert interviews (Loom), HMW note writing, four-step sketch, prototype building, asset gathering, copy writing.

**Either way:** Lightning Demos (sync is more energetic, async Loom works for time zone conflicts), storyboard (Sprint Master can draft async, team reviews sync).

## Remote Prototype Testing Tools

**Moderated (recommended):** Zoom + Figma prototype link (participant shares screen), Lookback, or UserZoom.

**Unmoderated (backup):** Maze, UserTesting, or Useberry. Use when you cannot schedule 5 participants on the same day or time zones make live interviews impossible. Trade-off: no follow-up questions, less natural think-aloud, and you miss body language.

## Common Remote Sprint Failures and Fixes

### Multitasking During Sync Sessions

**Problem:** Participants check email, Slack, or work on other tasks during video calls.
**Fix:** Set a ground rule on Day 1: close all other tabs and apps during sync time. Use frequent engagement tactics: polls, voting, round-robin sharing. Keep sync blocks under 90 minutes. The Sprint Master calls on people by name regularly.

### Poor Audio/Video Quality

**Problem:** Participants join from noisy environments or with bad connections, disrupting the flow.
**Fix:** Require headphones with a microphone. Test audio/video setup the day before the sprint. Have a backup plan: phone dial-in for audio if video fails. Encourage wired internet connections over WiFi for stability.

### Miro Board Chaos

**Problem:** The Miro board becomes a mess of overlapping sticky notes, orphaned elements, and unclear structure.
**Fix:** The Sprint Master sets up the board with clear sections, labels, and locked background elements before the sprint. Only the Sprint Master should move structural elements. Use frames to contain each exercise. Lock completed sections so they are not accidentally edited.

### Lost Momentum Between Days

**Problem:** In a physical sprint, the room and the walls full of work maintain continuity. Remotely, people close their laptop and lose context overnight.
**Fix:** Start each day with a 10-minute recap. The Sprint Master walks through the Miro board, highlighting where the team left off and what happens today. Send a short end-of-day summary via Slack or email with a screenshot of the day's output.

### Sketches Are Hard to Read When Photographed

**Problem:** Participants upload blurry or poorly lit photos of their paper sketches, making the Art Museum difficult.
**Fix:** Require thick black markers (thin pens do not photograph well). Provide instructions for photographing: lay the paper flat, use good lighting, crop to the sketch only. Alternatively, allow digital sketching in Miro for participants who prefer it.

### The Decider Is Not Fully Engaged

**Problem:** The Decider joins for 10 minutes and then drops off, leaving key decisions hanging.
**Fix:** Before the sprint, get the Decider's explicit commitment to attend all voting and decision sessions. Create a "Decider schedule" showing the specific times they are needed (typically 30-60 minutes per day, not the full day). If the Decider cannot commit, postpone the sprint.

### Time Zone Conflicts Kill Participation

**Problem:** Team members in distant time zones attend at inconvenient hours and contribute less.
**Fix:** Identify the minimum overlap window and schedule all critical sync activities there. Shift the burden of inconvenience across the week. Use async exercises to maximize contribution from all time zones.

### Friday Testing Feels Disconnected

**Problem:** The team watches user interviews on video but does not feel the energy and immediacy of in-person observation.
**Fix:** Use a dedicated observation channel where team members react and note observations in real time. Between each interview, do a live 5-minute debrief on video.

## Remote Sprint Checklist

- [ ] Tool accounts set up for all participants (Miro, Zoom, Figma)
- [ ] Miro board pre-populated with templates and structure
- [ ] Sprint schedule adjusted for time zones
- [ ] Async vs sync plan communicated to all participants
- [ ] Tech check completed (audio, video, screen sharing)
- [ ] Supplies shipped to remote participants (thick markers, blank paper, sticky notes)
- [ ] Each day starts with a 10-minute recap and board walkthrough
- [ ] Sync blocks limited to 90 minutes before a break
- [ ] All outputs captured in the Miro board
- [ ] End-of-day summary sent to all participants
- [ ] Friday participants confirmed and tested for screen sharing
- [ ] Observation channel set up (separate from interview call)
- [ ] Note-taking grid created in Miro

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

# Tuesday: Sketch Solutions

Tuesday is about generating solutions, not discussing them. The day shifts from group understanding (Monday) to individual creation. By the end of Tuesday, every team member will have produced a detailed, self-explanatory solution sketch. The critical rule: work alone, think deeply, and let the ideas compete on Wednesday.

## Schedule Overview

| Time | Exercise | Duration |
|------|----------|----------|
| 10:00 - 10:15 | Recap Monday target | 15 min |
| 10:15 - 11:30 | Lightning Demos | 75 min |
| 11:30 - 12:00 | Divide or Swarm decision | 30 min |
| 12:00 - 1:00 | Lunch | 60 min |
| 1:00 - 1:20 | Notes (Step 1) | 20 min |
| 1:20 - 1:40 | Ideas (Step 2) | 20 min |
| 1:40 - 1:50 | Crazy 8s (Step 3) | 10 min |
| 1:50 - 3:20 | Solution Sketch (Step 4) | 90 min |
| 3:20 - 3:30 | Collect and seal sketches | 10 min |

## Lightning Demos

### Purpose

Borrow ideas from existing products, competitors, and unrelated industries. Lightning Demos fill the creative tank before sketching begins.

### Preparation (Before Tuesday)

At the end of Monday, ask each team member to:

- Find 2-3 products or features that solve a similar problem (even from different industries)
- Bookmark them or take screenshots
- Prepare a 3-minute walkthrough

### How to Run Lightning Demos

1. Each person gets 3 minutes to demo what they found
2. Show the product on screen or walk through screenshots
3. Explain: "Here is what they do, and here is what I think is interesting about it"
4. The Sprint Master captures the big idea on the whiteboard with a quick sketch and label
5. No debate or critique during demos. Just capture

### What to Look For

| Source | What to Capture |
|--------|----------------|
| Direct competitors | Features they got right, messaging that resonates |
| Adjacent industries | Interaction patterns that solve a similar problem differently |
| Non-tech examples | Retail, hospitality, or service experiences that feel effortless |
| Internal products | Other features in your own product that work well |
| Academic/research | Frameworks or data that could inspire a novel approach |

### Example Lightning Demos

**Sprint target:** Improve onboarding for a project management tool.

- **Demo 1 (Trello):** "They show a sample board pre-filled with tasks so you immediately see how it works. The big idea: show, don't tell."
- **Demo 2 (Duolingo):** "They get you doing a lesson within 30 seconds, before even creating an account. The big idea: delay signup, lead with value."
- **Demo 3 (IKEA store layout):** "They force a path through the showroom so you see everything in context. The big idea: guided tour instead of open exploration."

### Capture Format

On the whiteboard, create a grid:

```
[Quick sketch]     [Quick sketch]     [Quick sketch]
"Show, don't       "Delay signup,     "Guided tour
 tell" - Trello     lead with value"   path" - IKEA
                    - Duolingo
```

Each entry has a simple sketch and a 3-5 word label. By the end of Lightning Demos, you should have 10-20 captured ideas on the whiteboard.

## Divide or Swarm

### When to Divide

If the target area on Monday's map has clearly separable components, assign different people to different sections.

**Example:** If the target is "signup through first project," one group could tackle signup, another could tackle the first project experience.

### When to Swarm

If the target is a single, focused problem, everyone works on the same challenge independently.

**Most sprints use Swarm.** When in doubt, swarm. Having 5-7 different approaches to the same problem produces richer options.

## The Four-Step Sketch

This is the core of Tuesday. Four progressively focused exercises move each person from reviewing existing ideas to creating a detailed solution. All four steps are done individually and in silence.

### Step 1: Notes (20 minutes)

**What to do:**

1. Walk around the room silently
2. Review the whiteboard: long-term goal, sprint questions, customer journey map, HMW clusters, Lightning Demo captures
3. Take notes on paper about anything that catches your attention
4. Copy interesting ideas, jot down thoughts, highlight constraints

**Tips:**

- Use pen and paper, not a laptop
- Do not organize your notes; just capture raw material
- Pay special attention to the target area on the map
- Review the sprint questions: your sketch should try to answer at least one

### Step 2: Ideas (20 minutes)

**What to do:**

1. Start doodling rough ideas on paper
2. Stick figures, flow diagrams, wireframes, word clouds: anything goes
3. Generate as many ideas as possible
4. Do not self-edit: ugly and half-baked is fine
5. Explore different directions, not just one

**Tips:**

- Set a personal goal of at least 8 distinct ideas
- Mix practical ideas with wild ones
- Think about the problem from the customer's perspective
- Consider ideas from Lightning Demos: how might you adapt them?

### Step 3: Crazy 8s (8 minutes)

**What to do:**

1. Take a blank sheet of paper
2. Fold it in half three times to create 8 panels
3. Set a timer for 8 minutes
4. In each panel, sketch one variation of your best idea (1 minute per panel)
5. When the timer rings, stop immediately

**Detailed Instructions:**

| Panel | Time | Focus |
|-------|------|-------|
| 1 | 0:00 - 1:00 | Your best idea, simplest version |
| 2 | 1:00 - 2:00 | Same idea, different layout or flow |
| 3 | 2:00 - 3:00 | What if the user starts at a different point? |
| 4 | 3:00 - 4:00 | What if there were fewer steps? |
| 5 | 4:00 - 5:00 | What if it were more visual, less text? |
| 6 | 5:00 - 6:00 | What would the competitor version look like? |
| 7 | 6:00 - 7:00 | What is the most radical version? |
| 8 | 7:00 - 8:00 | Combine the best elements from panels 1-7 |

**Why Crazy 8s Matter:**

- Forces you past your first idea (which is rarely the best)
- Creates variations that lead to unexpected combinations
- The time pressure shuts down perfectionism
- Panel 8 often produces the breakthrough

**Common Crazy 8s Mistakes:**

- Drawing the same idea 8 times with trivial changes (push for real variation)
- Spending 4 minutes on panel 1 and rushing the rest (use a timer that beeps every minute)
- Giving up because you "can't draw" (stick figures and words are enough)

### Step 4: Solution Sketch (60-90 minutes)

**What to do:**

1. Take 3 sheets of blank paper (or a large sheet divided into 3 panels)
2. Create a 3-panel storyboard showing a customer's experience with your solution
3. Panel 1: What triggers the customer to encounter your solution?
4. Panel 2: How does the customer interact with the core of your solution?
5. Panel 3: What is the result? What does success look like?

**Solution Sketch Requirements:**

- [ ] Self-explanatory: someone who was not in the room should understand it
- [ ] Has a catchy title at the top
- [ ] Anonymous: no name on the sketch
- [ ] Detailed enough to build: include button labels, headlines, key copy
- [ ] Shows the flow: arrows or numbered steps indicating sequence
- [ ] Fits the target from Monday

### 3-Panel Storyboard Structure

**Panel 1: Entry Point**

What the customer sees first. Could be:
- A search result
- An email
- A notification
- A landing page
- A colleague's recommendation

Draw the screen, message, or moment. Include real text, not "lorem ipsum."

**Panel 2: Core Interaction**

The heart of your solution. Show:
- What the interface looks like
- What the customer does (clicks, types, drags)
- What information they see
- How they progress through the experience

This panel often needs the most detail. Use annotations and callouts.

**Panel 3: Outcome**

The result of using your solution:
- What does the customer see when they succeed?
- How do they feel? What confirmation do they get?
- What happens next?

### Example Solution Sketch: Onboarding for a Project Management Tool

- **Panel 1 "Welcome Screen":** Greeting by name, question about use case (Marketing / Engineering / Design), "Get started" button. Sets context.
- **Panel 2 "Guided Setup":** Name your first project field, invite team members field, note that starter tasks are auto-generated based on use case selection. Shows the core interaction.
- **Panel 3 "Your First Win":** Project board with pre-filled tasks, one already marked done, confetti animation, "Share with your team" call to action. Shows the successful outcome.

## Tips for Non-Designers

### You Do Not Need to Draw Well

Solution sketches are about ideas, not artistry. Use:

- **Rectangles** for screens and containers
- **Lines** for text (squiggly lines = body text)
- **Circles and arrows** for buttons and navigation
- **Stick figures** for people
- **Words** for headlines, labels, and key copy

### Focus on These Elements

1. **Headlines:** What does the customer read first?
2. **Key actions:** What button do they click? What do they type?
3. **Information hierarchy:** What is biggest/most prominent?
4. **Flow:** Where does the customer go from each step?
5. **Copy:** Write real words, not placeholder text

### If You Are Stuck

- Return to the Lightning Demo wall and adapt an idea
- Solve for one specific sprint question
- Draw your favorite competitor's approach, then change three things
- Think about the worst possible version, then invert it
- Start from the outcome (Panel 3) and work backwards

## Collecting Sketches

At the end of Tuesday:

1. Everyone places their solution sketch face-down on the table
2. The Sprint Master collects them without looking
3. Sketches stay sealed until Wednesday morning
4. No peeking, no sharing, no discussing solutions over dinner

This builds suspense and prevents bias. On Wednesday, every sketch gets a fair hearing.

## Tuesday Checklist

- [ ] Lightning Demos completed (10-20 ideas captured on whiteboard)
- [ ] Divide or Swarm decision made
- [ ] All four sketch steps completed by every team member
- [ ] Each person produced a 3-panel solution sketch
- [ ] Sketches are self-explanatory, titled, and anonymous
- [ ] Sketches collected and sealed
- [ ] No one has discussed or revealed their solution

## Common Tuesday Mistakes

### Lightning Demos Go Too Long

**Problem:** Each demo takes 10 minutes instead of 3, eating into sketch time.
**Fix:** Use a visible timer. At 3 minutes, the Sprint Master says "Thank you, next." Capture the big idea and move on.

### Group Discussion During Sketch Time

**Problem:** People start comparing ideas or asking for feedback.
**Fix:** The afternoon sketch phase is silent. If someone asks a question, the Sprint Master says "Write it into your sketch."

### Crazy 8s Feels Pointless

**Problem:** People draw one idea 8 times or give up after 4 panels.
**Fix:** Before starting, show examples of good Crazy 8s. Emphasize that panels 5-8 often produce the best ideas because the obvious ones are exhausted.

### Solution Sketches Are Too Vague

**Problem:** Sketches show boxes labeled "content goes here" with no detail.
**Fix:** Remind the team: "Someone who was not in our sprint should be able to understand your sketch. Write real headlines, real button labels, real content."

### Only Designers Produce Sketches

**Problem:** Engineers and marketers opt out because they "cannot draw."
**Fix:** Share the non-designer tips above. Show examples of successful text-heavy, low-art sketches. The best sprint solutions often come from non-designers.

### Perfectionism Kills the Solution Sketch

**Problem:** Someone spends 90 minutes on a single beautiful panel.
**Fix:** Remind them: three panels, not one. The storyboard format forces breadth. Ugly but complete beats beautiful but incomplete.

# Wednesday: Decide on the Best Solution

Wednesday transforms a gallery of individual sketches into a single plan the team will prototype and test. The day uses structured critique and voting to avoid design-by-committee and the loudest-voice-wins trap. The Decider makes the final call, the team builds a storyboard, and everyone leaves with a clear blueprint for Thursday's prototype.

## Schedule Overview

| Time | Exercise | Duration |
|------|----------|----------|
| 10:00 - 10:15 | Setup: Art Museum | 15 min |
| 10:15 - 10:45 | Silent review and heat map | 30 min |
| 10:45 - 12:00 | Speed critique (all sketches) | 75 min |
| 12:00 - 12:15 | Straw poll | 15 min |
| 12:15 - 12:30 | Supervote | 15 min |
| 12:30 - 1:30 | Lunch | 60 min |
| 1:30 - 2:00 | Rumble vs All-in-One decision | 30 min |
| 2:00 - 4:30 | Storyboard creation | 150 min |
| 4:30 - 5:00 | Storyboard review and confirmation | 30 min |

## Art Museum Exercise

### Setup (Before the Team Arrives)

1. Tape each solution sketch to the wall at eye level, spaced evenly
2. Number each sketch (Sketch 1, Sketch 2, etc.) with a sticky note in the corner
3. Leave space between sketches for dot stickers
4. Place a stack of small dot stickers at each team member's seat

### How to Run the Art Museum

1. Everyone stands and walks along the wall, reviewing each sketch silently
2. No talking during this phase
3. Read each sketch carefully: title, panels, annotations
4. Place small dot stickers on any part of any sketch that catches your eye
5. You can use as many dots as you want
6. A dot means "this is interesting" (not "I vote for this")
7. Time: 20-30 minutes of silent review

### Facilitator Tips

- Play background music to reinforce the "no talking" rule
- If someone starts whispering, gently redirect: "Save it for the critique"
- Walk the room yourself to model the behavior
- Observe where clusters of dots form: these will drive the critique

## Heat Map Review

After silent voting, the wall should show clear heat maps: some sketches or sections will be covered in dots, others will have few.

### Reading the Heat Map

| Pattern | What It Means |
|---------|--------------|
| Dense cluster on one panel | Strong consensus on a specific idea |
| Dots spread evenly across a sketch | Generally interesting but no standout element |
| One sketch with very few dots | The idea did not resonate (or was hard to understand) |
| Same concept dotted across multiple sketches | A shared insight that multiple people reached independently |

## Speed Critique

### Purpose

Give every sketch a fair, structured hearing without turning into an open debate. The Sprint Master controls the format strictly.

### Process for Each Sketch (3 minutes per sketch)

| Step | Who | What | Time |
|------|-----|------|------|
| 1. Narrate | Sprint Master | Walk through the sketch panel by panel: "Here the customer sees X, then they click Y, and this leads to Z" | 60 sec |
| 2. Call out | Team | Team members call out standout ideas. Sprint Master captures them on sticky notes above the sketch | 60 sec |
| 3. Concerns | Team | Quick objections or questions (not debate). Sprint Master notes them | 30 sec |
| 4. Creator speaks | Sketcher | The sketcher reveals themselves and clarifies anything missed (only if needed) | 30 sec |

### Sprint Master Script for Narration

Use this pattern for each panel:

"In this sketch, titled [title], the customer starts by [describe Panel 1]. Then they [describe Panel 2]. And the result is [describe Panel 3]. I notice dots clustered around [specific element]."

### Rules During Speed Critique

- The sketcher stays silent until Step 4
- No one says "I don't like this" without a specific reason
- The Sprint Master controls who speaks and when
- Capture ideas on sticky notes with one idea per note
- Stick to 3 minutes per sketch; use a timer

## Straw Poll

### Purpose

A non-binding vote to reveal team preferences before the Decider makes the final call.

### How to Run the Straw Poll

1. Give each team member one large dot sticker (different color from the small dots)
2. Each person places their large dot on the sketch they think should be prototyped
3. Voting is simultaneous: count "3, 2, 1, vote" and everyone places their dot at once
4. After voting, go around the room. Each person explains their vote in one sentence
5. Record the vote tally on the whiteboard

### Why One Sentence Matters

The one-sentence explanation often reveals important reasoning:

- "I picked Sketch 3 because it directly addresses our sprint question about trust"
- "I picked Sketch 5 because it is the simplest to prototype in one day"
- "I picked Sketch 1 because it solves the problem for both new and returning users"

These explanations help the Decider make an informed final decision.

## Supervote: The Decider's Final Call

### How It Works

1. The Decider receives three large dot stickers in a distinctive color (usually stars or a different color)
2. The Decider places their three dots on the sketch or sketches they want to prototype
3. The Decider can put all three on one sketch or spread them across multiple
4. The Decider's vote is final. No discussion, no override

### Why the Decider Has This Power

- Someone has to make the call, or the team compromises into mediocrity
- The Decider lives with the consequences, so they should choose
- It prevents endless negotiation
- It mirrors real organizational decision-making

### What If the Team Disagrees?

The Decider's choice stands. The sprint process trusts that testing on Friday will reveal whether the decision was right. If the Decider is wrong, the team will know by Friday afternoon, and only one week was invested.

## Rumble vs All-in-One

After the Supervote, the Sprint Master checks whether one or multiple sketches were selected.

### All-in-One (Most Common)

Use when the Decider's supervotes landed on one sketch or on compatible elements from multiple sketches.

**Process:**
1. The winning sketch becomes the foundation
2. Pull in specific elements from other sketches that got dots or team support
3. Combine into a single concept

### Rumble (Less Common)

Use when the Decider's supervotes landed on two clearly different and incompatible approaches.

**Process:**
1. Prototype both approaches (usually as branded competitors: "Concept A" and "Concept B")
2. Test both with users on Friday
3. Each approach gets its own storyboard panel sequence

### Decision Criteria

| Factor | All-in-One | Rumble |
|--------|-----------|--------|
| Decider selected one clear winner | Yes | No |
| Two strong but incompatible approaches | No | Yes |
| Limited prototyping resources | Yes | No |
| Team wants to resolve a strategic debate | No | Yes |
| You want more definitive Friday results | No | Yes |

## Storyboard Creation

### Purpose

Translate the winning sketch into a step-by-step prototype blueprint. The storyboard tells Thursday's prototyping team exactly what to build, screen by screen.

### Setup

1. Draw a grid on the whiteboard: 10-15 empty rectangles arranged in rows
2. Each rectangle represents one frame (screen, interaction, or moment)
3. Number the frames 1 through 15

### Step-by-Step Process

| Step | Duration | What Happens |
|------|----------|-------------|
| 1. Opening scene | 15 min | How does the customer first encounter the solution? (ad, email, search result, referral) |
| 2. Entry | 15 min | What is the first screen or interaction? (landing page, app home, signup) |
| 3. Core flow | 60 min | Walk through each step of the solution. One frame per screen or major interaction |
| 4. Success moment | 15 min | What does the customer see when they have succeeded? |
| 5. Review | 30 min | Walk through the entire storyboard. Does it make sense? Are there gaps? |

### Storyboard Best Practices

**Include:**
- Real headlines and copy (not "text goes here")
- Button labels
- Key images or illustrations (described, even if rough)
- Navigation elements
- Error states or edge cases (if they are part of the test)

**Exclude:**
- Backend logic
- Features that will not be tested
- Multiple branching paths (pick one primary path)
- Detailed visual design (color, typography)

### Example Storyboard: Online Grocery Delivery

```
Frame 1:  Customer searches "grocery delivery [city]"
Frame 2:  Google result: "Fresh groceries in 2 hours - [Brand]"
Frame 3:  Landing page with value proposition and "Shop Now" button
Frame 4:  Category browse: Produce, Dairy, Meat, Bakery
Frame 5:  Product page: Organic Avocados, $4.99, "Add to Cart"
Frame 6:  Cart summary with items, quantities, and total
Frame 7:  Delivery time selection: "Today 2-4pm" or "Tomorrow 8-10am"
Frame 8:  Checkout: address, payment (pre-filled if possible)
Frame 9:  Order confirmation with estimated delivery time
Frame 10: SMS notification: "Your order is on its way"
Frame 11: Delivery photo: "Your groceries are at your door"
Frame 12: Follow-up: "How was your delivery? [Rate 1-5]"
```

### Common Storyboard Debates (and How to Resolve Them)

| Debate | Resolution |
|--------|-----------|
| "Should we include signup?" | Only if signup is part of the test. If the sprint question is about the core experience, start after signup |
| "How detailed should the copy be?" | Detailed enough for the Writer on Thursday to know the intent. Not final copy |
| "What if the user goes off the path?" | Prototype the happy path. Note edge cases as sticky notes but do not storyboard them |
| "This needs 20 frames" | Reduce. If it takes more than 15, you are including too much. Focus on the core flow |

## Wednesday Checklist

- [ ] All sketches reviewed in Art Museum with heat map dots
- [ ] Speed critique completed for every sketch
- [ ] Straw poll conducted
- [ ] Decider has placed supervotes
- [ ] Rumble vs All-in-One decision made
- [ ] Storyboard drawn on whiteboard (10-15 frames)
- [ ] Storyboard includes real copy, not placeholders
- [ ] Everyone on the team understands and agrees with the storyboard
- [ ] Storyboard is photographed for Thursday reference

## Common Wednesday Mistakes

### Groupthink During the Art Museum

**Problem:** Team members watch where others place dots and follow the crowd.
**Fix:** Spread the sketches far apart so it is harder to see others. Remind the team that dots mean "interesting," not "I vote for this."

### Speed Critique Turns Into Debate

**Problem:** One person argues for 10 minutes about why their approach is better.
**Fix:** The Sprint Master enforces the 3-minute timer per sketch. No rebuttals. Save opinions for the straw poll.

### Decider Defers or Compromises

**Problem:** The Decider says "Let's just combine everything into one" to avoid conflict.
**Fix:** Remind the Decider that Friday's test will validate the choice. Making a clear decision now is better than a watered-down compromise. A strong prototype of one idea beats a weak prototype that tries to do everything.

### Storyboard Is Too Vague

**Problem:** Frames show "main screen" and "results page" without specifics.
**Fix:** For each frame, ask: "If I handed this to a designer who was not in the room, could they build this screen?" If no, add more detail.

### Storyboard Takes Too Long

**Problem:** The team spends 4 hours on the storyboard and still is not done.
**Fix:** Time-box each section. The Sprint Master makes calls on unresolved details: "We are going with Option A. If it does not work on Friday, we will know." Move on.

### Ignoring the Sprint Questions

**Problem:** The storyboard drifts away from the sprint questions chosen on Monday.
**Fix:** Write the sprint questions above the storyboard. After each frame, ask: "Does this help answer our sprint question?" If a frame does not contribute to the test, cut it.