Don’t judge a book by its cover or a process by its name.
The design sprint is not just about design, not only for designers, nor it has anything to do with running. But it has plenty to do with guiding the team’s innovation efforts. A problem, after all, is at the core of good design and successful innovation. And that’s exactly what a sprint is meant to do – solve a well-defined problem in just a few days.
In today’s article, we will get to learn more about the highly praised technique, what it is, when it works, why it fails, and much more.
Whether you are a product manager, a marketer, an engineer, or any other professional involved in creating and launching innovation, I hope that this article will provide some valuable insights and tips for running a successful design sprint.
The design sprint is a customer-centric framework that merges the best aspects of lean development and design thinking into a five-day process for finding the best solution for clearly defined problems through prototyping and testing with real customers.
It’s a short and sweet way to push you and your team out of the same old ways of solving problems, giving “teams a shortcut to learning without building and launching” (GV).
First, a little bit of history.
The design sprint was originally created back in 2010 by author and consultant Jake Knapp. It is a modern take on modern problems, introduced in a fast-paced, and competitive environment, where investing time into projects is seen as a luxury. After all, the design sprint’s charm hides in its rapid pace and short, five-day span in which all the core development steps are taken care of – from ideas to customer-focused tests with real prototypes. No surprise that many well-known and creative organizations have used and loved the method.
The story goes that Jake was running a brainstorming session back at Google Ventures (now GV) when the session was interrupted by one attendee with a burning question every introvert had in such an activity: why are we doing this, does this even work?
After looking into some past sessions and statistics, Jake realized that he was running hundreds of them yet the truly brilliant ideas that got implemented came from a completely different place – solitary ideation.
Jake Later argued against the effectiveness of brainstorming, and while we generally agree, the reality isn’t as black and white. There is never a single perfect process. Rather, there is a place and a time for different tools and methods, and there are best practices to do them right.
However, that aside, we can be happy that brainstorming did not work out at GV because in the end, that gave us the design sprint.
“Design sprints offer a path to solve big problems, test new ideas, get more done, and do it faster”
- J. Knapp
To get the design sprint going you need three things planned and locked in and those are a clearly defined problem, good timing, and the right team.
Even with all three at your disposal, it really gets down to alignment and availability, openness to tackle a big issue that would clearly generate value for everyone involved in the process. Thus, just like with most teamwork-oriented activities, the quality of the sprint heavily relies on communication.
In short, a design sprint starts with a clear problem. The team works together to draw a customer journey map and pinpoints the outcome that must be reached at the end of the sprint. Once that is set, the map gets broken down into the “how”, working your way back from the outcomes to where you are now.
The success of the design sprint gets down to being aligned and wanting to tackle a big issue that would clearly generate value for everyone involved in the process.
Once the target is clear, each team member sketches a solution. Then the project proceeds to the voting phase and the highest-rated solution (or elements of few) gets prototyped. Once the prototype is ready to be tested, it moves to a selected group of people for testing.
Interviews take place at the end of the sprint on Fridays (or Thursdays if you are running sprint 2.0, on that - later).
A common interview step is to conduct user testing or usability testing to gather feedback on the prototype. Usually, this step involves observing users as they interact with the prototype and asking them questions about their experience, in order to identify areas that may need further refinement.
Consider who will be testing the prototype. Their unbiased opinions and input are crucial, so you need real customers. Not closest colleagues, friends, or family. After all, the test results should be the decisive factor in determining whether you should proceed with the project or end it.
It is not uncommon to employ internal members (from different departments) to take part in user tests. It is quite useful for big organizations, where they can dip into the large pool of employees and invite people from completely different departments. It saves time spent on the recruitment process and cuts costs, as involving external users might require compensation.
However, it might not be a feasible option for small organizations where every member is too involved in the design sprint and would be unable to provide unbiased feedback. In such a case, you need to source your users from outside the organization.
There are six key steps in the testing process:
The observation can be done by using a direct feed camera in a designated testing area, or if testing is conducted online, the user and your team can interact in a live call.
However, observation is the keyword here – only the test facilitators should be the ones that do the talking and guide the interview. The rest of your team should simply observe and allow the process to unravel to get the purest, unbiased user opinion.
And so, at the end of the sprint, you are done with the full process of creating a prototype of the product (even if it’s something as simple as a mockup) – in just five days! And finally, having real users test and review your product can save resources by showing whether your product idea is worth the investment, and if so, how to move forward with it.
With that said, let’s dive a little deeper into the whole process.
To begin with, let’s examine who makes the right team.
First, of course, there’s cross-functionality. If everyone comes from the same unit or department, you will hardly consider enough diverse views, get possible solutions, or have a chance to create a viable prototype.
Then again, going extreme towards the other end and inviting everyone to participate also dooms the process. Too many people will simply derail the project and it will be very difficult to manage. Thus, you must find the middle ground.
Normally, it is recommended to stick with a group of anywhere from four to around 10 people and each member should have a clear, value-adding role.
This is not a definitive list of people that you must include. As with many components of the design sprint, the team heavily depends on your unique problem, industry, and market in which you are competing.
The Design Sprint spans from Monday to Friday and is divided into five main tasks that must be covered during the period: mapping, sketching, voting and deciding, prototyping, and testing.
Let’s see what must be done each day.
1. Who will take part/is needed to execute the plan?
2. Who is responsible for developing each step?
3. What tools will be used to reach the final goal?
4. How much time would it take?
5. What are the success criteria, KPIs?
As with most processes and techniques, the design sprint is not perfect, and it isn’t a cure-all. However, when done right and for the right reasons, it delivers tremendous benefits. It can be used at the beginning of pretty much every ambitious project, especially the ones that are looking to create new products, services, or experiences that are tailored to the needs of the customer or user.
The design sprint is an easy and fast way to look over all possible solutions to a problem, especially when the project is time-bound. In addition, the rapid pace and pressing deadline, and gathering of a diverse team from various departments can offer the following benefits:
In general, design sprints can offer numerous benefits for innovation, from speed and collaboration to user-centered design and low-risk prototyping. By leveraging these benefits, businesses can create more successful and innovative products and services.
It is better to receive bad news after five days rather than after two years of development.
However, it's important to remember that while design sprints can be incredibly useful, they are not a silver bullet and may not work for every project or team.
In recent years an updated concept of design sprint was introduced by Jake Knapp. The main concern regarding the original design sprint was that it took a lot of dedication.
Yes, 5 days is not a lot in the bigger picture, but to be able to block off 5 days of work in a row, push aside all daily tasks and usual assignments, and completely dedicate one's time to a sprint is a lot to ask. Hence, Jake and his team looked for a workaround and came up with a shorter version of the original sprint – a design sprint 2.0.
So, what’s different?
First, the biggest change in the process is that Friday is off and the whole sprint gets wrapped up by Thursday. Now, how does that work?
By introducing more tools and different techniques to get to the bottom of things, design sprint 2.0 makes it possible to start the sketching step already on Monday. Hence, every other step – voting, prototyping, and testing moves a day, shortening the whole process to only four days.
In addition, it introduces a new element to sprint – external expert interviews. Expert interviews are a technique used to gather insights from people who have a deep understanding of the problem sprint’s team is working on. In the original design sprint, such interviews were used to focus on internal knowledge, shared in brainstorming and discussion sessions during the sprint run.
However, design sprint 2.0 puts emphasis on external insights and such interviews can be (and normally are) conducted before the sprint. This provides additional knowledge and helps the team make better-informed decisions and move at a faster pace.
This leads the team to produce their solution sketches faster too, which is now done on Monday afternoon along with the user journey mapping. This allows the team to maintain momentum and immediately capture all the ideas that members have generated, instead of delaying the process for another day.
On one hand, a shorter week and faster pace might look appealing but do consider that nothing has been removed from the process. So, an obvious disadvantage of design sprint 2.0 is how incredibly intense it can get. Especially, if you will be running without prior design sprint experience and strong facilitation skills.
It might not be enough time for long breaks, team lunches, and quality discussions about the topic. Everyone must be equipped with knowledge in the first hour of the sprint.
So, while in the end, it can save time, do consider the human factor of this speed run and whether your team is really capable of doing this.
The design sprint is destined to fail for ambiguous problems without any clear solutions, small iterations, and problems to which even partial solutions might take years to develop.
Thus, it is essential to evaluate each project one by one and determine whether the sprint is really a suitable approach or whether it would benefit from a different process, for example, the Phase-Gate.
With that said, sometimes even with the best intentions, design sprints are just destined to fail, causing the team to stagnate, lose focus or just drop the project halfway. So, what are the most common reasons?
The design sprint does not work for ambiguous problems, small iterations, and problems for which solutions will take years to develop.
The original design sprint is typically conducted in person, with all team members present and sharing ideas. The quality of the sprint relies heavily on the openness and collaboration of everyone involved. Virtual tools simply cannot fully replace the benefits of intense face-to-face collaboration, but a combination of virtual and in-person methods can help achieve the best results from a design sprint.
However, with the rise of remote work, many processes had to be adapted to a different environment. The same goes for the design sprint. Its flexibility made it possible to run a successful session virtually too.
But this requires prior experience in running the sprint face-to-face, and strong facilitation skills to ensure effective virtual collaboration and efficient time management.
But before you commit to running a virtual design sprint, remember the good old truth, that just because you can, it does not mean you should – a design sprint is a process created first and foremost for an in-person setting and to get the best results, I would highly recommend trying and organizing it in such way.
However, if it is not possible to meet your team in person, a virtual design sprint might just do the trick for you.
Before trying to run a virtual sprint:
Taking these steps before going fully virtually will serve as a good school to learn the ropes, give experience in managing communications, documentation, and user testing, and will make the transition experience much smoother. And with this, you can then take the action in the virtual space.
Steps to a successful virtual design sprint:
Virtual design sprints might seem easier to run in many ways. It does not require people to be in one place every day, it might cause fewer distractions and help each member to focus on individual work better. It also makes it possible to work together no matter the current climate, no matter people's location.
But it requires a very well-defined, clear process in place, and might be more difficult to facilitate. In addition, regular design sprints can work as a nice team-building activity, bringing people together. However, this part might be missing during a virtual sprint.
So, while it can be an effective way to facilitate collaboration and innovation in a remote team, it requires careful planning, preparation, and the right tools.
A good way to gauge possible solutions is to just try and see how they would work in practice. Some vendors make it a little easier to try the fit by offering free user-based versions, like us here at Viima, and some have demos or other free trials.
The tools will highly depend on your individual needs, sprint goals, capabilities, and your team dynamics – consider them before making any kind of commitment.
The design sprint is a popular, customer-focused technique used by teams to solve well-defined problems and create new products and services with limited risks. Depending on your team's needs and availability, you can run the good old five-day sprint, the more fast-paced – four-day sprint, or a fully virtual session.
It is a fail fast, learn fast way to problem-solving that can save you and your team months upon months spent on development, designing, and testing.
However, successful design sprints require careful planning, preparation, and strong facilitation. It is important to gather a diverse and cross-functional team, define clear objectives and success criteria, and allocate sufficient time and resources for each step of the sprint.
Moreover, while sprints can be highly effective, they are not a silver bullet. It's essential to recognize their limitations and use them only when they can truly generate positive results. Design sprints work best for solving complex problems with a high degree of uncertainty, but may not be suitable for more straightforward tasks, small iterations, or problems with well-defined solutions.
Ultimately, design sprints offer a structured and efficient way to bring together diverse perspectives, rapidly prototype and test solutions, and drive innovation.