Author: Predrag Rajković
You want more customers, the next cool feature, a service tailored to your customers? The Design Sprint can help you address those challenges. Find out what it is, what you need to run it and who can help you do it.
When it comes to product design, one can hear challenges product teams meet: ”My team is stuck in the process and needs help to proceed with feature productization.”, “We are too slow coming from idea to ready-for-development phase.”, “We have a challenge in making the decisions regarding product design. We keep discussing, but reaching the decision is almost impossible!”.
These are just a few examples product teams and product managers meet while managing their products.
A framework, or a collection of applied techniques called The Design Sprint can be used to overcome those predicaments.
The Design Sprint originates from Google Ventures, and has been developed from their work and understanding of start-ups, to help them pass the journey from idea to concrete product validated by end users[1]. As defined in the book that explains it, the Design Sprint[2] is a framework used by teams of different sizes to solve and test design challenges in 2-5 days.
Put like this it might sound very broad and doesn’t provide understanding when, how or why it should be used.
Let’s try to answer these basic questions.
What is the Design Sprint?
As indicated above, the Design Sprint is a framework, or a collection of techniques that can help teams in solving business critical issues. It is most often connected to product teams solving product design problems, but it can be successfully used for creating services, marketing campaigns, even processes.
This framework helps teams take the journey from problem definition, setting the long-term goal, ideation, proposing possible solution, its prototyping and finally testing the solution with end users in 2-5 days.
This means that once you face the business challenge, you need to engage your team of 5-7 persons for 5 days to come to a validated solution of the problem.
Sounds great, almost too good to be true, that in just 5 days you can see the possible solution of the most important challenge your company meets today.
But, let’s look at the second question, when does it make sense to use the Design Sprint.
When can it be used?
First of all you need to have a serious challenge in front of you. You won’t engage your team for 5 full consecutive days just to solve whether your call to action button should be positioned slightly left or slightly right. You want to engage people around something significant, something that may impact your business or that requires potential significant investments and something that is surrounded with certain uncertainty. In other words, you’ll want to run the Design Sprint when:
- Your company has to make a decision that will cause significant investments in the future
- You are creating new product
- You want to improve important part of your existing product
- You want to get alignment in the company around something where company is stuck
- You have an idea that you want to pitch to your management
Who is using it?
Although the framework started from working with start-ups it has been adopted by a great number of big companies from different industries. Let’s name a few: Google, Lego, United Nations, Deutsche Telekom, Ikea, H&M, KLM, The New York Times…
It is interesting to mention that McKinsey are offering this framework in a set of their services, but under the name of Concept Sprint.
Does this make sense? Give us a call and schedule a chat with our coach, a certified Design Sprint facilitator to get more details.
What does the process look like?
Before starting running the Design Sprint you have to prepare yourself and the sprint. What you need is:
- Proper and significant problem that should be solved.
- A facilitator to lead the team through the Sprint
- The decider to make important decisions during the Sprint
- The team of 5-7 people to do it
- Space, materials, stationeries…
Originally, by the book, the Design Sprint takes five working days Monday to Friday.
The source: https://www.invisionapp.com/inside-design/design-sprint-2/
However, depending on the problem that is to be solved, level of uncertainty around it, how much work has already been done, team experience it can be done in less than that.
As a matter of fact, back in 2018 the Sprint 2.0 was introduced which shortens the time needed for the Sprint to four days, and requires the full sprint team to be available only for 2 days instead of 5. This shortening has been achieved through focusing some of the activities, while at the same time, the implementation in numerous cases has shown that other activities don’t require as much time as it has been initially envisaged.
The source: https://www.invisionapp.com/inside-design/design-sprint-2/
However, for the purposes of this article and simplicity of explanation, let’s assume a full five days is needed.
Monday – the first day of the sprint is the day where the team gets on the same level of understanding of the problem to be solved. Here everything known about the problem is put in front of the team. The decision on the goal, where we want to be in 1-2 years time is made, and this decision is something that will be our North Star throughout the Sprint.
The map of a user journey through our product is made and the decision upon where in the journey we will focus for this sprint is made.
On Tuesday the creative work happens. Interchanging group and individual activities bring us to different proposals of possible solutions. The solution creation is done individually, even more, all solutions are kept anonymous in order to avoid idea pitching, or choosing the solution because someone in particular made it, not because the team believes it is the best one.
Wednesday is the day for choosing the solution that will be prototyped. The solutions created on Tuesday are all pitched by the facilitator in order to provide the same and unbiased voice that will represent them. The team chooses their favourite, and the decider gives their opinion on what should be prototyped. The fact that a certain solution has not been chosen doesn’t mean it is wasted. All good ideas are being parked, and they can be used later should this be found suitable.
Thursday is a prototyping day. Here the team has to make a rough representation of their idea. The prototype should be quick and ugly. There are at least two good reasons for this:
- The team should not spend too much time on something that is just a concept that is to be tested;
- The prototype should clearly show to interviewees that not too much effort has been put into it. This makes it easier for them to give sincere feedback without feeling bad if it is not all sunshine and rainbows.
Finally, Friday is the day when the solution concept is validated with end users, and the day where the energy, tension and team expectations hit their maximum!
One team member is going to lead the interviews with end users, while the others will, via camera, listen, watch and take notes in another room. For this kind of validation 5 interviewees is enough as very quickly the main patterns in user feedback start to show.
Once this is done, what you have is a worked-through idea of a solution, tested with users and a collection of valuable user feedback that clearly points where and how to develop your product further on.
Of course, this is not the end of the product development process, but at this point main issues have been solved and main uncertainties removed.
What are the main benefits of using it?
There are numerous benefits of using the Design Sprint. Let’s name a few.
- Increase speed of discovery and delivery
- Saves money by helping fact-based decisions
- Reduces the risk and uncertainty
- Shorten discussions and alignments in productization phase
- Provides unbiased language for strategic discussions
- Fosters data driven decision making
The Design Sprint also has certain advantages over other techniques used in similar situations (brainstorming or workshops for example). Firstly, as all proposals and ideas are anonymous, the Design Sprint evades situations in which a solution of the loudest, or highest paid person is chosen over solutions that might be better, but the creator is not loud, pushy or influential enough to push them through.
Another thing is that nothing created in the sprint is wasted. If a certain idea is not prototyped and the team finds it interesting, another Design Sprint can be run, and this idea can be prototyped and tested in this new sprint.
How to sell it to your boss?
The crucial thing in running the Design Sprint in your organisation is to “sell” it to your management. Apart from educating them about the Design Sprint and its benefits, there are several things more that you can do.
Prepare main stakeholder (the Boss)
- Position first Design Sprint as an experiment
- Show case studies
- Perform a short version of the Design Sprint to showcase its effectiveness
Prepare other stakeholders
- Workshop to onboard stakeholders
Just run it!
To conclude, should you have a business problem that needs to be solved, or an important decision that has to be made where alignment of different stakeholders has to be achieved, the Design Sprint can help you. Find an experienced facilitator to help you lead you through the process, and start sprinting!
A lot has been said about this framework, but the best way to understand it is to run it. Only through real-life engagement can you feel all challenges and find ways to overcome them. Satisfaction with the result of each sprint personally, but also energy created in the sprint team is something that is really priceless.
[1] The same term is used in another context by Jeff Gothelf and Josh Seiden in their book Lean UX, Applying Lean Principles to Improve User Experience, as a sprint during which the visual design of a certain feature is solved. This sprint happens before the development sprint and provides sufficient information on the feature that will be developed during the development sprint.
[2] Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Jake Knapp, John Zeratsky, Braden Kowitz, 2016