How to Validate Ideas With a Design Sprint

What is a Design Sprint?

A design sprint is a 5-day methodology used to discover, reverse-engineer, and solve problems using customer research, rapid iteration, prototyping, and user testing. Think of it as fast-forwarding into the future, testing real-user reactions to an idea before wasting time and money actually building it. The sprint methodology was invented by Google Ventures’ Jake Knapp, and is used by top companies such as Slack and Medium.

Design sprints can be used to prototype and test new products, extend the functionality of existing products, or improve the UX of existing products.

In typical uxtricks fashion, let’s kick things off with a little scenario.

Jetpack Sneakers 👟

We experience a problem, and/or, we notice that others are experiencing it too. Let’s assume the issue is that users are always running late in big cities with heavy influxes of traffic at rush hour times. We come up with a solution. Let’s say…jetpack sneakers?

Right off the bat, we’ve made two mistakes already.

Firstly, we’ve assumed that others are having the same difficulties (false consensus effect), when in fact we don’t know this to be true until we’ve conducted user research.

Secondly, we can’t know if our solution is the right solution (or if our solution is even viable) until we’ve tested it. Design sprints enable us to approach ideation with an open mind and iterate over a number of solutions, rather than valiantly obsess over one. Since it’s human nature to show bias towards our own ideas, it’s worth learning about debiasing beforehand, as it helps to alleviate ourselves of any biases and assumptions.

Back to Jetpack Sneakers…

Jetpack sneakers could encounter the following roadblocks:

• Manufacturing costs could be high, making them too expensive 😅
• Customers might require the ability to customize the sneakers ☝️
• People in the sky = disaster, they could be subject to health and safety law 🤯

By running a design sprint we’re enabling ourselves to realize these roadblocks before it’s too late, or even sidestep the idea completely in favor of a better one. Design sprints can yield surprising results, but we’ll 💯 end up with a better understanding of our users (and a number of ideas, one of which will be tested and possibly validated).

In today’s article we’ll learn how to conduct our own Google Design Sprint! 🎉

Day 1: Research

Monday/day 1 involves agreeing on a long-term objective, and conducting research to see what we can build, fix, or improve upon that will lead to this objective being met.

In a nutshell:

• 10am: introduce everybody, explain the sprint methodology
• 10:15am: clarify the long-term business objective
• 11:30am: create a user flow diagram of the current design
• 1pm: lunch 🥑
• 2pm: with user research, identify problems that users are having
• 4pm: consolidate the user research
• 4:30pm: choose one customer and one aspect of their user flow

Step 1: Checklist (~10am)

Write down the above (^) checklist on a whiteboard—this ensures that the design sprint runs to schedule. Remote teams can use online whiteboard tools like InVision Freehand, AWW App, or RealtimeBoard. Once step 1 is complete, check it off the list.

Step 2: Avengers Assemble (~10am) 👋

Gather 4-7 team members for best results.

It helps to acquire team members from a range of different departments within the company (e.g. marketing, customer service, development, etc), although design sprints can still be effective with a team of two or three as long as there’s at least one designer.

Name one facilitator, and one decider. A facilitator helps to move things along, and a decider has the final say. A facilitator should feel confident enough to request the role, enforce regular breaks, keep the team energized, and constantly ask “Why?” to ensure that the team reaches thoughtful conclusions. A decider should be able to make solid decisions when requested, as slow decisions will destroy team spirit and drain energy.

Within startups, the decider is often the CEO (improvize when necessary).

Here’s an example of a full sprint team 👏👏👏:

Step 3: Explain the Sprint Methodology (~10am)

As mentioned above, the team needs to understand what a Google Design Sprint is, and how the sprint methodology works. Google Ventures has a slide deck that explains.

Step 4: Get Optimistic (~10:15am) 😃

“Why are we doing this project?”

Write the long-term objective on the whiteboard.

Example: convert 15% of customers to a higher-tier subscription.

Step 5: Get Pessimistic (~10:15am) 😨

“What could go wrong?”

Convert fears into questions that the design sprint could answer.

Example:

• Fear: 15% of customers won’t convert
• Question: why won’t 15% of customers convert?
• Answer: to be determined during the design sprint

Btw: don’t forget to take short but regular breaks!

Step 6: Make a User Flow Diagram (~11:30am)

Move to a new whiteboard.

Place customers on the left, and the long-term objective on the right. Create a flowchart in the middle (5-15 steps) depicting the current user flows of the app or website (i.e. how do customers interact with the product in its current form?).

Note: this user flow diagram is sometimes referred to as a map or user story.

Step 7: Eat Lunch (~1pm)

Eat together, as a team 💪.

Step 8: Gather Research (~2pm)

Interview experts (reporter-style) on and outside of the team. Ask what they know about the customers, ask about any efforts to achieve the long-term objective (or similar objectives) previously, and anything else that might be relevant, or could be useful to know before diving deeper into the design sprint. Make each “interview” 15-30 minutes, to ensure that a variety of insights are collected within the next two hours.

Desired outcome: insight into problems that customers are experiencing.

Step 9: Reframe Problems As Opportunities (~2pm)

With markers and sticky notes, turn the problems into opportunities. Begin each opportunity with “How Might We…” (read about HMW notes here) and add them to a stack. When conducting a remote design sprint, RealtimeBoard and AWW App both have sticky note features, so either are a decent option for remote design collaboration.

Example:

• Issue: customers don’t know about the higher-tier subscription
• HMW: “How might we tell customers about the higher-tier subscription?”

Step 10: Organize HMW Notes (~4pm)

Add the HMW notes to a wall or whiteboard. Group repeating or similar ideas, and be mindful of common themes that appear. Don’t spend more than 10 minutes on this.

Step 11: Vote on Ideas (~4pm)

Now it’s time to decide which HMWs are the most opportunistic.

Everybody has two votes. Members can vote on their own HMWs, and/or they can add two votes to the same HMW. Focus on issues where, if the issue were fixed, it would contribute to the long-term objective. Add the clear winners to the user flow map.

Create a “misc” section for HMWs that don’t relate to a specific aspect of the user flow.

Below: a user flow map with HMW notes, by NileHQ.

Step 12: Pick a Target (~4pm)

Identify the most important customer on the map, bearing in mind the long-term objective (i.e. which customer is likely to help us achieve this objective?). In addition, identify the key aspect of their user flow, bearing in mind the opportunities described in the HMW notes (i.e. which aspect of the user flow is the most opportunistic?). While the facilitator ensures that everyone speaks their mind, the decider makes the final call.

Remember: a design sprint only lasts for 5 days. Don’t worry if some HMWs (or some aspects of the user flow) become excluded, we can tackle those in another sprint.

Day 2: Iterate

Here’s our next set of challenges:

• 10am: collect inspiration
• 12:30pm: divide or swarm
• 1pm: lunch 🥑
• 2pm: sketch solutions

Step 1: Lightening Demos (~10am)

How are other companies solving the same issues outlined in the HMW notes?

Find epic solutions from other companies. Demo each solution for three minutes, sketching them on the whiteboard where team members can refer to them later.

Step 2: Divide or Swarm (~12:30pm)

Soon, the sketching begins ✍️.

Decide who sketches what before breaking up for lunch.

If the aspect of the user flow that we’re targeting is still somewhat complex, we have two choices. We can either narrow the target a little more (even if it means tackling fewer HMWs) and have the team swarm it, or we can divide the target into even smaller steps and evenly distribute them amongst team members. Swarming tends to work out better, as dividing means that nobody thinking about the user flow holistically.

Once again, the decider makes the final call.

Btw: it’s totally fine to choose a small target and only a handful of HMW notes.

Step 3: Lunch (~1pm)

Once again, eat together as a team 💪.

Step 4: Four-Step Sketch (~2pm)

Group brainstorming doesn’t work. The cognitive load from listening to each other speak while trying to think stops us from developing our best ideas, so we’ll explore solutions individually, then assess them together. Remember to sketch easily understandable solutions, don’t. try. to. be. a. perfectionist. Words and shapes are fine.

Here’s how the four-step sketch works:

• Step 1: take notes for 20 minutes
• Step 2: sketch rough ideas for 20 minutes
• Step 3: sketch 8 variations of the best idea for 8 minutes (“Crazy 8’s”)
• Step 4: turn the best variation into a simple 3-step storyboard (10-20 minutes)

Keep in mind the following:

• Paper is faster (although wireframe tools are suitable for remote teams)
• Thick markers will stop us from sketching in too much detail
• Bit Timer will keep us on track (remember: 8 sketches/8m = 1m per sketch!)
• If you reach a mental block on the Crazy 8’s, explore one of the other ideas
• Give each storyboard a name, so they’re easy to refer to in team discussions

Below: Crazy 8’s.

Step 5: Recruit User Testers

One team member should set aside an extra 1-2 hours everyday for recruiting user testers. Post an ad on Craigslist—link to a screener survey to weed out respondents not within the target audience (and naturally, don’t reveal who the target audience is).

If the target audience isn’t your average Joe, try asking the client. If all else fails, try searching within niché communities such as subreddits or Facebook Groups.

Quick tips for recruiting user testers:

• Gift cards can sweeten the deal 😉
• Make scheduling easier with Calendly
• Make use of existing customers (where it makes sense)
• People are finicky, follow up numerous times throughout the sprint

Day 3: Decide

Wednesday/day 3—we’ll critique the solutions, decide which one has the best chance of aiding the long-term objective, and then we’ll create a more detailed storyboard.

In a nutshell:

• 10am: isolate the best solutions
• 11:30am: decide on the ultimate solution
• 1pm: lunch 🥑
• 2pm: create a more complex storyboard

Step 1: Review the Solutions (~10am)

Place the solutions on a whiteboard, or distribute sharelinks if using digital mockups. Have team members review the sketches independently, making mental notes of what they like/don’t like. After that, spend 3 minutes reviewing each storyboard as a team.

Step 2: Poll the Results (~10am)

Next, everyone “dots” the solution they like best.

• Ensure all solutions are anonymous
• Don’t let new ideas creep in, it’s too late
• The decider has 3 additional dots (“Supervotes”)

Once the voting is over, the decider uses their 3 supervotes to chose 3 solutions.

Step 3: Maybe Later (~11:30am)

Can the supervoted solutions work as a single prototype? If not, move the conflicting ideas aside so that we can explore them another time. Put it to a “dot” vote if needed.

Decider has final say…blah, blah.

Step 4: Eat Lunch (~1pm)

We are eating healthy 🍌, right? Good. Just checking.

Step 5: Storyboard the Prototype (~2pm)

Designers: step onto the stage!

Storyboard between 5 and 15 scenes, expanding upon the original 3-step storyboard. Keep the opening scene simple—how does the customer enter the story? Web search?

Next, think about the rest of the user flow and how the customer interacts with our solution. What are they trying to achieve? Remember, we have 15 scenes to work with.

If you hit a snag, start over. Don’t stall.

Below: a storyboard sketch, by Whitesmith.

Day 4: Prototype

On the fourth day the interviewer writes a script for tomorrow’s user tests while the designer(s) engages in some prototyping (using the storyboard as a roadmap).

Here’s the checklist:

• 10am: begin prototyping
• 1pm: lunch 🥑
• 2pm: stitch the story together
• 3pm: test the heck and hell out of it

Step 1: Prototype the Storyboard (~10am)

Start by deciding who’ll focus on which scene. If only one team member is prototyping, assign others to collect assets (if needed), or generally be ready to assist and advise.

Next, decide which tools will be used 🛠.

Prototyping tools tend to ship with user testing features, making them ideal for design sprints. However, some are designed for creating high-fidelity mockups, making it way too easy to obsess over little details. Ideally, what we’re looking for is a wireframe tool that lets us mockup a lo-fi storyboard quickly. Here’s our shortlisted recommendations:

Great for design sprints.

• Balsamiq (wireframes, user testing)
• Marvel App (wireframes, user testing)

Good for design sprints, but the hi-fi tools could be distracting.

• Justinmind (wireframes, user testing)
• UXPin (wireframes, user testing)
• Adobe XD (wireframes w/Wires, user testing)

Also good for design sprints, but again, the hi-fi tools could be distracting.

• Sketch (no wireframe components, but has user testing)
• InVision Studio (no wireframe components, but has user testing)

Remember: keep the prototype simple, don’t spend too much time on it (but also, don’t rush it either). Aim for basic, not rough, the user should be able to make sense of it.

Below: a low-fidelity wireframe made in Balsamiq.

Step 2: Eat Lunch (~1pm)

You know the drill 🌶.

Step 3: Stitch the Story Together (~2pm)

Prototyping can be a team effort, as described above. If this was the case, spend the next hour stitching the story together. Prototyping apps ship with user flow tools, so this is an easy enough task for an assigned “Stitcher”, who should also check to ensure that any scenes mocked up independently also make sense when stitched together.

Step 4: Self-Test the Prototype (~3pm)

Self-testing is the final line of defence before real users do their tests. Yikes!

Prototyping tools have a neat little feature called device preview, which allows stakeholders to test prototypes on real devices, as if it were real thing. Go nuts! 🥜

Behind the Scenes: Planning User Tests

As mentioned above, the interviewer will spend the day writing the script for tomorrow’s user tests. Important but often forgotten: a friendly introduction (to break the ice), a reminder of why we’re conducting these user tests (to set expectations), and assurances that there are no right or wrong answers (to make the tester feel relaxed).

Open-ended questions are the most effective (i.e. avoid yes or no questions, and instead allow the user to express their thoughts freely). Most importantly, we can call these user interviews a success if they answer the sprint questions outlined in day 1.

Desired insights: thoughts, feelings, actionable feedback.

Day 5: Validate

Day 5, the final day of the sprint, the moment we’ve been waiting for. After today’s users tests we’ll either learn that our solution is a flawed success (possibly ready for refinement using UI design tools), or we’ll learn that our solution isn’t the right solution, in which case we’d evaluate the user feedback and decide on a new course of action.

Day 5 takes care of some rather delicate matters, hence, there are no time-restrictions.

Step 1: Interview Setup

We’ll conduct the user tests using a technique known as the Five-Act Interview, but before that, let’s make sure that we’re ready to rock and roll. We don’t want to seem disorganized in front of our user testers; after all, they could be our first customers!

While the traditional design sprint methodology outlines tips and tricks for setting up a makeshift research lab, it’s actually much easier to conduct the user tests remotely.

Benefits of remote user testing include:

• Integration with prototyping tools
• The ability to rewatch user interviews easily
• Minimal setup, no need to invite users to a real location

Lookback and UserTesting (which integrate with Marvel and InVision respectively) allow stakeholders to quietly listen in on a user test via invite link. Non-interviewers should be off-camera. Have a couple of team members test the setup beforehand.

Have another team member draw a table on the whiteboard—include a column for each user tester, then add a row for each scene in the storyboard. This is where we’ll record the feedback. For remote user testing, Google Sheets is a suitable solution.

Be ready to take down notes. This happens on paper to begin with, not the table we’ve created. Minus the interviewer, the entire team (the more ears the better) should be ready to observe and note down reactions, exact quotes, facial expressions, and so on.

We’ll normally start to see patterns after 5 interviews.

Additional tips:

• Make the user tester comfortable, be friendly and approachable
• If deviating from the script, remember to ask open-ended questions
• Encourage the tester to think aloud and speak freely
• But…be silent when needed, to allow the tester to think and speak
• Be authentically interested in what the user tester has to say

Below: various user interviews recorded using Lookback.

Step 2: Five-Act Interview

Start with a friendly welcome. Thank the user for coming and remind them of why they’re here, but also explain how their honest feedback helps us significantly.

Move onto small talk to help the user feel even more at ease, but gradually steer the conversation into the topic we’re trying to learn more about (in the broader sense).

Next, bring out the prototype. Make it clear that some things may not work, and why. Remind the user that we’re testing the effectiveness of our solution, not the user’s ability to use it. Remind the user to think aloud, and speak freely and honestly.

Let the user kick things off by themselves, as they would if they were discovering our solution by ordinary means. When the user makes a comment, ask follow-up questions. When the user has a non-verbal reaction, remind them to think aloud. Be genuinely interested in what they have to say—focus on extracting useful insight and feedback.

Finally, debrief. Ask the user to summarize.

Step 3: What Happens Next?

Move notes into the table, then as a team attempt to draw conclusions based on recurring feedback. Label feedback as positive, negative, and neutral. End the day by reviewing the long-term objective, answering the sprint questions outlined at the beginning of the design sprint, and deciding how to move forward with the feedback.

Options include:

• Creating a high-fidelity prototype (assuming the idea was validated)
• Reworking the solution and conducting follow up user tests
• Conducting another (but shorter) sprint to explore an alternative idea
• Conducting another sprint from scratch (this time tackling something else)

…

Regardless of the outcome, we should be damn impressed with ourselves. We started the sprint with a big challenge and nothing else, however, we managed to sketch and storyboard an abundance of excellent ideas, build an interactive prototype, and even convince a bunch of unknowing user testers to take time out of their lives to offer us their feedback…all in 5 days. At the end of the sprint, our solution, even if not the right solution, should yield enough insight to drive the next step (whatever that may be).

Conclusion

When trying to accomplish…well…anything, these anythings always take longer than we think they will. Today’s tasks tend to turn into tomorrows tasks. Why? Because we’re all perfectionists, at least subconsciously. Conducting a Google Design Sprint allows us to break free from these habits and validate ideas quickly. It’s like cramming weeks/months of work into 5 days, but, the rewards are the same (if not even greater).

All teams do design sprints a little differently, especially experienced teams that have tweaked their workflow over time through trial and error. AJ&Smart even went as far as inventing a 4-day sprint, now known as Design Sprints 2.0. 3-day sprints also exist.

Jake Knapp outlines the original sprint methodology in his sprint book.

If you’d like to read this article (and more) in ebook format, download A Beginner’s Guide to Designing UX to learn more about full-stack user experience design 💪.

Got feedback? We’d love to hear it! Send us a tweet @uxtricksdesign.