Beyond the 5 Why’s
Updated: Apr 6
Think of the last time you interviewed someone, and they just responded with “yes” or “no.” We have all experienced an interviewee that is a bit reserved or has trouble explaining themselves. The 5 Why’s technique can help you get interviewees talking. This method is taught in many human factors courses and is familiar to anyone in design research. In this post we share our perspective on the 5 Why’s technique and how to expand upon it when searching for the underlying reasons behind human behavior.
Developed in the 1930’s by Sakichi Toyoda (founder of Toyota), the 5 Why’s is an interrogation technique that was originally aimed at understanding whether and why new product features or manufacturing processes were needed. At its core, the technique helps to identify the underlying cause of a problem. The technique is as simple as asking the interviewee the question “Why?” five times in a row. It is most effective when (1) the problem is clear, (2) the person has a deep understanding of the topic, (3) the person answers honestly, and (4) both the person and the interviewer are determined to solve the problem.
The 5 Why’s technique can be used to understand many things, such as user interface problems, workflow inefficiencies, system-level issues, or simply to uncover unmet user needs. By asking why, you allow the person more time to communicate the thoughts behind their statements. This helps you move from surface level responses to deeper meaning. The technique can also be used during root cause analysis to uncover the underlying reasons behind undesired outcomes. You can then apply countermeasures to address the underlying causes rather than solutions that simply address the symptoms. Ultimately, this method is used to get to the core of a problem and then make changes to improve the design.
Let’s see how this technique can be applied to a simple scenario. With this example, it is clear to see that there are layers of causes that are waiting to be uncovered.
You see someone slip and nearly fall while hurrying down a hallway. Later, you try to find out what caused them to slip.
Q1: Why did you slip?
A: I was in a rush.
Q2: Why were you in a rush?
A: I wanted to get to my meeting early.
Q3: Why did you want to get there early?
A: I was meeting new clients. I wanted to make a good impression by arriving early and looking put together. I usually wear sneakers to work, but today I wore nice shoes for my presentation.
Q4: Why do you mention your shoes?
A: The floor had just been cleaned and normally my sneakers wouldn’t cause me to slip. Maybe the floor was still wet.
Q5: Why didn’t you notice it was wet?
A: The floor was already shiny so I couldn’t see the water.
In this example there were several factors that resulted in the person slipping, but a possible mitigation would have been for the cleaning staff to place a caution sign in the hallway.
The 5 Whys is a very simple tool, making it easily accessible, but it also has some drawbacks. Firstly, the technique is very repetitive which could cause the interviewee to feel awkward. Secondly, trying to come up with questions that specifically start with 'Why' force the interviewer to focus more on question phrasing rather than the content of the conversation. Additionally, the interviewee might think you keep asking the same question because they keep giving the “wrong” answer, which is not the case. Finally, the 5 Why’s are most effective with interviewees who have a good understanding of the system, workflow, or user-interface in question. If the interviewee is inexperienced with the topic, many root causes could be overlooked.
While the tool can be helpful to get to the bottom of a specific, clearly defined problem, it is less useful in understanding larger problems that do not have a single cause. These larger problems may require additional techniques to understand their root causes.
Going Beyond the 5 Why’s
The concept of the 5 Why’s is great: Keep asking questions and dig a little deeper with each inquiry. But there are other ways to get to underlying causes without using the word Why over and over. Below are some questions we often use when trying to understand the root of a problem or unmet need.
I noticed you struggled when trying to...what was happening there?
Can you tell me a little more me about...?
In what way was that [worrisome/confusing/awkward]?
Describe to me what you were thinking when...
Talk some more about...
Help me to understand a little about...
What about the device might have led you to...
Tell me about what was going on when you...
Do you think there were any other factors at play?
The key is to ask unbiased, open-ended questions to understand the underlying reasons behind human behavior.
What do you do once you’ve collected all these layered responses?
There are other research methods that can be used in combination with the 5 Why’s to address some of its drawbacks and to help map out the data collected during the root cause interviews.
The first method is to use evidence in the form of observations, photographs, recordings, previous interviews, and/or device event history. This evidence allows you to see exactly what occurred during an event. However, to understand why the event occurred, it is equally important to understand the person’s thoughts and motivations at that moment. Reviewing the evidence with the person and asking follow-up questions, a technique called retrospective analysis, can lead to underlying causes or reasons.
Another complementary technique is a Fishbone Diagram where you brainstorm all the issues that could have resulted in an undesired outcome. The diagram below helps visualize the causes and effects of the problem. The problem statement is placed in the middle of the diagram which is the ‘spine’ of the fish skeleton. Then the categories of causes are drawn off the spine and become the ‘rib bones’ of the skeleton. Once you have several categories of causes, you can break them down further into contributing factors which tend to be the root causes. The more contributing factors you add, the closer you are to the root cause. Some categories to consider for your next Fishbone Diagram are physical evidence, environment, equipment, process, and skills.
While a Fishbone Diagram helps find as many causes as possible, a Fault Tree Analysis (FTA) helps narrow down all the potential causes to one or two root causes. An FTA visualizes the dynamics and relationships within a system including the subsystems, the points of failure, and the safety mitigations. FTA takes a top-down approach; therefore, the top of the visualization is the undesired event and then the events that can cause the undesired event are roots below the main event. Below is an example of a Fault Tree Analysis diagram.
Don’t let your interviewee off the hook!
You’ll never be able to solve problems and address unmet needs with yes/no responses. If you don’t know why your interviewee said or did something, keep asking questions until you do. Then pick a mapping strategy to help you make sense of it all.
If you aren’t sure how to use these methods, feel free to comment or reach out to us to chat about what you’re working on! We’d especially love to hear about a time you successfully used the 5 Why’s.
#research #humanfactors #usability #designresearch #medicaldevices
Fishbone Diagram: https://www.wallstreetmojo.com/fishbone-diagram/
Fault Tree Analysis: https://www.conceptdraw.com/examples/fish-bone-diagram-vs-fault-tree-analysis
A Quick Guide to User Experience Research Methods by James Pannafino and Patrick McNeil