If you want to know the full power of a Google product design sprint, consider this: In one week we’re able to identify a new product or feature, build a prototype, and test it on real users. That’s impressive enough, but what’s truly remarkable is that design sprints let us do all this alongside our clients — and without tears or late nights. If anything, it makes us a stronger, better team.
A Google design sprint also gives us a crash course in working with a new client. In five days, we learn the market they’re in and where they hope to go. The clients learn the basics of user experience, prototyping and user interviews. They’re able to ask themselves critical questions about their business and get real answers in a five-day span. At the end of a sprint, the client walks away with a working prototype and user feedback that can help determine whether to move forward.
There’s not a company around that couldn’t benefit from learning whether an idea is worthwhile in just five days, instead of over the several months a traditional product design process requires. Imagine the effort, time and money that could be saved by finding out one week into a project that users aren’t so keen on this feature, but really need some other functionality. We’ve run design sprint workshops for Chicago Ideas Week, a university, a pharmaceutical forecasting company, an innovation research e-commerce company and more — each walked away with a better understanding of what their clients wanted and where they could go. If you’re wondering what you might get out of one, here’s a little design sprint training to help you understand the process and the benefits.
Table of Contents
What is a Google Ventures design sprint?
Google Ventures, now GV, is basically Google’s innovation and design studio. The team pioneered Google’s product development process, but they also created the Google Ventures design critique — which we use — and plenty of other UX and design processes.
Designers have been floating the ideas behind the Google Ventures product design sprint on the Google Ventures blog for several years now. Google only formalized its brainstorming process a few months ago though, when designer Jake Knapp published his design sprint book, “Sprint.” The GV design sprint places a team of designers in a room with a client for a week. Together, they use a variety of exercises to quickly find an idea worth pursuing, prototype that idea and give it to users to validate or invalidate.
In truth, most of the Google Ventures sprint exercises are ones we've been using in UX for a long time. The innovation comes from putting all of these normal design tools like sketching sessions and kickoff meetings into the structure of a sprint. All together and under a short timeline, we’re able to realize value we don’t normally get.
For the past year or so, I’ve been researching the Google sprint idea and looking for an opportunity to implement it. I talked with Kyle Fiedler, Chief Design Officer at Thoughtbot, about his playbook. Several teams told me that they were getting a ton of value out of Google product design sprints. So the next time a client came to us needing development and testing of product designs, I suggested we put the Google design guidelines into practice.
How to tell if you need a product design sprint
A design sprint by definition adapts to the information you have in the room. It’s flexible enough that the same basic product design template can be adapted to work for almost any industry.
For me, the big sign that you need a sprint comes when you’ve spent months trying to figure something out, even if you know most of the details. If you have an idea that’s nagging away at you, a product design sprint is a low-risk way to scratch that itch. With a minimal investment of time and money, you’ll know whether the idea is worth pursuing, and you’ll have the tools to do so.
A product design plan generally works best when four things are true:
- You know your product and your market. Objectively, if you don't know anything about your product or market, you’re too early for a product development sprint. What you really need is a research sprint, and the time to find your place. A design sprint can tell you how to improve or extend a product — even how to launch a complementary product. But it can’t tell you what kind of business you should be in altogether.
- You know who your users are — and you can reach them. The user interviews we do on the fifth day of a Google Ventures design sprint are perhaps the most important part of the whole week. The goal is to get user feedback, and having the deadline of impending interviews forces you to make the decisions you need to make. If you can’t identify and book your users for the fifth day, I absolutely do not think you should do a sprint.
- A change has happened. Any time there’s an upheaval that you need to respond to, a design sprint can help. It doesn’t matter whether it’s a new market opportunity, a swing in user behavior or a new technology. If it’s causing a shift in the way people respond to your product, a design sprint can help you understand why and what to do about it.
- You’re ready to shake things up. A Google design sprint isn’t for folks who are largely happy with the status quo, or companies who want to work out the specifics around a small feature. A sprint is an opportunity to try something drastic, because you know at the end of the five days, users will tell you whether or not to invest more time and money into the idea. That makes it a great tool for companies that need a dramatic change in the business.
What the product design sprint process requires from clients
Five days in a room sounds like a huge investment — until you remember the many months it takes to design, prototype and test new products the old-fashioned way. We do our best to make it as unobtrusive for our clients as possible, but we do need representatives from the client’s team with us as much as possible during the week. We also need access to someone who can make the final call on any big decisions. There are only five days between ideation and putting a prototype in front of real users. We need a decider who can make the final call and keep things moving.
Before clients come into the sprint, we give them relatively simple homework to do. A lot of it will be things they’ve already done before: coming up with a problem statement, creating personas. The goal is to make sure all these ideas are collected in one place and fresh in the minds of everyone in the room. Often a team will go dig up an old set of personas they created, only to realize that they’re not all that accurate anymore.
We also ask that design sprint participants talk to people within their organization to make sure everyone is reasonably aligned. We’re not asking for total agreement — we don’t want the whole team to fall in line behind an idea that we quickly realize won’t pan out. But we do want some of the ambiguity to at least be identified and understood. Having these conversations ahead of time keeps us from spending the first day just trying to get on the same page.
How we run our own 5-day design sprint
The five days of a product design sprint are all labeled per the GV guide — understand, diverge, decide, prototype, validate. Here’s how we’ve adapted the design sprint checklist to get from business problem to validated prototype in one week.
Design sprint day 1
To kick off the week, we really just want to understand the problem so we can brainstorm solutions. We start the Google product design sprint by asking as many questions as we can. We end the day with an enormous amount of observations and notes about the users, the business context and our hypotheses. If we've done our job well, we identify what signals will tell us if the product has been successful or not. That's key. We're almost setting ourselves up to write the interview guide for day five’s usability tests on day one.
At Table XI, we’ve been using a process called an Inception to understand our clients’ business needs for years. The structure is very similar to day one of a design sprint — both are day-long sessions full of questions and fact-finding exercises. We’ve adapted Google’s template to incorporate some of the activities we do in an Inception. Things like “proto-personas,” rough sketches of users and their needs, and “hopes and fears,” a risk analysis exercise, are additions to the traditional design sprint, and ones we find highly valuable.
Everything we do is geared toward answering the same three questions — what are we doing, why are we doing it and who are we doing it for? We break the day up into four or five different exercises, so we can keep people engaged and make sure no one’s going unproductively down a single path. At the end of the day, we have a journey map that charts the steps users will have to take to complete the action the client wants. Then we highlight the pieces of the journey we're going to design prototypes for, which becomes a kind of checklist for the week.
Design sprint day 2
Day two we call diverge, because the team breaks up into separate corners to sketch out product ideas. It's based on the notion that the best way to get at different ideas is to have people individually focus on creating solutions. The moment you put two people in a room together there's a lot of synergy that starts to happen, and their ideas end up merging into one. It’s great — just not when you're trying to get a lot of ideas in a short period of time.
We start the day with a competitive analysis. Along the idea of diverging, we don't just look at true one-on-one competitors, we look at analogous examples too. Companies in the same industry often gravitate around similar ideas. When you look just outside of that sphere though, you can usually find a business that's fundamentally solving a similar problem in a different way. That’s where you can find some interesting ideas.
Before we start sketching, we share inspiration with a series of lightning demos, where each person takes three minutes to walk through three ideas they have. To get folks who aren’t used to sketching up to speed, we use an exercise called Crazy Eights, an extremely time-constrained sketching window designed to get people into a flow. Then we do pencil and paper concept sketches for the rest of the day.
Design sprint day 3
The third day gets really interesting, because we have to decide what path we’re going to take. This is the day we absolutely need to have client participation, especially from the designated decider.
We start with dot voting, where we place dots next to the parts of sketches we think are working well. It highlights the ideas that are ready for testing in a very visual way. GV does its sprints almost entirely with other designers, but because we often work with clients who don’t have a background in design, we added a step for people to explain their ideas. That way we get people’s pure reactions in the heatmap voting, but we make sure everyone understands the intention of the design before picking a final idea to prototype.
To pick the main concept we’re going to prototype, we use big-dot voting, where each person gets one vote. This is where we may call in the decider if things are close. Once we know where we’re going, we spend the rest of the day storyboarding. That gives us an opportunity to incorporate the pieces that worked from the designs we didn’t choose into the one we did. It also gets everyone on the same page about exactly what they’re prototyping.
Design sprint day 4
This is when we divide and conquer. The prototyping piece is straightforward. We split the prototype into pieces so we can build a testable model in one day. Then we have one person who’s assigned to be the stitcher, who puts the pieces together and matches the styles and flows to make a finished product.
While our designers are building, we assign our clients the job of gathering real content, so we can make sure the prototype is as realistic as possible. It also keeps them in the room for when we need to make last-minute decisions.
Design sprint day 5
Day five is when we validate. The whole week leads to this point — having the deadline of users testing your product really helps you focus the first four days, because you need to make sure there’s something there for them to see. We ask our client to find five people who are representative of the product’s target users. Then we get the prototype in front of each user individually so we can see how they interact with it and ask them questions about the experience. We deviate from Google’s sprint process and use a rainbow spreadsheet to quickly collect and visualize the responses. At the end, we synthesize the findings so our clients can share them internally, one last departure from the traditional product design sprint model.
We walk away knowing whether the idea shows promise. To get that answer within a week is key. Being able to quickly validate or invalidate a prototype allows us to throw away an idea without a lot of investment. Or, better yet, to continue down a path with a clear idea of what’s already working.
Want to get hands-on training?
What takeaways you get out of a design sprint
Clients are generally blown away by what they’re able to walk away with. At the end of a design sprint, they get a working prototype that they own. They can use the prototype to sell the idea internally, or to test it on more users. They can even take it to another company to build the finished product, though we’re always happy when they want to continue with Table XI. Clients also walk away with feedback from real users. They have the taped interviews, as well as our report on the findings.
Being able to see what people really think of the work right away is so powerful. It’s rewarding for us as designers, but it’s incredibly useful for clients. Instead of thinking about how a fictional user might respond, you get to see the reaction of a real user. When it goes right, it’s affirming. When it doesn’t, it can make you squirm. But it’s always educational, and it always leads to better products.
Right now we’re working with Rice University and Fiore Nursery and Landscape Supply to build the ideas that came out of the product design sprint process. We’re able to build much faster, because we already have a prototype and a working relationship with the client’s team. It’s the user feedback that gives the real value though. We don’t have to wonder whether users want what we’re building — we already know.