Why Design Sprints Don’t Work: The Problem with SCRUM
Coming across Design Sprint criticism is not new for designers and developers.
This article will take a closer look on these issues and expound on them.
But first, let’s get acquainted with Design Sprint.
Design Sprint involves implementing and testing new ideas and strategies in five days for product design.
In theory, this is a perfect scenario, but you can’t solve critical business problems in just five days in reality.
Though you aren’t going to have a finished product, you will have clear insight on what to do next.
The outcome is an interactive prototype, tested by a team of professionals (designers, managers, researchers, etc.).
The team, though, must have in mind that this is only a prototype and not a business solving model.
Design Sprint is an excellent tool to help you anticipate what’s coming.
You’ll know how the customers will respond to a new product even before you start investing money and effort in building it.
In this way, you’ll have a more efficient way of solving problems.
Moreover, you’ll be one step closer to the finished product.
Design Sprint Concept
The whole concept of Design Sprint rests on these actions: Map, Sketch, Decide, Prototype, Test.
Usually, these phases are conducted by a team of experts.
They’re synchronized to work together during the different days and phases.
Day One: Map
Starting from day one, you should understand the challenge and face the problem.
Also, in this phase, we note the needs and the habits of the end-user.
Day Two: Sketch
The second day is all about sketching.
Once the team is familiar with the problem, they can start brainstorming.
Each member of the team provides his solution based on the information from the first day.
Day Three: Decide
Day three is reserved for decisions.
Based on the voting, the team chooses the best ideas and solutions.
Sometimes the voting is conducted with tools like Jira or similar software.
Day Four: Prototype
On the fourth day, the team will build a prototype and prepare for the final phase.
This is the moment when you make your idea “come to life.”
Usually, this is done by one of the members using software like Figma, Adobe XD, or Sketch and some other UI Design applications.
Finally, the last day is for testing.
Day Five: Test
The team will present the prototype to some of the users, so that they can gather feedback.
In this way, the team will know what the next steps to take.
Maybe they’ll start working on another project or try to fix the problems on the current prototype.
Although the expectations about design sprint are high and believed to solve all of our problems, we don’t always get a finished product that meets the client’s needs.
The fact is that sprinting never really solves any big problem.
This is because it isn’t possible to design a new business model in such a short period.
If you’re interested in learning more about this topic, click on the following link.
Issues to Contend With
Lack of Information About the Users
Before you can start with a design sprint, the most important thing is to learn more about your users.
Firstly, what motivates them?
Secondly, what are their goals?
Lastly, what does the word success mean to them?
The answers to these questions take time and a deep understanding of your users.
Fundamental research is a crucial part of this journey.
But can you do it in five days?
Conducting a comprehensive kind of data gathering in five days is next to impossible.
Every human being has different needs and concerns.
To produce great products and services, you need deep knowledge of your end-user.
The product needs to be able to make life a little bit easier for the users.
Sometimes we cannot collect all the data, insights, facts, and requirements that quickly.
We need to time to create viable solutions.
In this case, we’re creating a prototype based on loose assumptions.
This might sound a little bit illogical or confusing because we’re providing a precedent, which later becomes the primary reference for any upcoming discussions.
It’s more likely that this will put our solution at risk at some point.
This can result to hiding significant flaws in our previous assumptions.
Based on the users’ feedback, there will be different reactions to the sprint.
If the feedback from the users is good, the team can go on with a more detailed approach and start preparing the implementation.
Now, if you get bad feedback, you’ll know that you have to conduct some more tests with the users.
You will be relieved, knowing that you haven’t wasted time and resources.
If you have an upcoming business project and you’d like to know whether a sprint is a suitable approach for you, read a little bit more here.
There are other significant issues before you decide to run a design sprint.
Absence of a Group Leader
One of them is the absence of a leader in the group.
Sprints are usually flooded with designers and planners because that’s what most people expect they need to get to the best outcome from the prototype model at the end of the day.
There’s this idea that you basically put together several designers in the same room, and eventually, they’ll come up with a great idea.
Well, this is far from the truth.
For a design sprint to be successful, you need various positions (managers, marketers, etc.), and of course, the most important guy in the room, the decision-maker.
This is the person who has the power to throw away everything you worked on.
Get this guy in the room!
The biggest challenge, of course, is to make sure you are trying to solve the right issue.
You’re spending time, money, resources, and effort, so be sure that you have the right problem to solve.
Fast-Paced Nature of the Design Print Process
Another problem is the fast-paced nature of the design sprint process.
Often the team can’t keep up with this.
And the entire sprint will slow down and become just another waste of time and money.
The key is to be focused, trust in what you’re doing, follow the plan, and stick to the exercises.
This will be a lot easier if you have a team with experience managing the sprint process.
However, keep in mind that it will be hard to gather a team of professionals because most of them are already working on other projects.
If you don’t have the right persons for the job, don’t even start.
And the last thing you need to ensure is that the issue you’re bringing to design sprints is worth solving and can be prototyped in 4 days.
Check out this article for more information.
The Reality with Design Sprint
Design Sprint have some conflicts within the SCRUM-agile framework.
This is the part where we’ll do more headbutting with some design sprint criticism.
Many people expect the Design Sprints to deliver a perfect set of different designs for the developers to implement.
But this is a wrong expectation.
Design Sprints are more of a prototypical character.
We can even dare to say that they’re not even ready for implementation most of the time.
This is due to their incompleteness.
A good prototype is initially set to explore a set of well-defined hypotheses.
And everything that is not in this range, will be left out as unrelated to the testing phase.
Also, using the information collected only for one day as a foundation for a project which will affect millions of people is absurd!
Another big problem is the situation where Design Sprints put an accent on the “think out loud test.”
In this case, the user is supposed to verbalize his thoughts and feelings.
This is hard, especially if you’re sharing your thoughts for a brand new project Y.
You can not always present the big picture that you have in your mind.
Design Sprints tend to force businesses to come up with critical decisions in a brief period and sometimes even without a proper understanding.
Lack of understanding can lead teammates to have arguments with each other causing hostility.
As we mentioned before, SCRUM and Design Sprints can operate alone, but they’re always better together.
It can be challenging to persuade others to participate and invest one week in something that is still not familiar to them or trust the process yet.
To fully understand its power and beauty, you should experience and be part of this process.
Read more about “Design Sprints are Absurd” here.
Despite the criticisms on design sprint, you shouldn’t completely discard it.
This is still an excellent tool that represents a beneficial addition to the set of potential solutions.
Don’t think about design sprint as a silver bullet.
Instead, it should be considered as a part of the overall design process.
Please don’t set your expectations high on a sprint–that it can help you solve significant issues or lead you to a perfect design scenario.
Keep in mind that it is not an independent process.
But, rather, it is a part of a whole system working for a solution.
If you enjoyed this article and video on design sprint criticism, you might want to view, too, the videos below.