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
Understand people through observation and interviews. Synthesize that data into meaningful scenario.
Ideate
Generate as many ideas as possible that address a scenario.
Evaluate
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.
