June 9, 2022
June 9, 2022
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.
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.
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.
Nikki Anderson-Stanier
Founder of User Research Academy
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?
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.
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.
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.
"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!
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.
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.
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?
As I mentioned, there are five steps within a design sprint:
Here is how I incorporate user research into each of these stages:
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.
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.
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.
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.
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.
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.
Nikki Anderson-Stanier is the founder of User Research Academy and a qualitative researcher with 9 years in the field. She loves solving human problems and petting all the dogs.
To get even more UXR nuggets, check out her user research membership, follow her on LinkedIn, or subscribe to her Substack.