How we’re adapting Google’s Design Sprint to get testable prototypes in a week
In two weeks, we built and validated four prototypes and produced six branding treatments. We did it without late nights or tears. If anything, it made us a stronger, better group of designers. By adapting Google’s Design Sprint to fit our client’s needs, we were able to quickly understand a new market, develop ideas for innovative products and get those prototypes in front of users for testing.
It started with something entirely new to us — the world of European online sports gambling. The client, a UK-based sports gambling site, came to us wanting to test out an idea for a new product. The Google Ventures, now GV, Design Sprint gave us an opportunity to get up to speed on both the new industry and the new client as quickly as possible.
GV only formalized its Design Sprint a few months ago, when designer Jake Knapp published his book Sprint, but the designers at Google have been floating these ideas for two or three years. A GV Design Sprint places a team of designers in a room with the client for a week, using 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 these exercises are ones we've been doing in UX for a long time. It’s really kind of the classic case of innovation — take something that exists and reframe it. By putting all of these normal design exercises like sketching sessions and kickoff meetings into the structure of a sprint, we’re able to realize value we don’t normally get.
For the past year or so, I’ve been researching this idea and looking for an opportunity to implement it. I’ve talked with other designers, like Kyle Fiedler, Chief Design Officer at Thoughtbot, and heard how much value other teams were getting out of sprints. So when the client came to us with a product question that needed solving, it was the perfect opportunity to start putting these ideas into practice.
How we’ve adapted GV’s Design Sprint into our Product Design Workshop
Before we even started, we had already diverged from GV’s structure enough that we decided to call our process a Product Design Workshop. Part of that is the nomenclature. Sprint, thanks to its use in Agile development to denote a one or two-week block of building, seemed to imply working toward a finished product rather than validating an idea. At Table XI, we’re also highly collaborative, and we thought calling it a Workshop better captured that spirit.
The five days are all labeled — understand, diverge, decide, prototype, validate. Here’s how we get from business problem to validated prototype in one week.
To kick off the week, we really just want to understand the problem so we can start brainstorming solutions. We ask the client as many questions as we can and leave 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 GV Design Sprint — both are day-long sessions full of questions and fact-finding exercises — so it made sense to incorporate some of the activities we do in an Inception into our Product Design Workshop. Things like “proto-personas,” rough sketches of users and their needs, and “hopes and fears,” a risk analysis exercise, are additions to the GV Design Sprint model, 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. When we get stuck on a concept or a big issue and we can't come to a resolution, we actually table it. We put it on a sticky note, put it to the side, it's something we can investigate later. because generally if there's enough debate about one single issue it means we don't have all the facts. We also break the day up with four or five different exercises, so we keep people from going unproductively down a path, or getting too fixated on one question.
We come out of the day with a journey map — in this case a path of the steps users will have to take to compare sports gambling odds and determine which sites offer them the best potential return on their bets. Then we highlight the pieces of the journey we're going to design for, which becomes a kind of checklist for us to complete during the course of the week.
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 those ideas. 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 great when you're trying to get a lot of ideas in a short period of time.
We start the day with a competitive analysis, where we see what our competitors are doing that’s working well and what they’re doing that’s working poorly. Along the idea of diverging, we don't just look at true one-on-one competitors, we look at what we call analogous examples. You often find in one vertical, people have all gravitated around the exact same ideas. When you look just outside of that sphere though, and find something that's fundamentally solving a similar problem, just not in the same way, you can find some interesting ideas. With this client, the betting world had all coalesced around the same ideas, so we looked at travel deals site Kayak. It’s not betting, but it is a tool that lets users compare value. We can get at better solutions if we go down paths we wouldn’t normally follow.
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. Then we spend the afternoon sketching. We open it up with an exercise called Crazy Eights, an extremely time-constrained sketching window that gets our juices going. And then we do pencil and paper concept sketches for the rest of the day.
The third day gets really interesting. That's where we have to make a decision about what we're going to do. And the reality is, most of the time the answer is mostly this but a little bit of these other things. Day Three is also the day we really need to make sure clients are involved. We really want clients involved every day, but days one, three and five are the most critical.
To find out what ideas seem most viable, we spend the day voting. We start with heatmap voting, where we all take little dots and just post them next to pieces of the interfaces that we think are working well. After everybody does that, it almost forms a visual heatmap of ideas that are ready for testing.
Because we’re an agency working with a client, rather than an internal team like GV, we added some additional explanation to our Product Design Workshop. That way clients, who may not have a background in design, can understand the concepts we’re using in our wireframes. After the heatmap voting, we have everybody go through and 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.
Once everyone understands the product ideas, we do a series of big-dot votes. Everybody gets one big dot to vote on what concept they think works. And then, because it's so important to have one person clearly making the decisions, we ask one person on the client team to make the final call on where we're going. So on Day Three, we very quickly get down from what could be six to eight potential solutions to the one we should prototype.
Once we know where we’re going, we spend the rest of the day storyboarding. We know what design we’re going to build, but we also want to make sure we grab all the pieces that worked from the other designs. We take our time to storyboard it out so everybody knows exactly what we're building. That way on Day Four we can be heads down.
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. Again, we adapted the GV Design Sprint by using the sketching tools we normally would — Sketch and InVision.
The prototype piece is maybe not as interesting as what we ask clients to do during that day. We actually put clients in a content gathering role on Day Four. That way we can test with realistic content, and it also allows them to be in the room when we need to make a couple of decisions. It also gives them insight into the process, so they can see we’re trying to test an idea, not necessarily a polished design.
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 tool’s target users. Then we get the prototype in front of each user individually so we can see how they interact with the site and ask them questions about the experience. At the end, we synthesize the findings so our clients can share them internally, one last departure from the GV 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.
What a Table XI Product Design Workshop delivers
We got so much material out of this sprint, our client was blown away. We actually did two one-week sprints. In the first, we designed for a giant, innovative leap. In the second, we brought those ideas into a new iteration of tried and true concepts already in the marketplace. We also added a short branding sprint in the second week. And because our team going into this was a little bit bigger than normal, we ended up creating two prototypes to validate in each one-week sprint, as well as the six branding concepts.
Aside from just impressing the client — which is always the goal — the sprint allowed us to teach our client how Table XI works and what we need from them. Both the level of interaction as well as the ability to test ideas with their customers. A new client walks in with no expectations, so we can use a sprint to define what our relationship is going to look like. What will be really interesting is running a Product Design Workshop for an existing client, where we can reset the relationship and test our own assumptions about the business.
As a team, a Product Design Workshop is a great opportunity to shake up our normal workflow. Designers don't actually get to work together all that much. A project usually has only one designer, so we don’t get to work alongside each other. This gave us a chance to see and learn from each other’s processes.
The idea of just being able to see what people really think of the work right away is also so powerful. As designers, we’re all hungry to find out if what we’ve built is actually the right fit, and doing it inside of a week has a lot of rewards. It also has some pain. You're putting out something you've designed and watching people use it and sometimes fail. But it's really educational.
The more we get designs in front of users, the smarter designers we become and the better results our clients get. And a product design workshop allows us to do that faster than any other process.
Have an idea you want to test? Email me.
Published by: Zeke Binion in Design