Fishbone Diagram Template for User Research

A fishbone diagram maps the breadth of potential causes across categories. [Five Whys](/templates/five-whys-template) follows a single cause in depth. Use a fishbone diagram first to identify which causes are most likely, then use Five Whys to drill into the top-priority cause. Think of fishbone as the wide-angle lens and Five Whys as the zoom lens.

That is normal. A well-facilitated fishbone session produces 15-30 potential causes. The prioritization step is where you narrow the field. Rank causes by evidence strength and likely impact, then investigate the top 3-5. The rest stay on the diagram as hypotheses for future investigation if the top causes do not explain the problem.

Yes. The categories should match your problem space. For a customer churn investigation, you might use: Onboarding, Product Value, Support Experience, Pricing, Competition, and Timing. For a quality issue, traditional manufacturing categories (Materials, Methods, Machines, Measurement, Manpower, Environment) may work better.

No. A fishbone diagram is best for complex problems with multiple potential causes. For simple, well-understood problems, go straight to [Five Whys](/templates/five-whys-template) or a quick [problem statement](/glossary/problem-statement) and experiment. The overhead of assembling a cross-functional group for a fishbone exercise is only justified when the cause is genuinely ambiguous.

Frame causes as system descriptions, not personal failures. "No regression testing before the nav change" is a process cause. "The QA engineer did not test the nav change" is blame. When someone proposes a people-focused cause, rephrase it as a process or system gap: "Why was it possible to ship without regression testing?" The [Five Whys](/templates/five-whys-template) technique is useful here for redirecting from people to processes. ---