5 myths about Design Sprints

mm

Google Design Sprint methodology has rapidly spread during the last years. Nowadays many companies and professionals run Design Sprints to improve their products and services as well as those of their clients.

Despite the fast pace growth of this methodology,  not everyone is completely clear on what Design Sprints are. We have often heard some inaccuracies that can fast become myths.

With this post, we try to shed light on certain aspects that still generate discussion.

Myth #1: Design Sprints are for designers

It is certainly true that being a designer helps: those who have knowledge in Design Thinking can learn and master the Design Sprint methodology easily.
Also, very often designers are those who are responsible for playing the Sprint Master role and taking the team through all of the phases in the process.

However, Design Sprints are not the designers exclusive territory. On the contrary, they are based on teamwork and involve all of those who have a direct relationship with the product and the problem we want to solve.

One of the great strengths of Design Sprint is the ability to access information that usually escapes us or is left behind between the folds in the structure of our company.
During a Design Sprint, all what we know about our design problem is shared amongst all of the team members.
The result is often surprising: with access to this new information, individuals from different departments, with different profiles and skills, are able to look at the problem with very different approaches and generate innovative ideas. Very often the idea that is chosen is not the result of a designer’s work, but of some other member of the team.

Design Sprint exercises do not require any specific design knowledge to be able to be carried out.

Yes, there are phases in which sketching is required, but only as a mean to communicate our idea more effectively. At no time are participants required to become designers.

 

Myth #2: Design Sprints are guarantee of successful ideas.

It is often believed that the only objective of a Design Sprint is to obtain successful ideas.
The truth is that Design Sprint was born as a method to reduce the risk of making bad decisions when you face a design or business problem.
Does this mean that all of the ideas generated in a Design Sprint will be good? No, not necessarily.

Design Thinking techniques that are used during a sprint help create innovative solutions that in many cases will be much better than those created in the past.

However, there is always the possibility that these ideas are not good for your users.

Actually the real super power of Design Sprints is the possibility to understand if your idea is good or bad after only 5 days and with no need to really develop anything.

This brings us to the next myth about the Design Sprints …

 

Myth #3: You can sometimes skip the final validation of your idea 

It is very tempting, after 4 intense days of workshop, to want to skip the last step: validation with real users.

After all, you have all agreed on what to design and you are also quite convinced that it is a winning solution.

In addition to this, carrying out the validation can be a somewhat tedious process.

You need to prepare the day’s activities (recruit the participants, find a suitable room, write a script for the sessions …) and, very possibly, you do not have ANY user research knowledge and need some training.

Do not even dare to think about skipping validation!

Without testing and confirming the goodness of your idea with your users, all you have is nothing more than hypothesis. Consensus does not make an idea necessarily good.
The true competitive advantage that a Design Sprint brings you is that you can know right away if your idea works. If it doesn’t, you can keep iterating.

If you do not validate your solution before developing it, it is very likely that you will spend time and resources in creating something that is not going to help you solve your design challenge.

Almost no solution created during a Design Sprint pass through a validation phase without needing improvements. In some cases, it is only minor changes, but, in others, it is the concept itself that does not work and has to be discarded.

 

Myth #4: Design Sprint are only for startups.

Applying the Design Sprint within large corporations can be a challenge for many.
Companies very often have well-defined work processes and are reluctant to introduce new methods.

In addition, the larger the company, the more isolated the departments that are can be involved in a sprint will be.  
As a consequence of that, it will be even more complicated to create multidisciplinary groups that come together for a Design Sprint.

It can be very easy to think that startups are the only type of company that can take advantage of Google’s methodology. In the end, the Design Sprint was born in Google Ventures to help its startups portfolio and the way in which new companies work is very well suited to the model.

Processes yet to be defined, small teams used to working together, agile mindset … all of these are ideal conditions to start working with Design Sprint.

However, we also have numerous examples of large corporations that successfully apply the Design Sprint on a daily basis.

A quick Google search reveals dozens of cases, from the British Museum to BMW.

Our experience carrying out Design Sprints for companies like KLM, Ecoembes or Vueling among others, confirms that yes, companies can successfully implement Design Sprints in their processes, especially if they have an innovation departments and rely on experts who guide them during their first steps with the methodology.

 

Myth # 5: Design Sprints are for digital Products only. 

The vast majority of success stories that we know about Design Sprint are related to digital products.

It is quite predictable: many of the startups born nowadays are tech companies. It is also very easy to apply the Design Sprint to an interface, be it an app, a website or any other device.

Despite this, Design Sprints can be applied to physical products or services, or even generate a physical product as a solution to a digital problem.

A couple of years ago we helped the Hightrack team to get to know the Design Sprint and implement it in their processes.

Hightrack is an app dedicated to the management of tasks and activities to improve personal productivity.

During one of their first Design Sprints, dedicated to improving their product, the friends of Hightrack surprised us with an unexpected result: a physical agenda.
How did Hightrack create an agenda as a result of a Design Sprint for its app? Have they done something wrong?

Not at all. Let’s not forget that the Design Sprint is an instrument to arrive to the solution of a problem, but it does not define beforehand how our solution has to be. The Hightrack team has found an innovative answer to their problem and has also demonstrated how the Design Sprint can be applied successfully to different contexts.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

TeaCup Lab shapes your UX strategy with Design Sprints and User Research