The Design Sprint (or just The Sprint) is the process introduced by Google Ventures and Jake Knapp, author of “ The Sprint”.

The main method idea is to answer the most critical project questions and doubts in just one week.

There’s no endless brainstorming sessions, no coding – just short, highly energetic activities that push your product forward.

Why did we decide to use it?

Our team creates merchandise solutions for Zalando employees and our business partners. We deliver tools that often need to support complex business logic and related procedures.

Before Sprint, we had a lot of questions about our users, their jobs, and goals. Our knowledge was unstructured; it was hard to clearly explain a big picture of our future plans.

We had many different ideas about how to improve the life of our users. Unfortunately, there wasn’t any strong proof of which ideas were deemed the most valuable.

We were looking for a way to answer open questions, structurize findings, and establish a long-term strategy for our products. The sprint concept sounded like something that fitted our problems perfectly.

We decided to find out if it really works.

Results

Sprint is flexible

Since we have not seen any showcases focused on enterprise, we were not sure if the sprint could be adopted to solve our problems.

It was not an issue. We have used the sprint twice (to find the way to deliver the best product information, and to improve the overall ordering process), and in both cases we felt that the sprint activities were helping us to solve our problems in a creative and more motivated way.

The Sprint is not a silver bullet for all your problems…

In fact, sprint activities are not really revolutionary. It is more like a framework for existing methods that helps to use them more efficiently in a limited time.

Something else to note is that the sprint is only as good as your team. If your team don’t choose to be fully involved and disrespect the rules, the results will be miserable.

Sprints can illuminate the way for the progression of your product, but when you are already on this path and you need to deliver it, the sprint’s role is limited here.

… but it works!

Although the sprint has its limitations, it was very helpful in our cases.

In one week, we achieved progress that often requires many weeks or even months. We answered a lot of product questions and analyzed our user problems. We were also able to generate, discuss, and test a few possible solutions.

And the most important thing: the sprint was valuable in establishing long-term product strategy and it gave us confidence knowing that we were on the right track.

Tips and tricks

Build a diverse team

A sprint team usually consists of seven people. It is natural to try to recruit the most important, clever, or talented people in your organisation.But the most crucial thing here is diversity. I am sure that our sprint would have been less effective if we were not including developers or customer specialists on our team.

Try to consider people that can understand your problem from different angles, even if they are usually not involved in making product decisions.

Don’t forget about the prototyper

If you’re making the wrong decisions during the first three days, you can’t get that time back. While painful, you can live with it. But if you fail further over the course of the following two days, you’ll receive incorrect answers that might push your project down the wrong path for months.

Ensure that at least one person has experience in creating interactive prototypes. You only have one day to prepare a realistic product simulation. It is really challenging and it will be even harder if you need to learn how to do this first.

An experienced prototyper will not only be more efficient, but also help you decide which elements are crucial and what can be skipped.

Remember the researcher

Friday sessions should be lead by an experienced researcher. If you are unable to recruit anyone for the whole sprint, try to invite them for at least the last day.

In my mind, people with no testing experience tend to suggest proper solutions for the user (usually unconsciously, for example by using subtle gestures).

Being a test observer can be tricky as well; sometimes it is hard to distinguish test observations from a user’s opinion, which can be misleading.

A good researcher will help you prevent these problems.

Cancel other meetings

Daily sprint work is divided in two three-hour blocks. It might look like you’ll have enough time to do some extra tasks on the side. This is not the case.

A Design Sprint is like sprint run: Short but intensive. You can run (or work) at your maximum level for a limited period of time. If you waste your energy on other activities, you will be less effective during sprint sessions.

We all know how hard is to clear your work calendar for whole week, but I implore that you try to do so – it is absolutely worth the trouble.

Keep to the schedule

Every sprint activity has strict time frames. Quite often, you may have the impression that it is not enough time to finish meaningful discussions or perform tasks properly.

Despite this, do not change the sprint schedule. Your time is limited on purpose: Work is short but intense, and everything that is not considered essential must be skipped.

If you try to “hack” the schedule you will lose intensity, focus, and energy.

Conclusion

I hope the explanation I’ve given has inspired you to explore using a Design Sprint to solve your own user problems in your team. With the success we’ve had, we’ll surely be using this technique more thoroughly in the future.

If you have any questions about our process or want to get in touch, you can reach me on Twitter at @adriandampc.