Here at Rocket we are big practitioners of the Google Design Sprint, the five day process whereby you test product/business ideas to see if they are worth pursuing. We use them to test everything from early product concepts to options for a large new feature. Here are a few things we’ve learned about how to run them more effectively.
Know when to run them. Even though design sprints are conducted quickly (in a single week) they are substantial projects that involve your entire team and stakeholders. While not a big time commitment, knowing when to run design sprints can save you the pain of spinning one up in circumstances where they are inappropriate.
For example, one of our clients was recently told by an advisor to run a design sprint to create a new MVP of their flagship app. The idea was that they would use the design sprint as a way to kick off the redesign of the software. After talking with the client, however, we realized that they actually already knew what to build: they knew what was (and wasn't) working in their current app. The problem wasn't figuring out what to build, the problem was that they just didn't have the skills in-house to execute on it. Instead of a design sprint, our client just needed design time...they just needed a senior designer who could redesign the app. Recognizing differences between situations like this is critical to using design sprints effectively.
Set expectations early and often. People have no idea what to expect when they participate in a design sprint for the first time, even if they have read through the Sprint site. They have all sorts of ideas and questions about what it might be like. What happens on each day? Am I going to have to sketch in front of other people? I'm not a designer so why should I attend? Etc.
Head off all of these questions by setting expectations early and often. Be attentive to people’s questions and concerns and set the right expectations at every turn. Send an overview email the week before you start. Create a list of participants and their roles. Let people know that this is a messy process and their expertise is valuable even if they’ve never designed anything. Setting these expectations builds trust in the process and lets people more freely express themselves during the week.
Don’t rush Day 1. It’s easy to rush Day 1. It’s easy to jump into a few high level discussions about market and competitors and personas and figure that you know everything there is to know. It’s easy to wrap Day 1 around 3:00pm. But I’ve found in practice that most teams do not go deep enough on day 1…they often just think out loud, make some lists, and look forward to actually designing.
I have found the most productive sprints happen when teams do not rush Day 1. They tend to pull in experts from other parts of the company (or even outside the company) who spend most of their time thinking about the market and their users. They try to learn something new themselves. In practice Support and/or Sales people are often good candidates to pull in when you need to know more about current or prospective people in the market. Taking time on Day 1 is almost always beneficial.
Relentlessly adhere to sprint questions. On Day 1 teams set the questions they want to answer during the week. In our experience when sprints go well, the team constantly refers to these sprint questions during the week and makes sure that they stay focused on them. When sprints go poorly, teams veer away from their sprints questions and don't end up using their time wisely.
It's easy to think you'll have the discipline to stay on top of your sprint questions. But in practice teams quickly fall into long discussions about tangential topics or product minutiae. It takes a lot of discipline to keep every conversation focused on the questions you want to answer during the week.
Choose a strong facilitator. Part of the Design Sprint methodology is to nominate a sprint facilitator to keep the team on track. Being the facilitator isn't glamorous, in fact it's relatively hard work. You have to ensure the team stays focused on the problem at hand and direct them when they get of track. A good facilitator needs to be able to change the direction of the team at any time.
Why? Because teams get off track A LOT. For example, when a team is practicing group-think the facilitator needs first notice it is happening and then needs to step in and say "It sounds like we're all in agreement. Shall we move on? Or are there counter-points?". Without this course correction teams will lose speed and speed is of the essence during sprints! If the facilitator is too nice or can't focus the group when necessary then things will get off track quickly.
Always be capturing. One of the earliest sprints I participated in was with the Google Ventures Design team, who created the sprint process. One good habit we learned from them was writing down everything as you go along, what we ended up calling always be capturing.
This is important for more than just completeness. When you capture everything you become much more cognizant of when the team is wasting time and repeating themselves. Cultivating the habit of capturing makes it easy to say "Let's capture this and move on", which keeps the team moving forward.
Don't run "abbreviated" design sprints. I cannot tell you how many people I have talked to who say something like “I love design sprints…we just ran an abbreviated one at our company”. This usually means that they did not do Day 5 (usability testing) or possibly even Day 4 (prototype building). This is a shame…those two days are where the real magic of the design sprint lies.
When you skip usability testing you avoid the most powerful forcing function of all…real world feedback from people outside of your office. The entire point of the sprint is to learn something new, and if you stop the sprint after Wednesday then what you probably just needed is straight-up design work. (see point #1). Naturally there are exceptions to every rule, but try not to schedule a design sprint unless you actually have five days to see it all the way through.
There you have it, seven tips to running better design sprints. These have come from our experience running them with many clients over the last two+ years. If you have any design sprint tips of your own, let us know!
Thinking about running a Design Sprint? Start by reading through the core literature. If you have questions or want help running a sprint, we've got a lot of experience and are happy to help. Get in touch.