Tips for facilitating a successful design sprint

Design Sprints enable you to quickly answer critical business questions through prototypes and user testing in 5 days or less. You can cut out months of unproductive internal debates and work together as a team leveraging this workshop format, as user testing—not internal politics—validates a new business idea. Colleagues experience the additional benefit of working on a cross-functional team, enabling silos to break down, thus significantly speeding up the launch of any new initiative.

In this article, our very own Clare Goldblatt shares tips on how to set up a successful Design Sprint. After all, the work you do to prepare and align with stakeholders beforehand is just as important, if not more important, than facilitating and performing the Sprint itself. And in this article we’ll discuss why.

Wait... What's a Design Sprint again?

I like to say that there are no stupid questions in the workshops and Design Sprints I run, so I am sharing this message with you too, dear reader.

A Design Sprint is a specialized type of workshop created by Jake Knapp from Google Ventures. He grew tired of endless discussion and debate at meetings that led to limited output and came up with this tried-and-tested workshop format for validating ideas.

It’s a Design Thinking-based methodology that allows colleagues to come to a shared understanding of what a problem is, work together to brainstorm and ideate what a solution could be for this shared problem, and then turn this solution into a prototype to be tested on users to examine if it’s a viable idea.

Often, we’re pressured at work to go into solution mode for problems we face immediately. There’s an indisputably proven benefit in taking the time to dissect what the problem is as a team—instead of being forced to generate rushed, half-baked solutions.

The Design Sprint’s schedule tends to look like the image below, whether it’s offline or onsite. Surprisingly, online Design Sprints work well and require just a bit of adjusting—but more on that later.

Above: Design Sprint 2.0 Version. Credit: AJ & Smart

At this point, I’ve facilitated, prepared, and acted as the UX Designer and facilitator for about 50 sprints. While each Design Sprint is unique and involves different stakeholders depending on the challenge, the process of setting up a Design Sprint, whether in-person or online, essentially remains the same.

I believe that the work you do to align with stakeholders before a Design Sprint is just as important, if not more important, than facilitating and performing the Sprint itself.

1. Make sure a design sprint is the correct method you need for your challenge.

Sprints can be fun and exciting, but ultimately, they’re just one tool of an infinite amount to achieve a design or business objective. Sprints are ideal for creating relatively simple new flows that don’t yet exist and revising old ones that aren’t performing, as a general rule.

However, a design sprint cannot accomplish everything and is not a suitable replacement for very complex product development. Also, suppose your organization is resistant to a change. In that case, one Sprint that conveys a new way of working will not stick if management and stakeholders aren’t willing to modify their habits.

2. Make sure you’ll have the data you need.

A well-executed design initiative isn’t operating off of assumptions. Instead, you should rely on insights and data, both qualitative and quantitative, to ensure the design is what people want and need.

Therefore, it’s imperative to work with the topic experts before the sprint to see what kind of reality you can gather from their insights. These experts might be able to provide you with user journeys, share access to analytics dashboards, or help share large-scale survey results. It can also never hurt to conduct a series of qualitative, deep-dive interviews with users in advance to supplement the quantitative data you’ve been provided.

I also recommend conducting the Expert Interviews before the sprint, which is a great way to gather qualitative data from people close to the process. For example, suppose your sprint is related to payment. In that case, it can be highly advantageous to schedule an expert interview with someone from Customer Service who’s familiar with the complaints and inquiries customers submit.

3. Earn Stakeholder buy-in and offer clarification

As with any project, it’s essential that you identify your stakeholders and understand who fits where and how within the organization.

Sometimes before conducting a sprint, I'll create a quick stakeholder map, which acts as a nice visual on who to contact and anticipate what needs they might have.

Here’s a visual of one we sometimes use below:

Once I have an idea of who these stakeholders are, I inform them what exactly to expect as an outcome of the sprint—which is as follows:

• A working prototype: not pixel-perfect, but conveying a new user flow and key interactions. Based on the customer feedback, the team needs to determine what changes will need to be made to the prototype and if there is enough potential and a business case to turn it into an MVP.
• A new product and/or business direction: Effective sprints leverage the knowledge learned from the intense collaboration and take a product or initiative into a new direction, presumably to reach a specific objective. An example could be refining a payment process flow to be clearer and easier for users to navigate.
• Insights from at least 5x Customer Interviews: To validate the new user flow conveyed in the prototype as a result of the sprint, it’s essential to always test your prototype on your target users. This offers the added benefit of bringing fellow colleagues along for the process of User Research, which not only engages them but also serves as a reminder that the processes and operations they work with directly affect people.
• A thorough report out: A comprehensive report out serves to share what’s been done, by whom, and what the next steps are. Plus, it’s nice to share the successes and milestones of colleagues.
  
  You might find that some of your stakeholders are not convinced about using a Design Sprint as a tool to solve their problems. This is normal, and it’s worth finding out why. You might need to refine the Sprint’s scope to ensure they feel comfortable moving forward with the Sprint. In my experience, some people have only been convinced of a Sprint’s effectiveness after the fact, but if you can sway your stakeholders in advance, the more smoothly your Sprint will likely go.

4. Getting the right people in the room/online space together, the whole time

Design Sprints simply don’t work if colleagues don’t commit themselves fully to the process. Colleagues need to block their calendars for the majority of the week, ensuring that they’re focused and dedicated to coming up with a shared solution that solves their problem. This may seem understandably frustrating, but done well, a Design Sprint might actually bypass months of unnecessary work in the condensed time span of approximately one week.

Also, because I work in many different regions with different languages, I always ask for translation assistance for the prototype in advance. Some people might fail to understand that it’s not simply a matter of copying and pasting content from English into the local language, but altering the words impacts visual design elements, significantly affecting spacing and alignment.

Working alongside colleagues who speak the local language and are willing to help create a prototype in their language has the added benefit of involving them directly in the design process.

5. Define Roles in Advance

Once you know who will be there and the stakeholders have given their green light, you'll need to define a few roles in the sprint. Align on who will be your facilitator(s) (we recommend 2), the UX Designer in charge of building the prototype, the decider, and the participants. You'll also need to think about who will be responsible for user testing.

In my experience, it's better to have one person serve as the primary facilitator, and this person should not be the same as the UX Designer. The facilitator needs to maintain neutrality throughout, whereas the UX Designer might need to challenge the group's ideas if they're focusing exclusively on the needs of the business, losing sight of possible tech or design constraints. It's also far too much pressure to have one person be the only facilitator and UX Designer. Still, facilitation can be done smoothly with one primary facilitator and a UX Designer helping out. Furthermore, it can be pretty exhausting to facilitate in a Sprint setting for days at a time, so having it split between 2 people is very helpful for everyone's energy levels.

Additionally, you'll need to have a maximum of 7 colleagues close to the process as participants, and one of them should be a decider. This person is in charge of making decisions and ideally has the influence to push the organization's initiative forward. These seven people should be from various departments, including marketing, customer service, sales, or other operational units, as long as they're very close to the realities of the initiative you'll be working on. Having more than 7 participants slows down the sprint significantly and leads to the "too many cooks in the kitchen" phenomenon.

6. Get to know the processes, people, and journey(s) in advance—as much as possible

The more prep you do before a sprint, again, the better. Even if you're a complete novice to the Sprint subject, ask as many questions and document as much information as you can to prepare. It might be stressful to make the user journey as a team during the Sprint if it's the first time you've seen this user journey--especially if it's a complex journey. Ideally, you can show an up-to-date version of the user journey during the Sprint (as-is version), revise it as a group (should-be version), and use this as the foundation for your user test flow and eventual prototype.

Also, if possible, set up a call or meeting to meet people in person or remotely to get to know each other a bit. Remote meetups before a Sprint have been highly effective for remote workshops, where it can feel harder to get to know each other. Getting to know participants in advance not only allows them to feel more comfortable with you before the Sprint happens, but you can also discover their expectations and manage them, if necessary. Finally, the more comfortable the participants are with you and the set-up, the more likely the whole operation will run smoothly.

7. Conduct some basic best practice research to get better prepared

It’s always nice to get some external inspiration from the design community. While you might not—and probably shouldn’t—already have a solution in mind for your Design Challenge, based on the journey you’ll be working on, you can look to external inspiration on how other companies and products work to solve this solution. You can even share your examples during the Lightning Demo section of the sprint.

Conclusion

Setting up successful Sprints requires thought, preparation and strategy. In fact, the more prep, the better. So let’s recap:

• Design Sprints are just one of many tools used to achieve a design or business objective. Make sure it fits yours.
• A well-executed Design Sprint operates off of both quantitative and qualitative insights and data, not assumptions.
• In order to earn stakeholder buy-in early on, much like any project, it is important to identify your stakeholders and their roles. Then, set clear expectations.
• It is imperative that colleagues commit themselves fully to the process. This means blocked calendars for most of the Sprint week.
• Define roles in advance. You’ll need 2 facilitators, the UX Designer in charge of building the prototype, the decider, and the participants.
• Come to the Sprint with an “as-is version”of the user journey and revise it as a group (should-be version). This should be used as the foundation for your user test flow and eventual prototype.

Now you’re all set. Stay tuned for part 2 of this article to learn all about hosting and facilitating Design Sprints!