Can you make a new flavour of candy with a Google Design Sprint?
Last week, when leading a short training session on the Google Design Sprint, I was faced with questions often asked in relation to the Sprints. So I figured that it would be helpful to write out my answers: may they be helpful to anyone considering using the Design Sprint method.
Question 1: Are there problems that a Google Design Sprint can’t solve?
The question was posed because Design Sprints can be used for a wide array of fields, not just the digital user experience I focus on. A Design Sprint is a problem solving method that has been effectively used in addition to websites and mobile apps to create everything from new chocolate flavours to running shoe designs and even Mercedes Benz cabin scent. However, it is not a magic wand that will solve all your challenges.
Speaking from personal experience, if you find yourself doubting whether a Design Sprint is the right method to solve your challenges, ask yourself the following questions. What will happen if I fail to solve the problem today? How will it affect my business? What costs will an unfinished project or a delayed product bring with itself? How will it affect your client experience and sales results? A Design Sprint is useful for projects that have an important impact on your business.
In addition, the Sprint will help your team to move forward quicker. Sometimes, a Sprint may be necessary if your project or development has reached a standstill and you feel like you have already tried everything else under the sun to get it going again. A Sprint will be a useful tool if your challenge incorporates people from the different units of an organisation. After all, its magic is letting people who would otherwise not connect professionally work together to solve a problem. A good Sprint strengthens a team, so it is also a good method for a project that is just starting out.
Question2: How do I motivate my team to take part of a Sprint?
I recommend getting the decision makers and leaders on board first. They will make it much easier to sell the Sprint to other people in the company. I have used a “Lightning Decision Jam” workshop for this purpose, getting the leaders together to solve a real problem, in order to introduce the Design Sprint tool in the process. When selling the Sprint to your superiors, mentioning the successful companies that already use it will benefit your cause, even more so if you can name someone from your sector or competition who has benefited from a Sprint.
Participants worry most about time. They don’t have time for a sprint. This can usually be argued against by saying that the premise of a Design Sprint is to save time. To save your time. I recommend showing the time and resources already spent on the project by working on it in the “traditional” way. Contrasting it with all the progress that is planned to be completed in only four days. This helps shift the perspective in your favour.
Another common worry people have is that they will be forced out of their comfort zone for four days. This can be challenging, especially to the more introverted team members. The solution to this problem is an experienced Sprint organiser who will be able to guide the participants in a way that allows everyone to share their ideas.
It is also completely normal for people to start doubting the necessity of the Sprint or the process itself while in it. The process is intensive, and the best remedy to this doubt is to encourage the team to keep moving forward, towards the light at the end of the tunnel.
Q3: How often can Design Sprints be used?
This question has no single answer. For participants, I recommend taking at least a month’s break before diving into a new Sprint. It is important to understand why the Sprint is necessary. What was the outcome of the last Sprint? Was the result lacking or was it something about the process that didn’t work for you? It is a good idea to have a retrospective meeting a week after the Sprint in order to discuss its results and future. A new Sprint is rarely needed, and instead the resources should be allocated to prototyping and further end-user testing.
If your last Sprint flopped, you may find it difficult to motivate your team. But we must keep in mind that the Sprint is only the beginning. Finding out that your prototype is not feasible in its current form is a positive rather than a negative if this revelation happens during a Sprint. After all, you came to this conclusion in only four days, without wasting months of money and time on a faulty prototype.
You can read more Design Sprint case studies by clicking here.