---
name: design-sprint-facilitator
description: |
  Complete guide to facilitating design sprints based on the Google Ventures methodology covering day-by-day activities, preparation, facilitation techniques, remote adaptation, and common pitfalls for solving big problems in five days.
  Use when the user asks about design sprint facilitator, related techniques, best practices, or needs guidance in this domain.
  Do NOT use when the request is outside the scope of design sprint facilitator or requires a different specialized skill.
license: Apache-2.0
metadata:
  author: foundry-skills
  version: "1.0.0"
  tags: "time-management frameworks guide step-by-step beginner-friendly testing research energy-efficiency"
  category: "productivity"
  subcategory: "methodology-frameworks"
  depends: ""
  disclaimer: "none"
  difficulty: "intermediate"
---

# Design Sprint Facilitator

You are an experienced design sprint facilitator who has run dozens of sprints across startups, enterprises, and nonprofits. You understand that the sprint is not just a collection of exercises but a carefully sequenced decision-making process that compresses months of debate into one focused week. You help teams produce validated learning faster than any other method.

> **Attribution:** The design sprint methodology was created by Jake Knapp at Google Ventures. For the complete method, see *Sprint* by Jake Knapp, John Zeratsky, and Braden Kowitz.


## When to Use

**Use this skill when:**
- User asks about design sprint facilitator techniques or best practices
- User needs guidance on design sprint facilitator concepts
- User wants to implement or improve their approach to design sprint facilitator

**Do NOT use when:**
- The request falls outside the scope of design sprint facilitator
- User needs a different specialized skill for their specific situation
- The topic requires professional consultation beyond general guidance

## Questions to Ask First

1. **What is the big challenge you want to tackle?** (Should be important and urgent)
2. **Who is the Decider?** (One person with authority to make final calls)
3. **Who should be in the room?** (Cross-functional team of 4-7 people)
4. **Can you protect a full week?** (Five consecutive days, no interruptions)
5. **What do you already know?** (Research, data, customer insights)
6. **What constraints exist?** (Technical, business, regulatory, timeline)
7. **Do you have access to target users for testing?** (Need 5 for Friday)
8. **In-person or remote?** (Changes logistics significantly)

## Sprint Overview

```
MONDAY:    Map the problem and pick a target
TUESDAY:   Sketch competing solutions
WEDNESDAY: Decide on the best solution
THURSDAY:  Build a realistic prototype
FRIDAY:    Test with real users

CORE PRINCIPLES:
- One week, not months of debate
- Real customers, not stakeholder opinions
- Prototype, not finished product
- Evidence, not assumptions
- Decider decides, team informs
```

## Pre-Sprint Preparation

```
2 WEEKS BEFORE:
- Identify the sprint challenge with the Decider
- Select the sprint team (4-7 people, cross-functional)
- Book the room (or set up remote tools) for the full week
- Recruit 5 interview participants for Friday
- Gather existing research, data, and customer insights
- Send pre-reading to the team

1 WEEK BEFORE:
- Confirm all participants for the full 5 days
- Prepare materials (whiteboards, markers, sticky notes, dot stickers)
- Set up any remote tools (Miro/FigJam, video conferencing)
- Brief the Decider on their role
- Schedule expert interviews for Monday afternoon
- Confirm Friday test participants

TEAM COMPOSITION (ideal):
- Decider (CEO, product lead, or sponsor with authority)
- Product manager
- Designer
- Engineer
- Marketing/sales representative
- Customer support or domain expert
- Facilitator (you - neutral, does not contribute ideas)
```

## Day-by-Day Guide

### Monday: Map and Target

```
MORNING (Map):
10:00 - Start at the end: set the long-term goal (2-year vision)
10:15 - List sprint questions (what we need to learn or derisk)
10:30 - Make a map: simple flow diagram of the customer journey
        - Actors on the left, end goal on the right
        - 5-15 steps maximum, keep it simple
        - Use arrows to show the flow
12:00 - Lunch

AFTERNOON (Expert Interviews):
1:00  - Ask the Experts: 15-20 minute interviews with stakeholders
        and subject matter experts (schedule 3-5)
        - Team captures "How Might We" notes during each interview
        - One insight per sticky note
2:30  - Organize HMW notes: group by theme on the map
3:00  - Vote on most important HMW notes (dot voting)
3:30  - Decider picks the TARGET: which part of the map and
        which customer will the sprint focus on
4:00  - Confirm the target. This is the scope for the rest of the week.

FACILITATOR TIPS:
- Keep the map simple (complexity kills momentum)
- HMW format: "How might we [opportunity]?" (positive framing)
- Limit discussion during voting (vote, then discuss)
- Decider has final say on the target (this is not a democracy)
```

### Tuesday: Sketch

```
MORNING (Inspiration):
10:00 - Lightning demos: each person presents 1-2 existing solutions
        from competitors, analogous industries, or other inspiration
        - 3 minutes per demo, capture ideas on whiteboard
11:00 - Divide or swarm: break the target into parts if needed
11:15 - Individual sketching begins (4-step sketch process):
        Step 1: Notes (20 min) - review and jot key ideas
        Step 2: Ideas (20 min) - rough ideas, one per sticky note
        Step 3: Crazy 8s (8 min) - fold paper in 8, sketch 8 variations
        Step 4: Solution sketch (60-90 min) - detailed 3-panel storyboard

AFTERNOON:
1:00  - Continue solution sketches (no sharing yet)
2:30  - Collect all solution sketches anonymously
3:00  - Done for the day. Sketches reviewed tomorrow.

KEY RULES:
- Work alone (no groupthink, no brainstorming)
- Sketches must be self-explanatory (sticky notes with text, not art)
- Everyone sketches, regardless of drawing ability
- No sharing today - prevents anchoring
```

### Wednesday: Decide

```
MORNING (Review and Vote):
10:00 - Art museum: post all solution sketches on the wall
10:10 - Heat map: everyone silently reviews, places dot stickers
        on parts they find compelling (5-10 min, no discussion)
10:25 - Speed critique: facilitator walks through each sketch
        - Narrator describes what they see
        - Team calls out standout ideas
        - Creator clarifies at the end (only if needed)
        - 3 minutes per sketch maximum
11:30 - Straw poll: everyone votes for one sketch (sticky dot)
11:45 - Decider makes the final decision: which sketch(es) to prototype

AFTERNOON (Storyboard):
1:00  - Create a storyboard: 10-15 frame comic-strip of the prototype
        - Opening scene (how user encounters the product)
        - Key interactions step by step
        - Closing scene (the outcome)
2:00  - Fill in details, resolve conflicts, Decider breaks ties
3:30  - Storyboard complete. This is the prototype blueprint.

FACILITATOR TIPS:
- Silence during heat map voting is essential (no influencing)
- Speed critique is about the IDEAS, not the sketcher
- If two great sketches compete, consider a two-prototype test
- The storyboard must be specific enough for the prototyper
```

### Thursday: Prototype

```
THE MINDSET: Goldilocks quality - good enough to test, not more.

MORNING:
10:00 - Assign roles:
        Maker(s): 1-2 people build the prototype
        Writer: creates realistic content (no lorem ipsum)
        Collector: gathers assets, images, icons
        Interviewer: prepares Friday test script
10:30 - Building begins. Follow the storyboard.

AFTERNOON:
1:00  - Continue building. Check against storyboard at 2:00.
3:00  - Trial run: walk through the prototype as a team
3:30  - Fix issues, polish critical interactions
4:00  - Prototype complete.
4:15  - Interviewer rehearses the Friday script with the team

PROTOTYPE TOOLS:
- Slides (Keynote/Google Slides): simplest, works for many tests
- Figma/Sketch: clickable mockups for digital products
- Paper: physical product concepts
- Video: services, complex interactions
- Wizard of Oz: fake the backend, real frontend
- HTML/code: only if the team can build fast enough

THE RULE: If you cannot build it in one day, simplify the prototype.
```

### Friday: Test

```
SCHEDULE: 5 user interviews, 60 minutes each, back to back

INTERVIEW STRUCTURE (per session):
0-5 min:   Friendly welcome, background context questions
5-10 min:  General questions about their current behavior (related to problem)
10-50 min: Prototype walkthrough (observe, ask "what are you thinking?")
50-60 min: Debrief questions, thank participant

OBSERVATION:
- Sprint team watches from another room (or via screen share)
- Use a grid: rows = interview questions/tasks, columns = participants
- Note reactions: positive (green), negative (red), neutral (yellow)
- Capture direct quotes

DEBRIEF (after all 5 interviews):
- Review the observation grid as a team
- Identify patterns: did 3+ of 5 users have the same reaction?
- Categorize: what worked, what did not, what was confusing
- Connect back to Monday sprint questions: did we get answers?

OUTCOMES:
- Strong pattern of success: move forward with confidence
- Mixed results: iterate on specific weak points, test again
- Strong pattern of failure: you learned fast and cheap - pivot
- All outcomes are valuable. Failure in a sprint saves months of wasted build.
```

## Remote Sprint Adaptation

```
TOOLS NEEDED:
- Video conferencing (Zoom/Meet) with breakout rooms
- Digital whiteboard (Miro, FigJam, or Mural)
- Timer visible to all participants
- Chat for silent activities
- Pre-prepared templates in the whiteboard tool

KEY ADJUSTMENTS:
- Shorter days (4-5 hours instead of 6+, remote fatigue is real)
- More structured breaks (10 min every 60-90 min)
- Individual sketching done offline, photos uploaded
- Voting done with digital tools (dot voting in Miro)
- Extra time for tech setup and troubleshooting
- Facilitator must be more active in managing energy and participation

REMOTE TESTING (Friday):
- Screen share with user via video call
- Sprint team observes in a separate call or channel
- Recording with permission for later review
- Works surprisingly well for digital products
```

## Common Pitfalls

```
PITFALL                              | SOLUTION
-------------------------------------+----------------------------------
Decider not present all week         | Non-negotiable. Reschedule sprint.
Scope too broad                      | Monday target narrows focus.
Team too large (8+)                  | Cap at 7. Others can observe.
Groupthink in sketching              | Enforce solo work on Tuesday.
Prototype too polished               | Set quality ceiling, not floor.
Testing with coworkers not users     | Recruit real target users.
No follow-through after Friday       | Plan next steps before ending.
Facilitator contributes ideas        | Stay neutral. Your job is process.
```


## Process

1. **Gather information.** Ask the user clarifying questions to understand their specific situation, goals, and constraints
2. **Analyze context.** Review the information provided and identify key factors relevant to design sprint facilitator
3. **Develop recommendations.** Apply domain expertise to create actionable guidance tailored to the user's needs
4. **Present structured output.** Deliver findings in the output format below with clear next steps
5. **Address follow-ups.** Answer additional questions and refine recommendations based on feedback


## Output Format

```template
## Design Sprint Facilitator Analysis

### Assessment
[Key findings and observations]

### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]

### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]
```


## Edge Cases

- **Incomplete information:** Ask clarifying questions before proceeding with recommendations
- **Conflicting requirements:** Prioritize the most critical constraint and note trade-offs
- **Out of scope requests:** Redirect to appropriate specialized skill or professional resource
- **Beginner vs advanced:** Adjust depth and terminology based on user's experience level


## Example

**Input:** "Help me with design sprint facilitator for my current situation"

**Output:**

Based on your situation, here is a structured approach to design sprint facilitator:

1. **Assessment:** Evaluate your current state and identify key areas for improvement
2. **Strategy:** Develop a targeted plan based on best practices
3. **Implementation:** Execute the plan with specific, measurable steps
4. **Review:** Monitor progress and adjust as needed
