A design sprint is a structured, time-boxed process, typically five days, that turns an idea or problem into a tested prototype before anyone writes a line of code. It's a sound framework. But showing up with just a calendar invite and no plan for people, materials, or deliverables is how sprints stall out by Wednesday.
This article breaks down exactly who needs to be in the room, what happens each day, what artifacts you'll walk away with, and when a sprint simply isn't the right tool for the problem in front of you.
TL;DR: key takeaways
- A sprint needs a defined team of 5-7 people with specific roles, not just "whoever's free"
- The five-day arc (Understand, Sketch, Decide, Prototype, Validate) produces a tangible artifact daily
- Pre-sprint prep, like your problem statement and recruited customers, matters as much as the week itself
- Validates a hypothesis: not a substitute for full product, brand, or website development
1. What is a design sprint?
A design sprint is a five-day framework, originally developed at Google Ventures, for answering a critical business or product question through rapid prototyping and real customer testing. Rather than debating an idea in meetings for months, a team builds something testable and puts it in front of real people by Friday.
The goal isn't a finished product. It's validated learning, meaning you find out whether an idea actually works before committing engineering budget, hiring, or months of roadmap time to it. GV calls this a shortcut to learning without building and launching, and that's a fair description.
Design sprint vs. Scrum sprint: they share a name, not a purpose.
- Design sprint: a one-time event run before development to test whether an idea is worth building
- Scrum sprint: a recurring development cycle, usually a few weeks, used to build and ship product increments
2. Who's included: the design sprint team
The team is the single most overlooked input in most sprint planning. Get the roles wrong and even a well-run week produces mushy, unactionable results.
2.1 The core roles
Every sprint needs these three people, without exception:
- The Facilitator: Runs the process, keeps time, and stays neutral on the actual decisions being made. They shouldn't have a stake in the outcome.
- The Decider: The final authority, usually a founder, CEO, or product lead. If they can't attend the full week, they need to appoint a delegate who can.
- The Designer: Owns the actual prototyping work and translates sketches into something testable.
2.2 Supporting roles
Beyond the core three, a sprint pulls in:
- Product Manager: Represents business goals and user needs, and keeps the week anchored to what actually matters commercially.
- Engineer/Developer: Flags technical feasibility in real time, so the team doesn't storyboard something impossible to build later.
- Subject Matter Experts: Marketing, support, data, or domain specialists brought in mainly on Day 1 to share context, not to sit through the whole week.
Ideal team size is 5-7 people. Any larger and the room slows down; decisions get diluted by groupthink, and dot-voting turns into a negotiation.
For technical and climate-tech founders specifically, this is where teams often hit a wall. Deep scientific or engineering expertise doesn't automatically translate into facilitation or design skill.
Running a sprint without either produces a week of unfocused sketching. That's why many startups bring in a senior external design partner, like What if Design, to fill the Facilitator and Designer seats while the founding team stays focused on the Decider role and technical input.
3. What's included: the 5-day sprint breakdown
Each day is dedicated to one phase, and each phase produces a specific artifact that feeds directly into the next day. Skip a day, and the whole chain breaks.
3.1 Day 1: understand
The team maps the challenge on a whiteboard, tracing the customer journey from start to finish. Then comes "Ask the Experts": short, 15 to 20 minute interviews with internal specialists: engineers, sales, support, or anyone with relevant knowledge, so the team pulls expertise into the room without keeping people there all week.
By the end of the day, the Decider picks one specific target problem. That target is the artifact the rest of the week will solve.
3.2 Day 2: Sketch
Rather than group brainstorming, each person sketches independently using a structured four-step method:
See how we have approached this in practice: Mobile UX design.
- Notes from Day 1
- Rough ideas
- Crazy 8s (eight rapid variations, one minute each)
- A detailed solution sketch
Working alone on purpose avoids groupthink, the loudest voice doesn't dominate. The day's artifacts are those solution sketches.
Meanwhile, someone starts recruiting five target customers for Friday's test. That outreach often takes longer than teams expect.
3.3 Day 3: decide
Sketches go up on the wall anonymously. The team does a silent review, then dot-votes on the elements they find most promising. The Decider gets a "supervote," meaning they can override the group and choose what actually gets built. The afternoon turns the winning concept into a storyboard, roughly 5 to 15 steps that map exactly what the prototype needs to show. That storyboard is the artifact Day 4 builds from.
3.4 Day 4: prototype
This is where "fake it" becomes the operating principle. The team builds a realistic-looking facade, not functional code, using tools like Figma, Sketch, or even simple mockups. It needs to look and feel real enough that a customer forgets they're testing a fake.
For a technical product like a carbon-capture monitoring dashboard, that might mean prototyping only the operator interface: enough to test comprehension without building the underlying system.
3.5 Day 5: validate
The Facilitator runs one-on-one interviews with the five recruited customers while the rest of the team observes from another room. Each session follows the same structure:
- Warm welcome
- Context questions
- Prototype introduction
- Tasks with think-aloud prompts
By the end of the day, the team has clear patterns on what worked, what confused people, and what to do next. The final artifact that decides the path forward.
4. What's included: materials, deliverables & pre-sprint prep
The sprint week gets the attention, but what happens before it starts determines whether the week actually works.
4.1 Pre-sprint checklist
- A clarified problem statement the whole team agrees on before Monday
- Target customers recruited for Friday testing, start weeks ahead, since recruiting takes longer than most teams expect
- A dedicated "war room" or shared digital workspace reserved for the full five days
4.2 Materials you'll need
- Sticky notes, markers, and at least two large whiteboards (or an online whiteboard tool for remote teams)
- Timers to keep exercises like Crazy 8s moving
- Small and large dot stickers for silent voting
- Prototyping software such as Figma or Sketch
4.3 What you walk away with
By Friday afternoon, a well-run sprint produces:
- A journey map from Day 1
- A full set of individual sketches from Day 2
- A storyboard from Day 3
- A testable prototype from Day 4
- Validated (or invalidated) hypothesis notes with customer quotes from Day 5
Documenting these somewhere accessible (a shared design board, a Slack thread, or a recorded Loom walkthrough) matters more than most teams realize. Sprints generate momentum, and that momentum evaporates fast if the deliverables live only in photos of a whiteboard nobody revisits.
5. When a design sprint isn't enough
A sprint is a precision tool for one specific question. It's not a fix for every product problem, and using it as one usually ends in disappointment.
A sprint is the wrong tool when:
- The concept is already validated and simply needs execution, not testing
- The scope is too broad: "reinvent our entire product" isn't a one-week problem and needs a specific, testable slice first
- The real need is ongoing design work, not a single validation exercise
A design sprint tests a hypothesis. It is not a shortcut for full product design, brand identity, or website development. Those require sustained, ongoing design partnership, not a single intense week.
This shows up constantly with climate tech and deep tech teams. Their product is often hard to explain, whether green hydrogen production or grid interconnection software.
A sprint frequently surfaces a bigger need underneath: translating that technical complexity into a brand, product, and website that closes funding and partnerships. What if Design picks up that full-service work once the sprint week wraps, right where the validated hypothesis leaves off.
A site that reflects the company you have actually become is the cheapest credibility you can buy, and it puts you back in control of the first impression. Get a free strategic audit.
6. Frequently asked questions
6.1 What is the purpose of a design sprint?
A design sprint validates an idea or answers a critical business question through a realistic prototype and real customer feedback. That cuts the risk of building the wrong thing before you commit serious engineering time and budget.
6.2 What is a Google design sprint?
A Google design sprint is the methodology Jake Knapp developed at Google Ventures. Teams now use it industry-wide as "the" design sprint framework, no matter which company runs it.
6.3 What is the first step in a design sprint?
The first step is pre-sprint setup: clarifying the problem statement and securing your team and space. This is followed by Day 1's "Understand" phase, where the team maps the challenge and sets a target.
6.4 How long does a design sprint take?
The standard format runs five consecutive days, Monday through Friday. Some teams run condensed 3-4 day versions for smaller-scope problems, though this trims prep and testing time.
6.5 Who needs to be involved in a design sprint?
At minimum, a Facilitator, a Decider, and a Designer, supported by Product, Engineering, and Subject Matter Expert input on Day 1. Five to seven people total keeps the room fast-moving.
6.6 What's the difference between a design sprint and a scrum sprint?
A design sprint is a one-time, week-long validation exercise run before development starts. A Scrum sprint is a recurring, multi-week cycle for building and shipping actual product increments.
