How And When To Use The 5 Whys
The 5 Whys is a technique that was developed by Sakichi Toyoda, the founder of Toyota Industries, as a problem-solving framework. It was utilised to drill down to the root cause when a problem occurs, in order to develop a counter-measure to prevent that problem from recurring.
Today, we can utilise this technique in User Experience Design as a counter-measure when something doesn't go as expected, but also as a pre-emptive tool to understand if we are solving the right problem in the first place.
Using The 5 Whys as a counter-measure
This is the original intention of this technique; to define the problem that arises, and dig to the root cause to understand what needs to be fixed in order to prevent the problem from happening again. It is a reactive process that fits in very well with the iterative and agile nature of the digital product design and development process, especially if you're releasing new iterations in every sprint.
With each iteration of your product, you will be tracking usage and analysing metrics to make sure that your latest updates are delivering on the goals. If you are falling short of your objectives following a release, or another issue becomes apparent, you can ask The 5 Whys to figure out how to resolve the problem.
Here's a hypothetical scenario to illustrate the process.
Problem: People are only visiting our website for less than 5 seconds and leaving.
Why are they leaving?
There is no content displayed on the page.
Why is no content being displayed?
The content takes more than 5 seconds to load.
Why does it take so long to load?
Because the browser downloads lots of tracking scripts before the content.
Why do we have so many tracking scripts?
Different ones have been added over time, and redundant ones have not been removed.
Why have they not been removed?
Because nobody told us that they were no longer being used.
From asking why 5 times, we have gone from knowing that people aren't staying on the website, to the reason why they are not staying on the website. Sometimes it may take fewer or more whys, but your ultimate aim is to find the actionable conclusion.
Utilising The 5 Whys as a reactionary tool is great to find these problems, but is there a way to prevent bigger issues from happening in the first place?
Using The 5 Whys in discovery
The value in the design process is the ability to uncover problems early, and therefore reduce the amount of heavy investment required in designing and developing a new product or feature for release.
When used in the discovery phase of the design process, The 5 Whys can be used to make sure that we are focusing on the real problem, and not acting on making a solution to cover up a symptom of that problem.
Here's a hypothetical example to illustrate.
The product owner comes to the team with a new feature that is to be developed. There is little information aside from that one of the senior stakeholders is adamant that this is the most important thing that needs to be worked on to get it to market as quickly as possible.
This is where we can utilise The 5 Whys as a tool to understand why we need to build this particular feature (if at all), and why it should be placed ahead of everything else that is in the backlog of work.
You will likely need the relevant stakeholder involved in this kind of exercise in order for you to find the answers you need, not only as to whether you should be working on this as a priority, but also to gain a better understanding of the origin of the work.
In some cases this can be a difficult conversation, but it is part of your job as a designer to understand the problem that the suggested feature is trying to solve, rather than just understanding the feature itself. When a feature is suggested in such a way, it can often be a sign that many conversations have happened before this point, and a solution has been decided upon at a higher level that is intended to address the problem.
Whatever the origin of this new feature, you need to understand the problem itself, and not a pre-defined answer aimed at solving that problem.
By utilising the same steps outlined when using The 5 Whys as a counter-measure, we can drill down to the underlying problem that the proposed feature is meant to solve, and from there begin to look at ways to solve that problem without a prescribed path with little to no flexibility in the design of a more effective solution.
In understanding the real underlying problem to be solved, you may find that the feature suggested will be the best way to create a solution. The time you have taken to arrive back at the original proposal should not be considered a waste of any time, as you will likely have a far greater understanding of the reasons why you are going to design and build this new feature.
However, sometimes the opposite may be true, and you will find that the proposed feature would not be a real solution to the underlying problem, but would perhaps alleviate some of the symptoms caused by that underlying problem. In this case, you may have just saved a huge investment of time and money in developing something that would have done nothing more than cover up a bigger problem with a figurative sticking plaster.
Real-world outcomes of The 5 Whys
Those possible outcomes covered above regarding the use of The 5 Whys in discovery are examples of the opposite ends of the spectrum. In the business world, decisions will be made on far more criteria than just the result of a single exploratory exercise into the problems that need to be solved. These will include the feasibility of a proposed solution, a timeline to get your feature out to market, providing value to the business, providing value to the users, and many more besides.
You may end up with business being in agreement that the larger underlying problem does need to be fixed, and assign you to undertake initial design work on a solution. But you may also discover that the amount of work required to implement the best solution will take far more time, more budget, and more people to address it effectively.
Your ability to make compromises as a designer in these kinds of situations will be key to the success of your product. Weighing up all of the different aspects of how to deliver a solution, setting a path that will ultimately lead to the best solution in the long run, and in some cases accepting that it will take many smaller steps over a longer time to get you there.
Losing a battle to win the war in the longer term is often how things pan out in the real world when it comes to designing products that a business relies on for income. Every case is a learning experience, but being armed with tools like The 5 Whys gives you the ammunition you need to make the right decisions for both your users and your stakeholders.
Let me know how it works out for you
Have you used The 5 Whys in your process before?