The Design Sprint - What is it?

Google Ventures coined the term "Design Sprint" back in 2010 to describe a technique for compressing typical design work into one super-charged week.  Google Ventures created the approach to rapidly increase the speed of product development. We all know speed is crucial at a start-up company.  The faster a team can find their minimum viable product (or pivot) the sooner they can land those first critical sales.

Although Google Ventures created design sprints for start-ups, other organizations use similar approaches to achieve design success rapidly.  At IBM I utilized a technique called a 'Design Hothouse' to deliver design results under extreme deadlines.  You may recall IDEO's 'DeepDive' technique as witnessed on the ABC Nightline episode Inside IDEO, where they re-designed a shopping cart in under 2 days. 

All three techniques (design sprint, design hothouse and deep dive) are rooted in design thinking which follows these basic tenets:


Understand people through observation and interviews. Synthesize that data into meaningful scenario.


Generate as many ideas as possible that address a scenario.


Evaluate and promote ideas that satisfy the scenario.

To understand the speed and value design thinking can generate let's walk-through the steps of a Google Ventures Design Sprint. A design sprint utilizes the strategies of design thinking and operationalizes it to deliver results in 5 days. 

Let's take a closer look.

DAY 0 - Organize

Find a facilitator:  A facilitator must be someone who understands the process and is capable of keeping the team motivated, focused and organized.  An effective facilitator can make or break the design sprint experience.  I've seen sessions go down rat-holes and struggle to recover momentum.

Invite the right people: It is important to invite the right mix of decision makers from business, engineering, support and marketing.  Each person must be willing to follow the process and be willing to suspend their own agenda for the duration of the sprint. No use bringing in a person with an axe to grind, each person must be willing to stay on task in order to achieve maximum results. 

Gather relevant data:  Gather the customer visit reports, the current web analytics, sales numbers, sales pipeline, or whatever data you have.  If it is an absolutely new idea, capture your assumptions about market size, opportunity and projected growth.

Line-up people to evaluate: On day 5 of the design sprint you will evaluate a prototype.  Line-up  customers or people to evaluate that prototype before you begin since that makes your deadline firm (often lining up customers can take some time, everybody has a busy schedule so give them some lead time).

Gather supplies: Ensure you have a good supply of sticky notes, dry-erase markers, blank paper, pens and tape to keep the sessions running.  Ensure a timer or clock is part of the kit. The timer is used to give boundaries to exercises and keep the sessions on track.

Secure a space: A dedicated space is important.  The team should not have to pack-up and move.  The space should be big enough to accommodate a team of 4-7 and have enough wall space for things to be posted.  A room with lots of whiteboard space is a bonus.

 DAY 1  - Unpack

Google Ventures uses the term unpack to describe the act of getting all participants on the same page. Existing research, product demos, business plans, sales data and customers analytics are presented and shared among the team. Common understanding goes a long way on day 1. A team may consider working the business model canvas prior to a design sprint in order to ratify they all agree on their business model. On day 1 I use a technique I call "Users, Goals, Tasks" in order to capture the basic understanding of who are the users of the product, what are the goals they are trying to solve and what tasks support those goals. Not sure how to start? Pick an industry that you expect to be part of your market (ie. financial) and identify the different users in that industry.  Then move on to a different industry that is applicable. Patterns typically emerge across industries.  Scenarios are a great way to capture the key situation that needs a solution, it puts a problem into a context that a team can relate to. Day 1 can be the most difficult day especially if a team is not prepared or has some dissension. A teams needs to agree about business goals, and who the product will service and why.  I will typically hold a team on this stage until at least a single common scenario is found that everyone is satisfied with. (Note: I once held a team at this stage for 3 days until agreement could be reached and a common scenario found - everything went like clockwork after that)

DAY 2 - Diverge

Diverge is a good title for the next stage.  A team now has permission to get as many ideas captured as they can that solve the users goals.  Use hand-drawn sketches to capture ideas rapidly. It is more important that you capture the core essence of an idea than making sure the idea is fully formed. Capture an idea and move on. I've seen teams generate 50-100 ideas in a sitting.  When I am a facilitator EVERYBODY sketches.  If you are in the room and participating then you sketch & present your ideas. This can make people feel self conscious of their drawing skills. I usually offer up some of my poorly drawn sketches & storyboards from previous sessions to illustrate that as long as the idea is conveyed through a sketch, that is sufficient. A session is broken up into idea generation and presentations. Every idea is presented by the person who created it. This ensures each idea is understood and opens the opportunity for questions.  Questions often lead to hybrid ideas where a new idea builds on one or more presented ideas. The day will end with a large set of ideas posted on the wall.

DAY 3 - Decide

Converge is another way to describe this step, since on day 3 the team must evaluate the initial ideas and converge on a smaller set that will be prototyped. I typically use only two criteria for evaluation.  

   How well does the solution satisfy user goals?

   Which solutions do you prefer? (you can use your own biases here.  i.e. easier to build, aligns with existing products, I like it!) 

 Voting is typically performed silently with voting dots. Since many ideas were generated in the previous step voting is crucial. What emerges from voting can be either agreement or dissent. Dissent is good on day 3 (it's better to hear dissent today than Day 5).  Always follow up voting with a big discussion. It is important to hear strong opinions about what should move forward and why.  There is a risk in being too democratic at this stage - sometimes it is best to give those closest to the customer more voting power (voting dots). Depending on what emerges from voting (one idea, 2 or more competing ideas), the team will need to decide how to evaluate them.  If competing ideas have been chosen it is likely best to test each head-to-head (i.e. A/B testing).  If only a single core idea has emerged spend more time on the prototype and be prepared with additional questions to keep the conversation rolling with your test subjects. Validation will not only help evaluate your prototype but will help determine if your assumptions about the users and their goals were accurate.  

Whiteboard the details of what will be tested through a scenario or storyboard.  Capture your questions next to it.  As you go through the scenario make additional sketches as required to capture the necessary details that fit the scenario. Sometimes problems and new questions come up when sketching the finer detail.  That is good.  Try to build those questions into the plan for evaluation.

DAY 4 - Prototype

 Not everyone's definition of a prototype is the same. For a design sprint a prototype is anything a person can interact with and discuss. The most important element of a one day prototype is speed and accuracy.  My go to tools have traditionally been a graphics package (Photoshop, Sketch, Fireworks) and a slide-sharing tool (Powerpoint, Keynote). These days I find I am adding inVision to that set depending on the format (web, mobile, desktop) of the application.  A combination of pictures, slides and slide transitions can make a pretty realistic looking product. Do not code anything!  That's right, at this stage code will only slow you down and get in the way of what you are trying to do which is evaluate an idea. Pictures and slides take only minutes to change where code can take hours.

Break up sections of the scenario and assign pieces of the prototype to teams of two. By dividing up the work it will move faster.  Assemble the pieces as they are completed to ensure smoothness and consistency with the scenario. If you have a seasoned researcher on the team have them write a research protocol to go with the prototype.

Before the day is over bring the team back together to do a dry run of the protocol and prototype. Assign a single team member to conduct all the evaluations.  Choose the person who has the most experience in a research role where possible.  Have them get familiar with the nuances of the prototype (sometimes they are finicky things). During the dry-run make two lists.  First, list the things that still need to be changed or improved with the prototype and assign those as homework to the team. Second, list new questions that need answering when running each evaluation session. 

DAY 5 - Validate

While Google Ventures uses the term validate, this makes it sound like you are simply trying to ratify what has been done.  I prefer the term evaluate since there is the possibility you will need to return to the drawing board.

Get prepared for the day by setting up any equipment you will need.  Do you plan to use a projector or record the session?  Test any equipment you need to ensure it works and you know how to use it. If you are testing remotely through a collaborative web tool make sure that is working and you know how to use it.

You want to set your sessions up in such a way as the entire team can observe and listen without interfering.  I've often found using collaborative web-sharing tools work best for observation. I also prefer to record sessions to capture specific quotes. Each team member should keep notes, and also include 15 minutes after each session for the team to debrief. A common approach is to use a scoreboard to capture the common highlights from each session. Schedule between 4-6 evaluation sessions (no greater than one hour in length) in a day and include one hour to debrief at the end to discuss the findings. Throughout the sessions you may see varied responses but most often the team will recognize patterns emerging in two categories: things that work and things that don't. I always plan for mixed results.  

Sprint complete – Woohoo!  

Pat yourself on the back for a job well done.  But wait, now what?  That depends on the outcome. How did the evaluation go? Did you end up with the mixed results you expected with a few things that went well and few things that need fixing? Or were things much worse? When you find serious challenges, this likely requires another design sprint to address the more serious challenges. Sometimes the entire prototype is just bad. This definitely requires the team to go back to the drawing board by hosting a new design sprint and revisit their assumptions and ideas.

Does a design sprint sound like something your organization could use to get the design results you need at speed?  I work with teams that want to learn the sprint approach and need a great facilitator to keep them on track.  Drop me a line if you want to learn more about the design sprint approach. I’ll be announcing some design sprint workshops very soon.  If you have a preference for business hours or in the evening please let me know.

What Can Product Teams Learn from Bob Marley?

I once attended a talk by a documentary filmmaker about Bob Marley that described how he and his band The Wailers were able to deliver timeless recordings but also deliver amazing live performances. At the height of Bob Marley's career (before his untimely death) the filmmaker once attended a rehearsal waiting to get an interview with Bob. What he described struck me as both intense and deliberate. The interviewer witnessed the band practice a single song for more than 8 hours. From time to time Bob would stop the rehearsal to discuss his vision for the song and how it could be improved. Periodically Bob would call out "switch" and each band member would move to a different instrument and pick up the song from the top. Flabergasted by what he'd just experienced, when the time was finally granted with Bob he asked about what he had just witnessed. Why would a band rehearse the same song for so long but also learn the instrument of other members of the band? What Bob had to say was telling of his perfectionism but also his dedication to his craft. He described how important it was for each band member to know their parts, but to also have an appreciation for how each instrument worked with their own to become something more. 

What does that have to do with product design?

Software design and development are a team sport.  It starts with vision but requires flawless execution by a team to deliver an exceptional product. I don't feel many organizations recognize how important shared vision and appreciation of each members contributions are. Bob Marley relayed his vision for a song and then he and his band did more than practice to perform their best, each member developed a sound appreciation for what each contributes by learning one another's instruments. I feel software teams can do more to develop a product vision, practice and cultivate an appreciation for what each is contributing.


A vision is important. It is not a pithy statement about becoming the best, but something bold, meaningful and compelling.  

 A vision serves to unite people and harness their energy.

What makes a vision? Vision is a product of deep understanding of the state of industry (technology and human values) and a desire to explore what is possible. This is no recipe for creating a compelling vision some would say it's a matter of thinking deeply and systematically removing the limitations for the current state of the industry. A vision is driven by "What if?"  Ask "What if" questions for every limitation your product or industry currently has.  

  • What if we could produce computer chips half the size of todays chips?
  • What if our software could run twice as fast as it does?
  • What if all cellular data packages were unlimited?
  • What if a quality laptop could be produced for less than $100?

Perhaps you can see Nicolas Negroponte's vision of One Laptop per Child in the last question?


How is it possible to practice when you have an aggressive schedule and endless deadlines? The same way other professions do it; make practice part of the schedule. Practice should be scheduled as team building events and should be fun. Fun ideas for practicing skills and techniques might include events like design improv (Interactionary by Scott Berkum) or exercises from the Stanford An event I helped create at IBM involved developers designing a planned program for Take Your Kid to Work Day. This event put a team of developers in the role of experience designer with mentorship from a seasoned experience designer. It was a fun way for developers to learn about experience design and grow their appreciation for the role. 

Find your own ways get teams involved in one another's work.  Whether that is events like those described or information sharing sessions and job shadowing. I believe a better appreciation for each others skills build better teams and better teams build better products. 

Are your products exceptional?

Is your product team operating at it's potential?

Perhaps it is time to listen to Bob Marley and cultivate your vision and your team?