You Are Using the ‘5 Whys’ Wrong. Here’s How to Improve.

Executive summary: The practice of “5 Whys” was pioneered by Toyota, and is practiced by designers worldwide. It is a research technique meant to get to the bottom of things. Many write about it, but neither Forbes, nor IDEO, nor the Interaction Design Foundations tells you about 2 dangerous flaws baked into the technique:

  1. You should not ask “why” — for multiple psychological reasons.
  2. And you should have a much clearer roadmap for when to stop than just arriving at your 5th ‘why’.

Read point I below to understand what the technique is about; read point II to understand the flaws in detail; read points III/a&b for practical advice on what to do instead; and read point IV for an example. This article will help you improve the “5 Whys” for yourselves, your interviewee, and your project.

I. What is it?

Basically the “5 Whys” is a research technique, where you are meant to ask the question “why” repeatedly, until you arrive at the root cause of a given problem. Here’s a more detailed demonstration and explanation.

But is “why” really the best question? And will you get to the root cause by the 5th question? No and no. Let me tell you why…

II. What are the 2 flaws?

The two flaws I keep referring to are baked into the origins of the technique developed at Toyota.

Flaw #1

The first flaw is that asking “why” may sound simple, but is actually burdened at a cultural, a personal, and a semantic level.

  • First, the cultural burden. If you know anything about Japan, you know it is different. Very different. So don’t assume that asking “why” is an exception. There are as many as three, or up to six ways to ask “why” in Japanese. I am not sure which “why” Toyota used, but whichever it was, it came with very different connotations than any western “why”.
  • As for the personal burden: As we grow up, parents ask us “why” we did this or that. Later on, our managers ask the same question. And because of this, there is an inherent interrogatory, even blame-attributing nature to “why”. This instantly triggers a stress response, and sets off a defense mechanisms — and you don’t want that feeling in your interviewee.
  • And finally, the semantic burden: Designers are encouraged to use open questions in interviews, like “who”, “what”, “where”, “when”, “how’ and “why”. But these actually represent three different categories. “Who, What, Where and When” are ‘ingredients’ — they are factual and precise. “How” is procedural, systematic. And “why” is past-oriented, motivational, and tends to be more abstract and ambiguous. It is a category on its own.

Flaw #2

And the second flaw is that this technique was developed for a manufacturing process. For finding root cause of mechanical problems and processes in a factory. But life is not a conveyer belt. When looking for root causes at Toyota, arriving at a fault earlier in the process, or a fault in the process itself was enough of a root cause. When improving the design of a service or product for end-users, factual causes are rarely, if ever, the root cause of a problem. There is a much larger human element to it.

Let’s now see solutions to remedy both of these above flaws.

III/a. What to ask instead of “why”?

Multiple articles on the subject point out that you can use other words than “why”, but never explain the cultural, psychological or semantic reasons outlined above. Most articles just say “ask why repeatedly”. To avoid being perceived as a parrot, do this instead:

  • Ask “how come” — though just a minor tweak, it appeals to the other person’s insights in a non-threatening way.
  • Just say “Tell me more…” or “Tell me about that”. Beyond communicating curiosity, this also allows your interviewee to share their thought process and reasoning.
  • Really build on previous answers you received. E.g. if your interviewee says “I didn’t have time to exercise”, instead of asking “Why didn’t you have time?” you could ask “Were you occupied with something else?” This transforms your question from what could be perceived as an accusation to one of interest and assistance.
  • Begin with “what”. This makes the answers more concrete. E.g. “What were the reasons for you not having enough time?”.
  • Use any of the ‘ingredient’ type questions, such as “Who, What, Where and When”, to get more precise and factual responses.

However, being factual and precise is not always the goal — let’s now look at when you should be factual, when you actually want the conversation to turn abstract, and when you know it is time to stop.

III/b. When to stop?

It is often mentioned that 5 is just a rule of thumb, and sometimes you can ask more “why”s. But that’s not too helpful in determining when to stop. Sadly, neither is Don Norman’s tip to “stop when people say I don’t know” — because saying “I don’t know” is a simple escape mechanism when answers get uncomfortable. Nor is it helpful to stop when answers stop producing useful responses — because it might not be apparent what is ‘useful’. And IDEO’s advice to “go deeper” is also not helpful — because what does “go deeper” really mean?

Luckily, the “iceberg model”, also called “levels of understanding” (page 8) helps you cut through this ambiguity. This is a systems thinking approach, that helps you dive below the surface, and states that everything should be looked at on 4 levels:

  1. events — “what happened?”
  2. trends — “does this event fit into a trend or pattern?”
  3. systemic structures — “what causes these trends and events to emerge?”
  4. mental models — “what assumptions, believes and values give rise to the structures?”

Sadly, most examples cited for the “5 Whys” technique stay at level 1, events. Until you have reached level 3, you cannot have arrived at a root cause. Especially not when human beings are involved. So here’s how to use this approach during the “5 whys” technique:

  • Consciously categorise the answers you receive from your respondent into one of the 4 levels. This helps you know where you are.
  • Be stubborn and do not stop until you have answers at least at level 3, but ideally at level 4.
  • If answers take you one level up, instead of down, that may mean you need to be open to new avenues of enquiry, and fork your questions to unearth multiple underlying causes.
  • Deliberately ask questions that take the conversation deeper. To go to level 2, ask things like “How often does this happen?”. To go to level 3, ask “Do you always follow this process?”. To go to level 4, ask “Do you agree with this process?”.
  • Don’t be afraid for the conversation to turn abstract. As mentioned above, being factual is not always the goal. Level 4 (mental models) is where things become less factual. But they also become more valuable, as the leverage of making change increases the further down you go. Responses at this level may describe mental models of an individual… but also of an organisation.

IV. An example

What better example to use than the one used by Toyota: a welding robot stopping in the middle of its operation. As you see below, their original example asks only “Why”, and stays at the 1st level, “events”:

  1. “Why did the robot stop?” — The circuit has overloaded, causing a fuse to blow.
  2. “Why is the circuit overloaded?” — There was insufficient lubrication on the bearings, so they locked up.
  3. “Why was there insufficient lubrication on the bearings?” — The oil pump on the robot is not circulating sufficient oil.
  4. “Why is the pump not circulating sufficient oil?” — The pump intake is clogged with metal shavings.
  5. “Why is the intake clogged with metal shavings?” — Because there is no filter on the pump.

Let’s continue the above inquiry with our newly-gained knowledge:

  1. “How often do welding robots stop due to the problem of missing filters?” —More often than in the past. (level 2: patterns)
  2. Is there an automated process to monitor oil pump or filter health? — There is no automated process, we rely on random checks. (level 3: structures)
  3. Why do you believe the organisation omits automated monitoring? — The factory used to operate faultless, and I believe we grew complacent. (entering level 4: mental models)

Just 3 additional questions, strategically aimed at going to deeper levels in the iceberg model, reveals much more detail and depth to the original problem. Your ‘5 Whys’ have just gained superpowers!

In closing

So in short:

  • do not use “why” — it makes people defensive.
  • have a map of events-trends-structures-mindsets to understand if your questioning is going in the direction, and if it is time to stop.

Oh, and forget about “5 Whys” being simple — it is a combination of process engineering, psychology and systems thinking. Even with all the above information, we are just scratching its surface….

Thanks Arash Golnam and Eva Moorbeek, for knowingly or unknowingly inspiring me during our systems thinking courses at Design Dissolve.

Resources used: Design Dissolve, Philipp Bubenzer, IDEO, Forbes, Toyota, Interaction Design Foundation, Mindtools, Atlasian, Kanbanize, Buffer, Psycentral, Melbourne Child Psychology, Keith Webb,

--

--

--

Service Design & UX @ Whitespace / Human Centred Design @ Luzern University

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to run your first digital wellbeing design workshop

How early-stage founders can create a killer user experience (without hiring a UX designer)

Days of 3D | Vol. 1

Cincy TUG Shenanigans with the #DataFam + Michelle Frayman has our Viz of the Week

Patchwork and Putting Pieces Together

A Video Prototype

Why Industrial Design?

UX Case Study — Parisians and Museums.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Peter Horvath

Peter Horvath

Service Design & UX @ Whitespace / Human Centred Design @ Luzern University

More from Medium

Top 10 Reasons an External Facilitator Should Run your Design Sprint

Whither Service Design 2022

Human-centered design matters!

Beyond design thinking