Design Sprint 101: How to Solve Problems and Test Ideas in 5 Days
In recent years, we’ve seen the rapid growth of empirical-based agile methods in software development process. On the other hand, fans of Lean Startup methodology use the build-measure-learn loop and try to constantly listen what their customers say about their product. The next emerging topic is the design sprint. A brilliant concept or just another buzzword? Let’s find out.
Basically, the design sprint is a 5-day framework for the process of validating your ideas quickly and cost-effectively. It was introduced by GV (formerly known as a Google Ventures) and developed to help companies make the decision-making process shorter. The authors of the concept used it with a lot of businesses (i.e. Nest, Flatiron Health, Medium) to create better products. But how exactly does it work for us?
How to use a design sprint
At 10Clouds we do not work for clients – we work with clients to build great digital products. To do that we need to understand the whole concept quickly and communicate about it with our partners clearly and frequently. What helps a lot in achieving that are product workshops.
Last year, we started using design sprints during the workshops with some clients. It was thought out as one of the techniques that would help us achieve a better understanding of important product goals.
The complete sprint cycle takes five working days and lets the team go through the process of problem-idea-learning without the need for building the whole solution. The team just validates a hypothesis so that they know whether the concept at hand meets the business goals and provides value for end customers.
The most important thing is to choose the right hypothesis to validate. And this happens on day 1. This day helps us understand the product issues by sharing knowledge, discussing problems, and choosing a target for the week’s efforts.
Sprint is a perfect fit to conduct it both on starting as well as ongoing projects. During this day, the client shares all the information about our target users and their needs, competition, market conditions, and business goals. We don’t delve directly into countless ideas without a solid understanding of what the biggest strategic or tactical issues are that we need to solve next week. Is it the low retention rate? Or maybe people are lost within one of the scenarios? The first day’s purpose is understanding the problem.
The most important thing is to choose the right hypothesis to validate.
The next three days are mostly about the solution itself. There is a lot of sketching, making notes and discussing which of the solutions could be best for our defined hypothesis.
What we always learn about this part, again and again, is that we are all designers – everyone in the team can come up with an excellent idea. Lateral thinking not a domain-internal capability of the so-called creative minds. We work together to find the best possible solution to the problem and the sprint works because people want to take part. The real value of a Design Sprint is that this framework is all about teamwork.
The other thing is a Design Sprint is a very democratic process. Everyone has an opportunity to say whether they liked and didn’t like the particular idea. We gather solutions that could be the best fit and let everyone vote for their personal favorites after a short explanation.
This also incorporates a critical, but too often underestimated, aspect of a design critique. I have personally seen too many times how hard it is for many companies to establish a culture of healthy feedback. But because within Sprint every prototype is tied to our business goals, this framework forces everyone to be very candid and specific. We never talk about ‘likes’ and ‘dislikes’ but about meeting our goals defined during day 1 and affirming what’s working about each idea.
In the beginning, we were a little bit afraid that maybe there wouldn’t be so many designs, and we would have not much to discuss, but we found out very early that during a Sprint, the team can generate a lot of good concepts within a short span of time.
During a Sprint, we have a chance not only to learn how to solve the problem, but we can also get to know each other a little bit better – both within the team and with the client. Did you know that one of your developers is learning about machine learning after hours? Or maybe one of your marketing guys is really into sports and has information that could actually be crucial for solving this problem?
During a Design Sprint the team can generate a lot of great ideas in a short span of time.
The last day of Design Sprint allows you to validate whether the idea you chose to test solves the problem your team defined during the first day of the sprint. We do that by showing our prototype to other people. Alternatively, if target users are not available, we just validate it with the client.
This is a really valuable day, because it can, for instance, happen that the initial idea client came up with doesn’t really solve the problem. Or it turns out that the solution that the team figured out is not that good, which is also a really valuable lesson for us. The team learns quickly what works and what doesn’t in a presented prototype without spending money on weeks of development.
Is a Design Sprint worth it?
If you work for a startup, or software development company working for startups, you know that this environment changes quickly and unpredictably. At 10Clouds we keep in mind what Eric Ries, the creator of the lean startup concept, said about winning in this context:
The only way to win is to learn faster than anyone else.
Taking that into account, we believe that incorporating design sprints into your product development routine will be a big step towards building better solutions. Design sprints are a really valuable tool – they successfully combine various techniques coming from the fields of user research, customer development, agile, and lean startup. It is also a great tool to get to know your teammates and clients a little bit better. All in five days.