Uncover the root cause of recurring problems by iteratively questioning surface-level symptoms and assumptions.
The 5 Whys is a root cause analysis technique that drills past surface symptoms by asking "Why?" repeatedly to uncover the true underlying problem.
The 5 Whys is a root cause analysis technique originally developed within the Toyota Production System. It works by repeatedly asking "Why?" in response to a problem statement, peeling back layers of symptoms until the fundamental cause is revealed. UX researchers, product managers, and design teams use it when a fix has already been attempted and failed, signaling that the real problem has not been correctly identified. The method requires no special tools or training, making it accessible to teams of any size or experience level. A facilitator presents the problem, and the group collaboratively answers each successive Why, grounding every response in evidence rather than assumption. The power of the 5 Whys lies in its simplicity: by enforcing structured questioning, it prevents teams from jumping to solutions prematurely. It is most effective when combined with data from analytics, user feedback, or observation, ensuring that each answer in the chain is factually supported rather than speculative.
The first step in the '5 Whys' method is to identify the problem or issue that needs to be solved. This involves discussing with your team or stakeholders the symptoms and impacts of the problem to ensure everyone is on the same page.
Once the problem has been identified, ask the first 'Why' question. This question should focus on understanding the root cause of the problem. For example, if the issue is that users are not finding a specific feature on your website, the first 'Why' could be: 'Why are users not finding the feature?'
After asking the first 'Why,' analyze the answer provided by the team or stakeholders. This may involve gathering data, user feedback, or conducting further research to validate the given response.
Based on the analysis of the first answer, ask the next 'Why' question. This process is repeated until you have asked a total of five 'Why' questions. Each subsequent 'Why' should delve deeper into the root cause, helping you peel back the layers and identify the underlying issue.
After asking the fifth 'Why,' the final answer should reveal the root cause of the problem. At this point, you should have a clearer understanding of what is causing the issue and can begin brainstorming solutions to address it.
With the root cause identified, work with your team to develop and implement solutions that address the problem. Monitor the results of these changes to ensure they are effective in solving the issue and improving the user experience.
Lastly, review the entire process and the solutions implemented. Assess the effectiveness of the '5 Whys' method in identifying the root cause and solving the problem. If needed, iterate on the process and solutions, continually seeking to improve the user experience.
After completing a 5 Whys session, the team will have a clearly documented causal chain linking an observable problem to its root cause. This chain provides a shared understanding of why the problem exists and creates alignment on what needs to change. The primary deliverable is an actionable root cause statement accompanied by one or more proposed countermeasures. Teams typically leave the session with a prioritized action plan that targets structural fixes rather than quick patches. Over time, repeated use of the 5 Whys builds a culture of deeper inquiry, reducing the likelihood that teams invest effort in solutions that only address symptoms.
Be precise and specific when answering each Why, grounding responses in facts and observable evidence rather than opinions.
Write the entire chain on a physical board or flipchart so all participants can see the progression and spot logical gaps.
If the root cause remains unclear after five Whys, continue asking until the team reaches a structural or systemic cause.
Avoid assigning blame to individuals; focus on processes, systems, and design decisions that contributed to the problem.
Validate each answer before moving to the next Why by asking the team whether the stated cause actually explains the symptom.
Run parallel chains when a single Why has multiple valid answers to avoid oversimplifying complex problems.
Involve people closest to the problem, not just managers, to ensure answers reflect ground-level reality.
Document the final root cause and proposed countermeasures so the analysis leads to concrete action.
Teams often stop asking Why too early, settling on an intermediate cause rather than the true root. Keep asking until you reach a structural or systemic factor that can be addressed.
Responses like "poor communication" or "lack of resources" are too broad to act on. Push for specific, evidence-based answers that point to concrete changes.
The method should target processes and systems, not people. When answers point to a person, redirect by asking why the system allowed the error to occur.
Some Whys have multiple valid answers. Exploring only one branch can lead to an incomplete understanding. Run parallel chains when answers diverge.
Each answer should be verified with data or evidence before proceeding to the next Why. Unvalidated assumptions can send the entire analysis in the wrong direction.
A concise definition of the observed issue or user pain point to be investigated.
A documented chain of Why questions and answers tracing symptoms to causes.
The core systemic problem(s) uncovered through the iterative questioning process.
Actionable countermeasures targeting the root cause to prevent recurrence.
A plan with owners, timelines, and resources for implementing solutions.
Post-implementation evaluation comparing before-and-after metrics and outcomes.
Documented lessons learned to refine future problem-solving efforts.