Design sprint - when is it the right thing to do?

The classic design sprint consists of a series of activities and processes that make it possible to go from idea to validated prototype of a concept or product in just five days. The process is carefully planned and executed according to defined time frames that ensure the process is constantly driven forward - a sprint!

At Charlie Tango we've been using a modified eight-day design sprint for many years - though not as religiously as many other agencies. Every project and clients need is different - which is why we're strong believers in organising tools and methods depending on what we're dealing with. We believe in the value of a design sprint - but only when we can clearly see that it solves the right need.

We add the extra three days to the process because we believe in the development of a more thorough prototype, where the insights gained at the end are implemented and corrected. Throughout the process, we also emphasise the presence of the different roles and stakeholders that the product involves; UX and UI designers, business people, the customer, the user and the development team. This gives us the best chance of creating a successful and relevant product.

But when do we recognise the need for a design sprint? We see the most value in using the design sprint in three different situations:

#1 "Come up with a new, innovative concept"

Design sprints are known as a catalyst for innovation - the root of fresh, creative ideas. To that end, the sprint is hugely effective. The ideation phase allows for inspiration, quick sketches and discussion forums, kick-starting the manifestation of ideas and ambitions into a concept that will be tested and user-validated later in the week. We humans are wired to do what we're good at - what we know works - and that's not a recipe for creating a completely different concept. If you really want to take creativity to the next level, as a facilitator you need to work systematically to get the participants there.

#2 "That thing we've been thinking about for years - is it really a good idea?"
It's not often that we're asked to start from scratch. Most of the time, the customer has skilled employees who have already thought about how a digital solution can be improved. The design sprint gives these ideas a well-deserved test run so they can either be discarded or put into production - rather than sitting at the bottom of the backlog or tucked away on a dusty drive as an idea note. With the design sprint, we quickly concretise ideas and test them on end users. This allows us to make informed decisions about what is worth developing, what would improve from another round of ideation and what should be discarded altogether. We organise such design sprints with the ideas from the backlog at the centre.

#3 "Concretise a concept so it can be pitched"
A third version of the design sprint aims to support a pitch. It usually stems from someone having an idea that they want to realise. But it's hard to convince decision-makers because it's too vague. In this case, the design sprint uncovers and concretises the concept, making it possible to test on end users. This means that in the end, we don't just have a described idea, but rather a visually expressed and user-validated concept, which makes it much easier to decide whether the concept needs to be specified and developed. While the UX and design designers concentrate on visualizing the concept, the more business-oriented people in the team can develop a business plan. The combination of a visual and user-tested concept and a descriptive business plan is typically an optimal format for taking a qualified position on the concept's value and further development.

There are many opinions on how and when a design sprint should be carried out. At Charlie Tango, we work with a wide range of businesses and organisations - from pharmaceutical companies and government agencies to banks and sushi restaurants. The process varies not only with the profession, but with the product, the problem statement, the customer - pretty much every parameter. Therefore, we need to take each case individually and assess which tool is needed and how best to utilise it.