We explain what a Design Sprint A design sprint is a 4- or 5-day process for quickly solving major challenges, developing new products or improving existing ones. This allows months of work to be compressed into just a few days.
This is achieved by creating prototypes and testing ideas with test subjects. A quick way to solve major problems that a company has without making major time commitments.
Design Sprint briefly explained
The design sprint was developed at Google Ventures. The process gained notoriety in 2016 through the book "Sprint" by Jake Knapp, John Zeratsky and Brad Kowitz.
A design sprint saves time and money. Challenges can be solved and ideas tested in 4 (or 5) days.
Perhaps you are familiar with this situation: you are faced with major challenges, want to test new ideas but are not really making any progress.
Many ideas and opinions come together at the brainstorming meeting in the validation phase. There is a long discussion, perhaps lazy compromises are made and then implementation begins.
In the best case scenario, an MVP (Minimum Viable Product) is built. But even that takes months. And once you have finally launched the product on the market, you realize that you have missed the customer a little. With the newly gained knowledge, you then go back to development.
This is actually not a bad process, true to the motto Build - Measure - Learn.
However, a lot of time is lost during the build and launch phase in particular. Even building an MVP is a risky investment for many companies.
With a design sprint, this resource-intensive part can be skipped. With the help of a prototype, you can go straight to validation. This allows you to fast-forward to the future. Customer reactions to the product can be captured directly before making expensive commitments.
This allows you to jump directly into the future to see your finished product and the reactions of the test subjects before you make expensive commitments.
Need support? We guide you and your team through the design sprint! Talk to us.
Design Sprint 1.0 vs 2.0
The design sprint in version 1.0, as it is still described in the Sprint book is a five-day process. As it has often proved difficult in practice - especially in large companies - to take the sprint team out of their daily work routine for an entire week, the process has been streamlined somewhat.
The first three sprint days were shortened to two days using moderation tools. The last two critical days (prototyping and testing) remain unchanged in terms of time.
However, it is no longer necessary for the entire team to be present for prototyping in particular. It is sufficient for a smaller team that specializes in prototyping and is familiar with the sprint to work on the implementation of the prototype.
While it has proven easier in practice to carry out a Design Sprint in version 2.0, this does not mean that a Design Sprint 2.0 is better or worse.
If the task is particularly complex or the team has little or no experience with a design sprint, it may make sense to take the extra day. With a experienced sprint moderator However, even an inexperienced team can cope well with a Design Sprint 2.0.
In the end, time is the deciding factor: whereas in Design Sprint 1.0 each team member works for around 35 hours, only around 12 to 17 hours are required for V2.0
Design Sprint V 2.0 Procedure
On Monday we start by creating a common understanding of the problem: we invite experts and share our knowledge as transparently as possible within the team. Even "obvious" knowledge is put on the table so that everyone in the team really understands it. This is because understanding is often only distributed in the individual heads of the team.
As soon as we have reached a common understanding, we develop ideas. Everyone has the opportunity to visualize their ideas and share them with the team. By the end of day 1, we have already developed possible solutions.
At the beginning of Day 2 we decide on a favored idea and develop it throughout the day into a solution that is as mature as possible for the application scenario in the form of a storyboard - the basis for the prototype.
WednesdayThe third day is dedicated to prototyping. Headphones on, hoodie on, full throttle. We create a prototype that pours the good ideas and exciting hypotheses into a mold.
Today it counts: Thursday. The fourth and final day. We show our prototype to five selected test subjects. We receive direct feedback to find out whether our ideas are sustainable - or not.
Design sprint in one day
Even if it should be a top priority, for most companies it is a problem: making employees available for 4 or 5 days for a design sprint.
It is therefore also possible to concentrate a design sprint on one day and thus take the workload off the employees. However, this requires precise preparation. And there is also a lot to do in the follow-up.
After one day of the design sprint, the sprint result will not yet have been determined. But it can be used as a solution to conserve the scarce resources of employees.
When is a design sprint the right tool?
A design sprint can be used in three scenarios
- You have a major challenge that you need to solve quickly
- There is a completely new product idea
- An existing product is to be improved
Always bear the following situation in mind: Let's assume that we were to design and develop the solution idea for one of the three scenarios above directly and put it on the market without having shown it to test persons beforehand. Now the solution idea fails and we realize that we have not developed it for the market.
How big is the impact of this failure for your company?
If the impact is rather low, we do not have a major project risk. There are other methods that are better suited to idea validation.
However, if the impact of failure on your company is medium to high, you should consider a design sprint. This allows you to limit the risks considerably in advance.
What does a sprint challenge look like?
Regardless of whether you need to solve a challenge, have a completely new product idea or improve an existing product. All design sprints should have one thing in common: A well-chosen sprint challenge.
A sprint challenge should be chosen so that it is not too narrow, but also not too broad.
Let's assume we want to solve the following problem: "My sales representatives always submit their monthly statements too late"
The challenge "How can we use a smartphone app to speed up the process?" would be too narrow. A solution (smartphone app) is already given here. However, there may also be better solutions that don't require an app?
The sprint challenge "How can we get employees to meet deadlines?", on the other hand, is far too broad. The specific problem of monthly billing is not mentioned. Deadlines could also affect projects of any kind.
The following sprint challenge is more suitable: "How can we simplify our monthly payroll process so that employees can complete it more quickly?"
The problem (simplify the monthly billing process) is specifically named, the goal is defined (complete it faster) and the challenge does not include a specific solution (smartphone app).
The first design sprint: getting support
Anyone conducting a design sprint for the first time should seek external support. Only an experienced sprint moderator can ensure that the design sprint really is a success.
There are a few stumbling blocks here, especially for inexperienced teams, which the Faciliator can easily avoid.
We are happy to support you with your design sprint on request. Inquire here.
DE_DE 
EN