If you’re a UX researcher, designer, or product manager, you’ve probably heard of the design sprint. It’s a popular method that promises to apply the magic of design thinking to products and features quicker than the speed of light. Sprinting may seem a bit intimidating at first. Especially for us UX researchers out there (we naturally like our deep thinking and analysis). But if your business needs to move quickly, it’s worth giving it a go.
Before we get into how to run research in design sprints, let’s make sure we’re all talking about the same thing.
So what is a design sprint anyway?
A few years ago, Google Ventures (or GV, as it’s now known) was in desperate need of validating design ideas quickly to help their portfolio of 150+ startups grow and scale. They knew that some of the best and most successful Google products, such as priority inbox, were designed during times when there was a hard deadline. An idea sparked – could they use time constraints to help the teams work more efficiently? And so the design sprint was born. GV calls it a ‘“greatest hits” of business strategy, innovation, behavioural science, design thinking, and more.
So how does it work? After some experimentation, the GV team landed on a method where a team of five to eight people would take a product design from concept to research in just five days. (And, as far as I can tell, GV is still sprinting away.)
The makeup of the team and the structure of the days are key. Sprints need at least one designer, one product manager, and one user expert (normally a researcher) to work effectively. The five days follow a strict schedule so that the team can stay on track and have their design properly evaluated by the end of the sprint.
The classic GV design sprint
In the classic GV design sprint, each day takes on a theme. After some initial preparation, on the first day, the team focuses on understanding the design problem. This may mean delving into transactional data, looking at what competitors are doing, and reviewing any existing research. The theme of the second day is diverging – coming up with as many competing ideas as possible to solve the problem. The third day is a decision point where the team chooses the most promising idea and fleshes out the concept in more detail as a user story. Day four is all about prototyping and expressing that idea in a way that can make sense to possible users. And finally, on day five, the focus is on validating the design solution by showing it to real users.
Integrating UX research into a fast-paced environment
Unsurprisingly, when word got out about GV’s design sprints, other companies decided to give it a go. Today, sprinting is a very common practice within UX and product organisations all over the world. But how do you effectively work within the constraints of design sprints when you’re a UX researcher? We’re trained to take our time, to listen, and to avoid making quick assumptions.
Step one: get in the right mindset
First, start by shifting your perceptions. Design sprints aren’t the opposite of what you’ve been trained to do. Instead, think of them as a compressed way of getting to insight and decisions quicker.
Step two: get in the right rhythm
Then, find the right cadence. Sprinting is more philosophy than dogma. After all, not every organisation can get the right people in the room for five days in a row. However, those key stages of the sprint – understand, diverge, decide, prototype, and validate – can happen over a flexible timeline that works for you and your team.
If you can’t move fast enough in a five-day working week, I suggest shifting your sprint timelines so that more days are allocated to each stage. Test and learn to find what works best for you. But don’t let your sprints get too bloated. You need to be able to get into the rhythm and keep going.
Step three: get bums on seats
One of the best things about being a researcher on a sprint is that the final day is all about getting everyone involved in the research. It’s a bit like being part of a theatrical production – you’ve nailed the dress rehearsal, but now it’s opening night. It’s key that your team members feel like part of the ‘validate’ stage. So make sure you invite them to participate in any usability or concept-testing session. If you can’t get them on the ‘other side of the glass’ or viewing your remote sessions, invite the rest of the team to make notes and give feedback on a highlight reel of the user research.
Remember to own the findings as a group. You know how sometimes research feels like a box-ticking exercise that needs to be tolerated before products go live? It’s not like that at all in a design sprint. The classic GV method involves everyone getting down with the Post-Its and sticky notes to consolidate findings together. You can be the facilitator here. But you don’t have to do all the heavy lifting on your own. Design sprints get you away from having to pump out yet another ‘research findings deck’ that disappears into a shared drive to die alone. Instead, embrace the teamwork and document sprint findings together. Whether that’s on a wall covered with Post-Its or in a group Trello board.
It’s a sprint, not a marathon
As the research lead within a sprint team, it’s also important to keep focused on the next sprint on the horizon. Try to schedule your research sessions before you even start your sprint. This tip comes straight from GV. They realised that sprinting works best when you are not spending your key days trying to deal with a mountain of research ops such as booking in research participants or deciding whether to run in-person or remote sessions. And if the ops are slowing you down, ask for help from the rest of the team.
And remember, it’s a sprint, not a marathon. Sprinting isn’t necessarily suited to designing completely new products or behaviours. No matter how tightly your team operates, you are unlikely to discover the next big thing via a design sprint. Keep your discovery research on a separate track until the concepts are really solid enough to make it through a sprint. If you only have one day of research per sprint, it’s got to be based around a product design that can properly be put through its paces. One where you can actually make those go/no-go decisions after only one day of validation.
Research is at the very core
Researchers don’t need to be afraid of design sprints. They’re a great way to test and learn your way to better product and feature design. All you need is the right team, cadence, and challenge. Plus, research is at the very core of a sprint: you don’t learn anything without user feedback.
Personally, I’ve run research on nearly 10 design sprints now. And though I was sceptical at the beginning, I now really love the sprint method. It’s creative and fun! There’s a great feeling of community, and you get pushed out of your comfort zone as everyone participates throughout the sprint. Also, I’ve gone from having one or two people behind the glass of the usability lab for my research sessions to a full house of teammates who really engage with what our participants are thinking and feeling – a researcher’s dream!
If you want to find out more about design sprints, check out GV’s online sprint resources or pick up Jake Knapp’s Sprint book. Zhenshuo Fang at Google also has some good tips on how to facilitate design sprints.
