How to run a design sprintTim Metzner and Colin Flynn

A process developed at Google Ventures to turn a half-baked idea into

a (testable) prototype in one week.

What is a Design Sprint?

What sprints can do:

• Quickly validate and gain feedback for a product idea.

• Discover the right priorities and features for a product.

• Kill concepts before throwing tons of resources at them

• Establish and confirm the broad strokes of a feature before worrying about non-critical details.

What sprints can’t do:

• Create a lot of new ideas (not focused on ideation)

• Produce a market-ready solution

• Always provide an obvious go/no-go decision

What is a Design Sprint?

When should you Run a sprint?

You should run a sprint when you have:

• A clear problem to be solved or an assumption you’re ready to test.

• Access to stakeholders and domain experts.

• Team buy-in and commitment from decision makers.

• Project goals defined. Ask, “What does success look like?”

You should not run a sprint if:

• You’re still in the ideation phase (i.e. don’t know what to test yet).

• Key stakeholders/decision makers aren’t going to participate.

• Your team doesn’t have the time to fully engage in the process.

How it works

Pre-work

Pre-Work:

• Determine roles: Who is the Decider? Who is the Facilitator?

• Ask, “What does success look like?”

We’ve learned:

• The Facilitator and Decider must have a good relationship and some rapport built; Decider must trust expertise of Facilitator.

day 1 - MAP

Objective:

• Unpack the problem/challenge and determine the focus for the sprint. What is the key thing you need to see tested?

We’ve learned:

• It’s important that the facilitator sets the tone and expectations for each activity.

Day 2 - Sketch

Objective:

• Explore ideas through sketching and iteration (not debate).

We’ve learned:

• Facilitator and Decider should have sidebar conversations throughout to stay on the same page.

• Continually reset; here’s where we’re at, here’s where we’re going.

Day 3 - Decide

Objective:

• Determine which solution to prototype. Each group member votes by placing a dot sticker on his/her favorite solution.

We’ve learned:

• Take breaks. Tough decisions can bring up some tension. A ten minute break to clear the air can be some of the most valuable time spent in the day.

• Be time-flexible with the schedule. Don’t move onto the the next phase if you haven’t completed the one you’re on.

Day 4- Prototype

Objective:

• Build a prototype of your solution, with an accurate and polished look and feel.

We’ve learned:

• Don’t schedule days longer than 6 hours and don’t start at the crack of dawn

Day 5 - Test

Objective:

• Test your prototype with real users. Learn from their insights, burst assumptions, and validate ideas.

We’ve learned:

• A Design Sprint doesn’t actually have to be 5 days (and it doesn’t have to be 5 consecutive days)

• BUT, it can’t too spread out; you’ll lose momentum/insight.

• It SHOULD be the same people throughout the process (introducing new people mid-way is hard).

Thank you www.Differential.com

Contact us: @tmetzner

@colinpflynn

hello@differential.com