When Should You Use Design Sprints for User Research?

Design sprints are fast-paced, exciting, and encompass every reason I left academic research.

As a researcher, I usually get to facilitate the design sprint and help people unlock their creativity, all with a dose of user testing.

But I haven't always been a huge fan of design sprints. When I first learned about them, I wasn't sure how I was supposed to squeeze user research into a day.

However, after a few sprints (some of them failed), I got my groove, and I saw the benefit of this quick testing cycle. I started to have fun and look forward to these jam-packed days.

Here are some of my secrets.

Jump to:

• What's a design sprint?
• When to NOT use design sprints
• How to incorporate user research into your design sprint

First, what's a design sprint?

There are about a thousand books and articles on design sprints, but the most popular (and my favorite) is Sprint by Jake Knapp. Although the byline is a bit lofty—"Solve big problems and test new ideas in just five days”—Knapp filled his book with good information on ensuring more human-centricity in your product development process.

In his book, Knapp defines a sprint as "a unique five-day process for answering crucial questions through prototyping and testing ideas with customers." What does this mean?

You take a problem based on previous research, brainstorm, ideate, test, and iterate. There are five days in a working week, and in a design sprint, each step correlates with one day.

Ideally, at the end of the sprint, you have one or two validated prototypes the team can move forward with developing. It is a quick way to help a team move forward with an idea.

Sounds like a magic bullet, right? It's easy to see them as one. But design sprints aren't meant for every problem.

When to NOT use design sprints

Design sprints are fast and fun, making them a tempting option. However, design sprints have a time and a place. I have seen them misused, leading to confusing results, a waste of time, or procrastination.

So, when should you avoid using design sprints?

Your problem is unclear

Design sprints were created for us to solve a problem. If you aren't sure of the problem you’re trying to solve or "have some cool ideas," a design sprint isn't the right tool. First, brainstorm a problem or need users have, and then design sprints can help.

You haven't based the problem on previous research

Is the problem a business problem? For example, are you trying to "fix churn rate" or "increase newsletter sign-ups?" Sure, you can come up with a million ways to potentially fix this, but your scope will be terrifyingly huge. Instead, use previous research to pull out your users' needs or pain points and start there.

A lot of research is needed

I have seen a team try to create personas through a design sprint. Personas and other generative methods require significantly more participants and analysis time. Additionally, some complex products and flows need more than a quick 30-minute usability test. Make sure your research needs for the sprint align with what you can fit into the day.

The scope is too small

"Should we add this button" or "should we change the colors of our headers?" If the scope is very narrow, you won't get meaningful information. Think about whether or not you can decide without research first—there is always A/B testing!

The scope is too broad

Alternatively, we can't use a design sprint to "reinvent the way people travel" or "rehaul our entire product." These topics are too big to cover in one week and leave teams disappointed when there isn't enough information to make an informed decision.

Design sprints aren't product development

Agile sprint, design sprint. Sounds similar enough, right? Can't we replace design sprints with other sprints? They are faster and cheaper. Nope! Design sprints and agile sprints have entirely different goals and outcomes.

Agile sprints take a big problem and break it down into smaller chunks of work and tasks within an agreed timeline. Design sprints help us get quick brainstorming and feedback on ideas. Design sprints can come before agile sprints but can't replace them.

So, where is the balance?

Now that we understand when design sprints won't serve us, how do we know when we have a problem perfect for a design sprint?

• Your problem is clear and based on previous research, such as user needs and pain points.
• The problem can be solved within five days by the team
• You can understand usability through testing with five participants (and have time to test with them)
• You are willing to continue to iterate (the design sprint isn't the end!)

Incorporate user research into your design sprint

As I mentioned, there are five steps within a design sprint:

1. Day one: Empathize. During this phase, you and the team agree on a problem and goal for the sprint. Once this problem is defined, you gather knowledge about that problem and map it out.
2. Day two: Ideate. The second day is about creating ideas based on the problem. You review the existing ideas (from the research) to improve. This day is filled with sketching and brainstorming.
3. Day three: Decide. After a day of brainstorming a bunch of ideas, it’s time to narrow them down. The team decides which ideas have the best chance of solving the agreed-upon problem. These ideas go into a storyboard.
4. Day four: Prototype. Turn the storyboard(s) into a prototype that you will use to test with people the next day. The team comes together to make sure the prototype(s) are complete and ready for tomorrow.
5. Day five: Test and iterate. This day is about testing the chosen ideas with users and learning how they react to your prototype. You can then continue to iterate with your team based on the feedback from users.

Here is how I incorporate user research into each of these stages:

Day one: Empathize

Once this problem is defined, you can start uncovering knowledge about the problem. User research is crucial for this phase.

In this step, you conduct stakeholder interviews and review previous research. Additionally, you bring this information together into a deliverable, such as a journey or empathy map.

Also during this stage, you define the ideal participant and agree on the recruitment criteria for the tests.

Day two: Ideate

The ideation stage is fun because people unlock their creativity and brainstorm new ideas. I use different brainstorming techniques for ideation, like How Might We's or Crazy 8's. I also include the pain points or needs relevant to the problem statement.

As the researcher, I am the voice of the customer and help bring their perspective into the brainstorming sessions. At this point, start recruitment and scheduling if you haven't already. I always over-recruit just in case we experience last-minute drop-outs. For instance, if we want to speak to five participants, I schedule seven.

Day three: Decide

As above, I am the voice of the customer during this step. Although we generally use dot-voting to help us decide on which idea(s) to move forward with, there are a lot of discussions as well.

During this discussion, I take the role of the potential user and point out different areas that might confuse me or cause more issues. This role-playing exercise is excellent for keeping the user in mind and avoiding just "really cool" ideas.

Day four: Prototype

Once we select an idea for the prototype, I become a thought partner for the designer. I will sit down with them to help create a relevant flow for the original problem.

Alongside being a thought partner, I also confirm schedules for testing the next day. Once the designer finishes the prototype, we review it a few times to test for any glaring issues, and then I get to work on the interview guide. Ideally, I conduct a dry run before the testing day if there is time.

Day five: Test and iterate

Of course, user research is essential in this step, as you do research all day. Ideally, you speak to five participants during the day to get their reactions to the prototype and test for basic usability.

I always recommend doing a quick debrief at the end of the day to identify patterns from the sessions. After this debrief, I assign action items for the next steps if we have to continue to iterate or test with more users.

Try it!

Design sprints are a great way to introduce user research to your team and prove that you can do it quickly and effectively with great results.

Design sprints are also a fun way to innovate and push yourself out of your comfort zone—I know they certainly do that for me! Make sure to align with your team beforehand so the design sprint is the best tool, and that user research is at the core.