What is a 5 Whys template?

It is a template that helps you get from a symptom to the root cause by asking 'why?' until the real problem surfaces. You state a problem, then keep asking why each answer happens until you reach something you can actually fix.

How many times do you ask why in the 5 Whys?

Usually about five times, but five is a guideline, not a rule. Sometimes it is three, sometimes seven.

When should you run a second chain in the 5 Whys?

Run a second chain when a 'why' has more than one honest answer. Real problems often have more than one root.

5 Whys Template (With an Example)

A 5 Whys template helps you get from a symptom to the root cause by asking “why?” until the real problem surfaces. It’s deceptively simple: you state a problem, then ask why it happens, then why that happens, and so on — usually about five times — until you reach something you can actually fix.

Why it works: teams love to fix symptoms because symptoms are visible. The 5 Whys forces you past the obvious and down to the cause that, if solved, makes the symptom disappear for good.

The fill-in structure

Start with a clear problem statement, then build the chain:

Problem: [the symptom you observed]

Why? → [answer 1] Why? → [answer 2] Why? → [answer 3] Why? → [answer 4] Why? → [root cause]

Keep a notes column beside the chain for evidence or branches. If a “why” has more than one honest answer, run a second chain — real problems often have more than one root.

How to use it

State the problem in the user’s terms, not the solution’s. “Users abandon checkout,” not “we need a new button.”
Answer with evidence, not opinion. Each “why” should be something you can support, not a guess.
Stop when you hit something actionable. Five is a guideline, not a rule — sometimes it’s three, sometimes seven.
Watch for branches. If two causes are real, map both.

A worked example

Using the pain point from our journey map example:

Problem: Maya calls the bank just to find out whether a client has paid.

Why? → She can’t tell from the app whether money has arrived. Why? → The app has no clear, timely signal when a deposit lands. Why? → Deposits are only visible by digging into the transaction list. Why? → The product treats all transactions equally — nothing flags an incoming payment. Why? → No one designed for the “did I get paid?” moment, which is the freelancer’s most anxious question.

The root cause isn’t “the app is confusing.” It’s that a specific, high-anxiety moment was never designed for. That points straight to a fix — a deposit notification — and it makes a far stronger case study than “I redesigned the dashboard.”

What to use before and after

Before: a customer journey map surfaces the symptom worth investigating.
After: turn the root cause into an opportunity with a How Might We.

For how root-cause thinking becomes part of a portfolio story, see the UX case study guide.

Showing you found the root cause — not just a symptom — is what makes a case study credible. Folioverse helps you turn that thinking into a case study recruiters trust. Try it free.