The traditional design sprint doesn’t work for all teams for all problems. As a former Google UX researcher, I worked with several variations of the 5-day sprint. The effectiveness of a design sprint depends on many factors, such as the complexity of the project, stakeholder availability, and how difficult the user research participants would be to involve.
This article shares several ways we adapted the 5-day sprint model based on team project goals and timelines. I’ll share insights on how to modify away from the textbook sprint model. Before we get started, if you’re wondering what a design sprint is, head over to this design sprint primer before reading more on how to adapt it for your team.
5-Day Sprint
Good for: Well-understood and defined problems, teams co-located and with calendars cleared.
The 5-day design sprint is the right place to start. It’s most effective when you have a well-defined problem and know a lot about the audience you are solving the problem for. Your whole team needs to be available and unplugged from other distractions. The sprint participants also need to be committed to sharing their time and ideas toward creating the best solution. Often having team members on equal footing allows all ideas to be heard equally and for trust to be established more rapidly.
Within a 5-day sprint model, there are often modifications made to when and how the user research is done. We’d often move the research to the week prior or after the designated design sprint week. This allowed for more flexibility when participants inevitably canceled or if more user types were uncovered during the design sprint week. When moving the research outside of the 5-day sprint week, make sure to share the results in a live format that allows for discussion and brainstorming. Emailing a report won’t cut it, since people tend to skim instead of absorb the data.
Iterative Sprints
Good for: Difficult or complex problems and solutions, problems with diverse audience needs
My personal favorite variation is the continuous or iterative sprints. While I was at Google, I played with multiple formats of this sprint across several teams. In some ways it’s a fusion of agile and design sprint methodology. It allows teams to tackle challenging problems, which often require multiple attempts and angles to truly understand and solve them.
Another benefit of this longer form sprint is that it provides the opportunity for research with multiple audiences. Often times, a more complex product will have multiple user types that will have different goals, use cases, and requirements for the product. By spreading out a design sprint over multiple weeks or months, your team can be allowed more space to thoroughly explore each of these user types and their needs.
On one team, we scheduled a weekly ongoing sprint. We scheduled 5 participants each Wednesday, for 8–12 weeks in a row. From Thursday to Tuesday, we’d rapidly build up a new idea, to then tear down and refine it with new participants the following Wednesday. We moved in leaps and bounds by forcing regular research sessions. We could also potentially scrap the entire design approach if new insights drove us to a stronger solution. Over the 8–12 weeks, we found a consistent direction and ultimately developed a deeper understanding of the problem we were solving.
A second team that I was the researcher on at Google used the iterative sprint model in a different way. In a single week, we’d run through several iterations of design and research. This team was limited in researcher capacity, so it was essential to get the most out of the time available. We would run 2–3 research sessions each morning and then spend the afternoon tweaking and iterating based on those sessions. By the end of the week, we really understood how our solution would work or not work for different types of companies and different types of users. The other components of a traditional design sprint would occur in several meetings ahead of this design and research intense week.
Short Form Sprints
Good for: Companies with “meeting” cultures, building consensus with a wide range of stakeholders.
One of the most common formats I encounter are short form sprints. In practice, it’s very difficult to get all the stakeholders in a room at the same time. It’s even more challenging to get them to stay in the room, focused, for 5 days. Companies with meeting-centered cultures make it hard for full teams to block off their calendars without interruption.
However, if the design team runs off to do a design sprint in isolation, their solutions are likely to be discounted by other teams. One of the best benefits of using a design sprint framework is to build consensus among a broad set of teams, across engineering, product management, and sales. Teams are more bought into a solution when they were part of the ideation.
By trimming down the 5-day sprint to a workshop format, you can still get many of the same consensus-building benefits. Typically I find that 2–4 hours is optimal for this highly condensed version of a sprint.
Before the session, data is collected through discovery research and synthesized for the team. The workshop begins with reviewing the known data about the problem. I find that people get excited when the meeting begins with data and insights, then quickly moves into opportunities for them to contribute their ideas. The final solution should be open-ended, so that the design team will have the flexibility to evolve the solution as they delve into understanding the nuances of how to solve it.
Using the short form sprint, you allow the team to participate in design thinking and to feel a part of the ultimate solution. When people are part of the brain storm, they are more likely to take ownership and pride in the final solution, even if they’re not part of every single detail.
How would these different models work for you team? Have you tried the 5-day sprint? What adaptations have you made? We hope this guide inspires new approaches for making design sprints work best for you and your team.
