At the Google Ventures Design Studio, we have a five-day process for taking a product or feature from design through prototyping and testing. We call it a product design sprint. This is the fifth in a series of seven posts on running your own design sprint.
At this point in a design sprint, you’ve got a lot of ideas down on paper. You’ve explored the problem, generated a ton of solutions, and looked around at how other companies are solving similar problems.
It’s awesome to have a lot of ideas. It’s a great feeling. But I’ve got bad news: You can’t build and test everything. And even if you could, it wouldn’t be very useful, because you’d have too much information to sift through. So you’ve got tough decisions to make: Which solutions will you pursue and which will you put on ice?
Today we’ll look at how to decide which solutions to flesh out, and how you’ll fit them together into something you can rapidly test with users to learn what’s working and what isn’t.
COMBAT THE GROUP EFFECT
The decision-making process is hard, and this is one place where working as a group can become a liability. Companies and teams have a natural way that they make decisions—but in a sprint, the group effect can cause decision-makers to behave more democratically than they do in real life. Once the sprint is over and that rosy democratic feeling wears off, you can be left with something that doesn’t have true support from the deciders.
To combat this effect, the facilitator often has to draw out the decision-maker to give their honest, true opinion. You’d be surprised at how often this reluctant decision-maker is the CEO. No way, really? Yes way. In the sprint, people are out of their comfort zones, and even CEOs can begin to behave in non-standard ways.
Trending: How to Transform Daily Habits into Life-Changing Rituals
One method is giving “super votes” to the deciders during design critiques, which you did in day 2. But most of the time, there are no special techniques. You just have to be blunt.
As facilitator, you should be upfront with the team if you sense you’ve got a case of groupthink. Let everyone know that you need more assertive participation from the deciders. Additionally, you should have the words “make the call, Sally” on the tip of your tongue throughout day 3. (I’m assuming your CEO’s name is Sally.) Don’t worry about being a sycophant. If you aren’t conscientious about bringing the decider in now, you’ll have a problem later.
SEARCH FOR CONFLICTS
The first thing I like to do in this phase of a sprint is comb through storyboards from the previous day looking for conflicts. A conflict is a place where there are two or more different approaches to solving the same problem. Conflicting approaches are super helpful, because they illuminate the choices for your product.
For example, let’s say you’re designing your homepage, where you explain your product to potential customers. Maybe one person’s storyboard uses a video, and another uses diagrams on a long scrolling page, and a third uses a single image of the product. Great, you’ve found a conflict! Every time you find one, write it down. I like to put the topic and solutions on sticky notes, like this:
Each conflict is like a little gold mine. In business-as-usual design, designers often end up picking one approach and going straight to high resolution. When I was working on products in-house, I’d often get so caught up in that one solution that I wouldn’t even have time to think about how else it could be done.
So one of the best things about the product design sprint is that it allows you to map out those decision points, and perhaps even to explore a few conflicting ideas in parallel, instead of immediately committing to a safe choice.
BEST SHOT OR BATTLE ROYALE?
You have two basic options for what kind of user study you’re going to run at the end of your sprint. You can prototype several different approaches and test them against one another (the “battle royale”) or you can go with a single prototype (the “best shot”).
The advantage of the “best shot” approach is that you can put a lot more work into that one prototype, or just get it done faster. If you’re testing only one solution, the user study is less complex, and it gives you more time to see what the users say about your competitors’ products (or just interview users, which is always surprisingly valuable for teams).
The “battle royale” works well for newer spaces where there really aren’t many conventions, and you need to figure which one is going to work best for the user. The disadvantage is that it takes more time, and your testers may run out of patience before you get all of the information you’d like to have from them. You may have to bring in more participants and run more studies.
On the upside, the results of a “battle royale” can be very surprising. When working with startups, I’ve often seen a dark-horse design turn out to be the strongest in user studies. When that happens, we thank our lucky stars we didn’t “best shot” it, or we never would have known.
You may also do some kind of hybrid. Occasionally, if you choose the “best shot” approach, you’ll get into testing and find that something’s really not working in your prototype, and you need to go back and have a “battle royale” over that specific feature.
Trending: 5 Reasons Life Gets Better After Your 40s
So how do you know which to pick? Start with a gut check: If everyone is excited about one option, you may be ready for a “best shot.” But if it feels more like you’re sitting there and scratching your heads about what to do next—or else you want to throttle each other because those fools just won’t agree with you—well, you may need a “battle royale.”
TEST YOUR ASSUMPTIONS
What else should you test in your user study? Listing out your underlying assumptions is a good way to revisit the big picture, especially when you’ve been heads down in a sprint for a few days.
Some of those assumptions might be about the users (example: “Users are willing to upload a profile photo”), some about the business (“the designer-with-glasses-and-beard market is large enough to support our product”), some about technology (“we can automatically cluster profile photos by beard shape”), and maybe even some about messaging (“people will still find beard jokes to be amusing, even for the third time in a single paragraph”).
I can tell you that last assumption is false right now, but for most others, you’re going to need some kind of research. Guess what? You can test a bunch of them by showing a prototype to users.
For example, if you have a big assumption that users will be comfortable sharing private data in your product, you may want to pick the most aggressive sharing defaults you can think of to prototype. When you show it to users, you’ll find out pretty quickly whether your assumption was correct.
Try to come up with a way to test all your assumptions, either in the user study or in some other parallel task that can start right away (e.g., ask the engineers to spend a few hours hacking at that beard-clustering algorithm). If you can’t test every assumption now, keep a list for next time. Untested assumptions are like takeout containers in your fridge: If you leave them for very long, things get nasty.
OK, you’ve picked which conflicts to explore and you’ve decided which assumptions to test. Congratulations—you’re ready to script your prototype.
WHITEBOARD THE USER STORY
Now we’re going to make a storyboard that shows exactly how the user will step through your prototype, click by click. This storyboard will become the spec for building the prototype. This is an activity that the group does together—it’s actually the last group step before you break for prototyping.
Trending: 5 Simple Strategies for Persuading Anybody
Start by drawing a big grid on the whiteboard—each cell should be about as large as two sheets of copy paper, and for most sprints, you’ll cover one or two whole whiteboards with your grid. The idea is to draw a comic book that tells a story starting when the user opens the prototype and ending when they complete all necessary tasks.
In each comic book frame, you’ll draw a single action—whether it’s a pointer clicking on a button, text being entered, or a stick-figure user doing something in real life. You don’t have to worry about layout or design in great detail, but you do have to think through every action that takes place in the story.
Drawing the storyboard is hard work, and you’ll want to facilitate carefully. Get one person to draw, but don’t make them figure everything out on their own. The group should be engaged and discussing what happens next and giving that brave soul holding the whiteboard marker as much help as possible.
When you begin drawing, imagine you’re framing the prototype for your user study participant. How will they get to your product? What will they be trying to do when they get there? That’ll help you figure out whether the first frame of your comic book is an email or a Google search or an advertisement or the App Store or whatever—and hopefully the story will flow easily from there, following the outline you laid out in day 1.
KEEP THE GLOVES OFF
As you storyboard, there will be lots of small decisions to make that didn’t come up earlier in the day. That’s expected, since you’re working at a finer level of detail now. The facilitator has to work hard here to not let people be too nice. You don’t want design by committee. If there’s a good argument going, don’t try to find middle ground or make people agree. Help the team place a bet on one of the opposing solutions and keep the other in your back pocket if it fails. Call on the CEO to make a tough call when needed. If both solutions are viable, you may want to opt for a “battle royale”—just don’t use it as an excuse to avoid decisions.
When you’re finished with the user story, take a moment to pat yourselves on the back and eat some chocolate because it’s probably been a pretty epic task. You’ve given form to everything you want your user study participant to experience, and you’re ready to turn that story into a higher-resolution mockup.
In the next post, we’ll move on to prototyping. It’s time for the Fellowship of the Sprint to break up, at least temporarily, as everybody puts on their headphones and cranks out a crafty imitation of a real product. Stay tuned.
