When to use a Design Sprint

Some time ago, I wrote a post about how I predicted the future using the Google Design Sprint. After which several people asked me if and when a Sprint could be used and wether it fit their company.

Although the Google Design Sprint began in software development and was built to help projects and development move forward quickly, today, the Sprint is used to work on all kinds of different topics concerning innovation. This may make it seem as if the design sprint is a magic wand that has a solution for every problem.

I will now share a few questions that, in my experience, will help you understand whether a Google Design Sprint can be useful for your company today.

A Design Sprint is best used in situations where time is limited and stakes are high.

Is the problem you’re looking to solve important enough?

What will happen if you fail to solve this problem? How will a failed solution impact your business? What effect does this have on your results and your brand? It’s clear that there is no reason to lock yourself and your key team away in a room for five days to solve a problem that does not greatly impact your business. In addition to the impact of the problem, it is important that the problem be clearly worded. It’s difficult to solve problems that are vaguely worded.

Preparatory work is important here. The Sprint organiser must collect the necessary information from the team and the clients to word the problem as precisely as possible on day one. An example of a clear problem with a large business impact: How do I convince clients to switch to e-channels from physical locations? How do I create a simple and user friendly self-service for my existing service? Should I have a uniform client management tool for all my regions?

Kas sul on täna juba silme ees selge lahendus või idee?

If you already have a clear solution or idea in mind, it might be best not to waste your time on a Sprint. Sprints are best used in situations where the are no concrete solutions to a given problem, or situations where there are many solutions that you wish to quickly test before committing. If you have a clear solution in mind, you might benefit more from creating a prototype and testing it on end-users, instead of starting from scratch.

Does your problem include different parties?

Does your problem include different parties? Is your challenge a problem faces by only one unit or does it include different parties and entities One of Design Sprint’s benefits is that it helps connects different parties and entities that would otherwise never work together. The Sprint is not a magic wand, but it often helps overcome standstills that have been created through entity co-operations, as the parties are forced to reach a solution in a limited time frame. A good team size for a sprint is considered 7-8 people, including the organiser. Not everyone has to be there every day, but a core of 4-5 people should constantly remain working on the Sprint. It’s important that different parties who interact with the solutions be present, starting from product owner, decision makers, customer support, sales and IT and ending with clients.

Now, an example from the fourth day of a recent Design Sprint, where we were creating a prototype.

I have also been asked if we can Sprint in 20 hours instead of 36 by leaving out prototype creation and testing. It is possible but then no longer a Design Sprint. All the elements of a five-day Design Sprint (understanding the problem, generating solutions, picking the best solution, prototyping, testing) can be done separately - for example weekly - but then it is no longer a Design Sprint. It becomes a very focused workshop. The main idea of the Sprint is to be quick and finish in 36 hours what would usually take months.

It is also important to understand that the Design Sprint is not the end, but the beginning. The Design Sprint does not culminate in a ready-for-use product. Rather, it is a week meant for testing different solutions on end-users, which will allow the team to quickly move on with their development. Sometimes, the end result can be the need for further development. The Sprints can conclude with the knowledge that it is pointless to spend more money and time on the product in its present form. Which is also a good result if this conclusion can be reached in five days, rather than five months.

You can read more Design Sprint case studies by clicking here.