Business, Design

What Design Sprints have taught me about efficient team work

July 5, 2016

Read time 4 min

Following the recent publication of the bestselling book The Sprint, the Design Sprint has been all the rage in the industry. The Sprint bundles design thinking with an attitude of “Getting Things Done” and facilitation practices from Google Ventures and Ideo.

The Design Sprint is a week-long endeavour to design, prototype, and validate ideas with customers: “the sprint gives teams a shortcut to learning without building and launching.” The team works on an idea for a product or a concept for five days, with pre-defined daily targets that force members to focus and prioritize. The process is supposed to boost productivity by reducing distractions and general slacking. Leeway for excuses is narrow, the team has to focus on delivering something tangible.

The week is intense but not crunch mode, fast-paced yet focused, demanding but not stressful. For an attention span-challenged person like me, the design sprint is a really satisfying discipline. I’ve collected some tips on how to stay focused and work effectively from the past Sprints.

Form a motivated team

In order to get through a design sprint week, it is crucial that every participant really wants to work on the specific case with that particular team. The ability and will to find ways to make oneself useful without too much guidance is imperative. Most of the time, the mission is to “do or explore something which might be of use for us on Friday”.

Trust in the team, the ability to both put egos aside and be undisguised in front of fellow team members are all important. One should be prepared to present unfinished work and receive criticism point blank.

Time is like white space, think carefully how to fill it

Discussing issues openly can be take up lots of time without actually accomplishing much. The Sprint book offers a variety of methods for “working individually together.” Conversations are more productive when everyone has prepared something by themselves first. 

We’ve usually sketched and prototyped in 45- to 60-minute iterations. When the timer goes off, we present our work and discuss briefly on what to concentrate on next. Avoid over-explaining your work, just absorb feedback and take notes. Discuss over a sketch, written draft or sequence of boxes rather than speculate on an abstract level.

I’ve found it helpful to split the short, individual iterations into three parts, 20 minutes each. The division forces me to get something down.

  1. Start with a gathering of ideas: don’t try to draft anything
  2. Produce as many solutions, written or drawn, as possible around the same idea
  3. Refine the best idea into a presentable form

Set goals for each day

A short discussion in the morning about what should be accomplished before the start of the next day – and then checking the situation at the end of the day – helps the team work in sync.

In one design sprint which I was a part of we didn’t map the problem well enough on Monday. This lead to disconnected working, because we weren’t solving the same challenges. We ran behind schedule for three days and were only able to bridge the gap on Wednesday’s decision presentation.

The point is: skipping the phase of clarifying goals of the day will cost you later.

Get the client involved

An intense Design Sprint week is a wonderful opportunity to incorporate the client into the team. With a week-long schedule, things move along rapidly. This encourages the client to clear their calendar and fully participate for those five days.

The positive sense of urgency is really evident when the team arrives on Monday and immediately starts plastering post-its onto walls like Jackson Pollock. The shared “war room” is a visual display of the team’s energy. When bundled with tangible results, it’s a breath of fresh air for a big part of organisations.

Furthermore, the design sprint can also be a fast lane for trust building – ways of working are easier to explain after the client has witnessed the dedication of the team first hand. Of course, there’s expectation management to be done afterwards in order to explain the more sustainable pace of the follow-up implementation project.


After doing a number of design sprint weeks I’ve realised that in many design cases, the extra time hasn’t really given that much more assurance about whether the design works or not. Often the additional time is used to studying backgrounds rather than exploring new approaches.

Within a short timeframe, it is also much easier to “kill your darlings” if an idea simply doesn’t work than in a long specification or concept design process.

So far, the Design Sprint has been really a motivating and satisfying way of working, and I recommend trying it out. Obviously, the design sprint isn’t for every case, and it has its limitations. Nevertheless, Sprint weeks are thoroughly rewarding, and the amount of high fives on the last day of the Design Sprint is squared to the high five count of regular Fridays.

Never miss a post