The question of “why?” is as old as humanity itself. The quest to answer it has led us from creating tools out of sticks and stones to carrying miniature digital multi-tool computers in our pockets everywhere we go. It allows us to understand how these advancements came to be, while simultaneously looking to the future of purposeful innovations.
Anyone who’s been around children for any length of time can attest to their incessant curiosity. Every statement seems to be met with, “why?” Eventually, children grow out of this phase; whether it’s because they became less curious, or they were told enough times that things are just the way they are. But for many of us, “why?” remains a pertinent question in our everyday work. In today’s technological age of digital interfaces and experiences, it’s the single most important question we can ask.
Don’t get us wrong, asking “what?” is also important. It’s a solid starting point for any project and a critical tool for classification and understanding where a thing belongs within any given pattern—whether that pattern is a tool set or a society.
But there tends to be an over-focus on the “what.” Stakeholders are sometimes understandably reluctant to see their idea change, even if that change is in the best interests of delivering the right product that satisfies the identified need or problem. It’s the reason companies put time and resources into an app when what they really need is a stronger social media presence, or why they fill their site with PDFs (which have their place, but are inflexible and an accessibility nightmare) when some additional pages of well-organized content would tell the same story and provide a far better user experience In our quest for clarity and understanding, we should spend far more time asking “why?”
Fortunately, there’s a way to approach projects that helps us examine past challenges, as well as bring clear vision and intentionality to future projects. It’s a tried-and-true method called “root-cause analysis.”
How to Use RCA to Look Back
Root-Cause Analysis (RCA) is a problem-solving technique often used in manufacturing and engineering. Originally developed as “The Five Whys” by Sakichi Toyoda of Toyota Motor Corporation, and refined by Toyota Production System inventor Taiichi Ohno, the basic concept involves stating a problem and responding at least five times with the question, “why?” It encourages participants to push past surface symptoms in order to isolate the underlying root-cause. In fact, the Five Whys are so impactful that they are now a part of the Six Sigma curriculum.
Example:
You finish filling out your registration, tap the “Submit” button, and the app crashes, completely erasing all data and forcing you to start over. This is annoying enough if you’re a user. For developers, this is the ultimate nightmare.
The problem at hand is obvious: The app crashed as users tapped “Submit” on their registration. Where RCA picks up is in the asking of why did this happen?
Q: Why did the app crash?
A: Because it contained a bug.
Q: Why did it contain a bug?
A: Because it didn’t get caught in testing.
Q: Why didn’t it get caught in testing?
A: Because we didn’t test for that specific scenario.
Q: Why didn’t we test for that scenario?
A: Because we were running out of time and had to launch by X date.
Q: Why did we run out of time?
A: Because development took longer than expected.
Q: Why did development take longer than expected?
A: Because we underestimated/didn’t take XYZ into consideration/etc.
RCA can sometimes take a great deal of time, especially when trying to follow a myriad of threads and streams while piecing together what happened, or when data and evidence isn’t immediately available. It’s entirely possible that it takes fewer than five questions to get to the root issue, but these cases require the participants to double-check their conclusions and ensure that they’ve approached the issue honestly and openly.
How to Use RCA to Look Forward
This process should also be applied to the front-end of a project to help gain clarity for all parties involved, including project owners and/or stakeholders. In cases where a solution to a problem is brought forward instead of the problem alone, this process is an effective way to advocate for the design by helping to dig in further to pressure test or help discover the right solution.
Original Proposition: “We want to have an app.”
Q: “Why are we creating an app?”
A: “Because we’ve seen an increase in the bounce rate for our website.”
Q: “Why is there an increase in bounce rate for our website?” (An opportunity to examine strategy, do some user testing, and maybe involve the customer experience team if available)
A: “Because our pages take a long time to load.”
Q: “Why do the pages take a long time to load?” (An opportunity to look at website performance statistics)
A: “Because the images are large and we’re using transparent PNGs that are offset.”
Q: “Why are we using offset transparent PNGs?” (An opportunity to look for improvements within the processes and techniques within the creative/UX teams)
A: “Because our CMS requires us to write specific code in order to display this type of design properly.”
Q: “Why does our CMS require that?” (An opportunity to examine development and IT processes and techniques)
A: “Because it’s an older CMS that doesn’t support this new code framework.”
Q: “Why haven’t we upgraded to a more modern CMS?” (An opportunity to look at IT structures)
A: “Because it isn’t in our team’s fiscal or time budget.”
Possible Solution: “Then perhaps we can look at reallocating the budget for the app into upgrading our CMS and providing a better, faster, and more modern web experience for our users.”
The underlying beauty of RCA is that its usefulness is not limited to the corporate sector. You can apply RCA to any aspect of life and, provided you approach the problem-solving aspect with honesty and sincerity, you will be able to cut through the layers of fluff and excuses to identify the actual problem you’re trying to solve.
Asking “Why” is for Everyone
Everyone, at every level of the project, should . Each of us brings a unique perspective based on our experiences, our education, and our skill set, and these perspectives are what help any project to be well-rounded. UX designers understand how users interact with digital products and what makes the best experience. Developers understand the technical ramifications of bringing those designs to life. Researchers can analyze data and use it to inform KPI and other metrics. Writers can transform business goals and features into a compelling story and structure it in a way that maximizes the impact it has on readers. Each team member brings insight that will benefit the overall project. The key to unlocking that insight is being empowered to ask why.
Change is a constant in our world. Thanks to technology it often feels incredibly sudden. The ability to adapt to that change, to welcome it and see the inherent value and opportunity that it brings, is paramount for any organization that intends to last. The best way we can do that is to understand what brings the change about, and use that to formulate a plan for moving forward. If we apply root-cause analysis and the Five Whys, we stand the best chance of giving those plans the clarity they need to not only survive, but thrive well into the future.