10 Tips for Successful Design Sprints

Blue Bottle’s most interesting finding? Contrary to expectations, the sprint helped it realize consumers don’t purchase coffee based on its place of origin. In just five days, the consultants helped Blue Bottle prototype a user-friendly interfaced designed to help customers decide on coffee that was instead suited to their brewing preferences.

But the design sprint process isn’t just about creating better websites, and it certainly isn’t just for coffee companies. In fact, Google Ventures has used its design sprint process to build up-and-coming companies — including Uber, Medium, and Nest — across a wide range of industries. So whether your company is building its next product or working on its first IoT project, it can use the design sprint methodology to challenge user assumptions, create a prototype, and test it among real consumers.

Yeti conducts design sprints across five stages, split among five days. If your company is considering running a design sprint, here are some tips on how you can make the most of it:

Know when to sprint

Sprints are meant to make the once messy design process more approachable. But before any product design can take place, the sprinter must come prepared with a testable vision. So if you haven’t done your homework, it might be best to wait until you’ve identified a distinct problem and a potential solution. Signs that a sprint might not be your best course of action include:

• There’s no clear opportunity for improvement with new solutions
• There’s little to no user data available to support your vision
• The project is very short in length
• There’s no clear business opportunity in solving the problem
• The problem is too broad to be investigated with a single prototype

Identify your ‘why’

Ask yourself, “Why should my product exist?” To lay the groundwork for a successful sprint, you’ll need to know what problem you want to solve and how the solution better serves the target customer. Look at any appropriate analytics data, interviews with users, and business goals to help identify your “why.” This saves valuable sprint time, clarifies the reason your team is engaging in the sprint, and helps identify which technical experts you’ll need to involve.

Choose your space

One important — and often overlooked — decision involves the space in which the sprint is to be held. While a sprint can succeed nearly anywhere, its chances of success rise in a location that inspires creative thinking and engaged discussion. Choose an area with large whiteboards or clips to hang giant sheets of paper. Moving spaces can cause creative upset, so if possible, run all stages of the sprint in the same room.

Pick target users

The final day of the sprint involves testing your solution on potential customers, so contact five potential users before the sprint begins, and coordinate with them. This helps you think not just about a demographic, but also about a specific person’s needs and motivations — a crucial step to avoiding a product-market mismatch. Try testing competitors’ solutions on users to better understand the product’s market.

Commit to the sprint

It can be daunting to clear your calendar for an entire week, but design sprints are all about sacrificing a few resources now to save heaps of them later. If you can validate a product’s assumptions (and its market fit) within a week, you’ve saved yourself months of work.

Successful sprints, however, require an involved decision maker. The product owner must be present at all times, or at the very least, should appoint a team member to speak on his or her behalf. Other team members who should be committed to the sprint include representatives from design, engineering, customer support, marketing, and finance. Each should be available as needed to consult on discussion of feasibility and customer needs. At the end of the fifth day, all contributors should regroup to discuss the sprint’s findings.

Put away devices

Computers are essential tools for looking up user research or building the prototype, but we recommend everyone stow their digital devices during the rest of the sprint. We all know how easy it is to get distracted by an incoming text or email. If somebody does need to take a call, have him or her take a quick break so as not to distract others.

Prepare to improvise

While a schedule is crucial for design sprints, so is appropriate improvisation. Five days is a long time for everything to go according to plan, so be agile when outside factors affect it. For example, if the product owner is called away on an urgent out-of-town meeting, you’ll need to gather all of his ideas before his departure and delegate a new decision maker. Or, if the prototype fails when testing, be ready to get out the paper sketches to walk testers through the software’s interfaces.

Keep an open mind

When you choose a problem to explore solutions around, you’ll need to accept that others have valid ideas — even when they conflict with your own. If you’re not willing to examine every solution, you might miss out on the sprint’s most valuable idea. For example, knowledge from baristas — who might seem like small players in the sprint — were key to Blue Bottle Coffee’s website redesign. Although they might not have the top-down view of Blue Bottle’s CEO, they did have hands-on knowledge of the brand’s coffee blends and customer preferences.

Designate a facilitator

A facilitator has the power to make or break a design sprint’s outcome. Good facilitators manage group time, guide conversations, resolve disputes, and remain objective when discussing others’ ideas. Choose a facilitator who’s unafraid to curb tangents and tell others when it’s time to move on. Conversely, this person should also be able to judge when a discussion warrants further exploration at the expense of the schedule.

Appreciate the value in any outcome

Even when they steer a client away from a potential project, design sprints provide value. You should leave a design sprint feeling invigorated with validated (or invalidated) customer assumptions, a prototyped solution, and demonstrated savings in time and money. Your design sprint will result in one of three outcomes:

• Every assumption is correct, and the prototype is perfect. In this rare outcome, teams should question whether they sufficiently pushed testers for feedback. If they have, the team should pursue a roadmap to build the product.
• The tested prototype proved some assumptions and invalidated others. This is the most common outcome, and it encourages iterations. Next steps may include abbreviated sprints or additional research before starting to build a solution.
• The tested prototype is a total bust. Sometimes, the tested solution might be way off the mark. This could mean the market isn’t ready for your solution, or it could mean users aren’t experiencing the problem. This can be a frustrating outcome, but don’t despair: It means your business has saved thousands of dollars in not building a product that nobody would use. This means it’s time to do more research, brainstorm new ways to solve the original problem, or determine a new problem to solve.

Product development can be intimidating when you’re doing it alone. If you’re about to build a new product, don’t waste valuable time or money on an idea destined for failure. Consult with Yeti to conduct a fruitful sprint with the proven design sprint methodology.

For more background information & best practices on design sprints, check out our recent post which provides an Intro To Design Sprints.