The right opportunity for a Design Sprint

A few thoughts and insights about when is the right time to run a Design Sprint process.

Making decisions -Photo by Yaron Ben Adiva

Many of you must have heard about GV’s Design Sprint as there’s a huge hype around it. As most other hypes, we are starting to get loads of opinions. Some of them are supporting and encouraging us to use the methodology and some of them are more critical of it, mainly by claiming that it’s too “vague” or “a time waster”.

I recently read two popular posts — “Design Sprints Are Snake Oil” by Erika Hall claiming that “The moral of this story is that many methods start out as legitimate tools to promote better, clearer thinking faster and end up as activities substituted for thinking (and in the case of the design sprint, shorthand for “you can do anything in a week”),” and another post “User Research is Overrated” by Jonathan Courtney saying that “The Design Sprint process exposed that our own design process was mostly filler!” The first one refers to the Sprint as a UX research replacement in a non-supportive way and the second one claims that a UX research process is redundant and the Sprint could replace it.

I think that both of them are right (but not in a diplomatic way). I believe that when it comes to problem solving, we as professionals need to open our toolkits and decide which one of our tools has the highest potential of helping us to solve a particular problem in the most efficient way. Deciding which is the right tool is a major part of our job and IMHO it’s what defines us as experienced professionals.

The Sprint methodology should be considered as a qualitative form of agile UX research combined with ideation process. It doesn’t mean that we don’t need to take the quantitative research methods into consideration or we shouldn’t conduct a significant UX research and run a Sprint instead. In fact, at the beginning of the Sprint, you should brief your group about previous quantitative and qualitative researches you recently did during the “Understand” stage, so everyone will be aligned with the results. As with any other UX process, the decisions we make should be educated ones and based on solid facts and validations, not only assumptions.

HMW’s - Photo by Yaron Ben Adiva

When to use the Design Sprint

There are pros and cons of using one methodology on top of another, so the answer for “when is the right time for me to run a Sprint?” — like many other answers to UX questions (and overall in life…) — It depends. So, what is the right opportunity for a Sprint? From my experience, there are a few of them:

1. When you have a big challenge, but not too big

When running a Sprint, the challenge should be neither too narrow nor too broad. You shouldn’t run a Sprint to determine where to put a button or to solve the world’s climate change (you still have only one week). However, it’s very important that your challenge will be well defined. Not too specific, but rather a generalization; in case there’s a challenge of figuring out how people will interact with a product and study their behavior (like Savioke’s build their robot personality), or in case you are working on a new feature and you want to check the value that it gives to your users, or in case you want to increase the usage of an existing functionality — that’s where you should put up a Sprint together.

2. When you have limited resources

When the deadline is just around the corner or the budget is too low, it’s better to conduct a 3–5 days Sprint rather than not conducting any process at all. The Sprint might even save you huge resources instead of just solving a problem technically, developing it, and praying for it to work. It doesn’t mean that you won’t need to conduct any research — the Sprint will help you to organize things and put them in front of you so you can get a better perspective and make better decisions.

3. When you have a strong conflict

I guess that most of us had to deal with too many opinions or conflicts that were hard to settle within your team or with a client of yours. When dealing with such conflicts the Sprint stages could be used as tie-breaker by exposing the conflict to the entire group from multiple angles, generating new solutions, and make decisions together as a team using the Zen dot voting and open discussions. By the time you have validated your decisions with the users and confront them with your stakeholders — the conflicts should be settled. Not good enough? iterate based on the results you have received from the Sprint.

4. When there’s a lack of creativity

The Sprints uses mixed ideas generating techniques (from Stanford d-school and IDEO). For example, one method — “the crazy 8 in 5” pushes you to find 8 quick solutions in 5 minutes. So at the beginning of this exercise you’ll go for the “obvious” ones or the ones you already thought about, and then the interesting and “crazy” ideas will start floating. From my experience, most of the people are generating no more than 4–6 solutions, but this exercise helps them to think outside of the box and build new ideas afterwards on top of those of their teammates.

5. When you want to engage your team

Your work routine might not be productive enough, especially at the beginning of a project. When you need to empower your team, get a better team effort or initiate a new project with a client, the Sprint will help you to gather all the people involved, break the ice and start building up a trust for a better working environment.

The Crazy 8's in 5 - Photo by Yaron Ben Adiva

We are the creative ones

Be open minded; if we as curious designers won’t do that, we can’t ask for others to do so — we are the creative ones :). So, don’t misjudge or underestimate one method over another unless you try it; you’ll never know what kind of value it will bring you in the future, even if it’s a minor one. Always strive to learn more methods and acquire new tools for your professional toolkit both technical and theoretical ones. When there’s a doubt, don’t be afraid of trying a new method — the worst case; you’ll fail and learn from the process. Right?

Related Links