UX promptly needed. Make it shine.

The real fix is never the one closest at hand.

Series Introduction: “UX promptly needed.” argues for where proper UX process is urgently missing — from public services to product testing. Each entry shows what applying it correctly would actually look like.

Imagine a product team burn three sprints making a broken feature look better — new icons, smoother animation, a fresh coat of color on a button nobody was clicking. Engagement never moved. The button was never the problem; something underneath it was broken, and nobody had gone looking. Shine, applied to the wrong layer, is just expensive camouflage.

Canva AI + Krystian M. Frahn

In this article:

• Why the closest, easiest-to-ship fix is usually the wrong one

• What changes when the Five Whys gets aimed at a person instead of a mechanical fault

• Why “the user made a mistake” is a discipline’s line in the sand, not its finish line

• Why root-cause work needs more than one set of eyes — including the eyes of whoever built the thing

• Why “shine” is a downstream effect of the right cause, not something applied afterward

Written by Krystian M. Frahn, AIinUX framework creator | 5 custom made Anthropic Claude skills in a row used by the author for the research and article creation

The Closest Fix Is Rarely the Real One

A team assumes users need a faster checkout. The real issue, once anyone looks past the symptom, is unclear product information that causes cart abandonment before checkout is even reached — the person left before they got to the register, as UX Design Institute’s research points out.

Solving the root problem is a first-order discipline in this field, not a nice-to-have layered on afterward — Don Norman named it as one of human-centred design’s founding principles, alongside focusing on human needs and thinking in systems. Torrens University’s account of the field shows the pattern that follows when it’s ignored: design flaws recur because teams keep intervening on the symptom, not the mechanism producing it. The closest fix is the one that’s easiest to ship, which is exactly why it’s rarely the right one.

That’s the whole tension this piece sits inside. Shine polishes what’s already been found; it can’t substitute for finding it.

Asking “Why” Five Times, Aimed at a Person Instead of a Pump

The Five Whys was built at Toyota to chase mechanical failure: a blown fuse traced back to a worn bearing, back to a missing strainer. Sakichi Toyoda built it in the 1930s; Taiichi Ohno called it the basis of Toyota’s scientific approach.

UX research redirected the same chain at motivation instead of machinery. Joseph Mok’s account shows repeated “whys” surfacing the deeper need behind a stated problem, not just its symptom. Rajesh Ghodke pairs it with interviews and usability testing, so investigators don’t settle for the first plausible answer.

But I’d push back on treating that transplant as clean. A bearing either is worn or it isn’t. A person’s motivation takes longer to settle and can’t be rushed to a tidy answer — you’re reading for feeling, not measurement, and that costs time the mechanical version never charged.

That patience is exactly what collapses the moment “the user made a mistake” gets accepted as the finish line.

The Discipline That Refuses to Stop at “The User Made a Mistake”

A fighter jet’s crashes were blamed on pilot error for years. Sneha Mukherjee’s analysis of the case shows investigators eventually pushing past that verdict to the actual cause: cockpit hypoxia, from a faulty ventilation system nobody had questioned.

There is no assumption that the user is always right. Just don’t be satisfied with blaming him — always ask whether there’s an underlying cause.

That’s not an excuse for the user. It’s a refusal to let blame be the place inquiry stops.

Most design conversations I sit in reach for the user’s mistake first, because it’s the fastest exit from the room — the meeting ends, the ticket closes, everyone moves on. The discipline is staying in the room one question longer, past the point where blame would have let everybody off the hook.

Why the Root-Cause Search Needs More Than One Set of Eyes

The person closest to a product is often the worst-placed to find what’s actually wrong with it — too invested in their own version of the story to see past it. A UX Planet account of chasing chronic wrist pain past the obvious fix, a wrist support, to its real cause, sitting posture, only worked because the investigator was willing to keep questioning their own first answer.

That’s why HCD — or UX design in general — tends to be team work, where the UX designer leads, but hears others. If the person who built the feature is also the only person deciding whether the feature is the problem, whose blind spot are we actually testing?

The team isn’t there to slow the designer down, and it isn’t there to overrule them either. It’s there to catch the cause the designer is too close to see — the blind spot that comes from having built the thing in question.

That team I watched, animating a button nobody clicked, never got past their own instinct to make it look better. No root cause, no second set of eyes, no chain of whys run to the end. Just shine, chasing a symptom in circles.

Design is about design. Execution is a matter for CEOs and scrum masters — which means a beautifully built feature can still be a failure, decided before a single pixel shipped, no matter how well the build itself goes afterward.

The shine everyone chases at the end is not something you apply on top of a product once the deadline arrives. It is what is left over, almost incidentally, once the actual cause — not the closest one, not the most comfortable one — finally got found and fixed.

What’s the button you’re polishing right now — and have you actually asked why anyone would press it?

Krystian M. Frahn is a UX designer and researcher, supporting Human-Centered Design and exercising the use of AI in the process, creator of AIinUX design framework | linktr.ee/aiinuxdesign

Dictionary

Root Cause Analysis (RCA)

A method of tracing a problem back past its visible symptom to the first event or condition that actually produced it. It exists to stop teams from treating the symptom itself as the target for a fix.

Five Whys

A root-cause technique developed at Toyota in the 1930s — asking “why” repeatedly, typically five times, until the chain terminates in something systemic and fixable. In UX, the same chain is redirected at a person’s underlying motivation rather than a mechanical fault.

Human-Centered Design (HCD)

A problem-solving approach that keeps the real needs and lived experience of the people affected at the center of every decision. Applied to causal analysis, it insists the chain of “why” must end in a genuine human need — never in blaming the person for a design’s shortcomings.

Read more:

Gorichanaz, T. (2025, April). Identifying the barriers to human-centered design in the workplace: Perspectives from UX professionals. Proceedings of the ACM on Human-Computer Interaction, 9(2), Article CSCW110. doi.org/10.1145/3711008

Mukherjee, S. (2018, April 14). The problem area of any UX project should start from root cause analysis. Medium. medium.com/@sneha11.mukherjee/the-problem-area-of-any-ux-project-should-start-from-root-cause-analysis-dd5178a407c5

Mok, J. (2024, May 22). Uncovering user needs with the Five Whys technique. UX Primer. articles.ux-primer.com/uncovering-user-needs-with-the-five-whys-technique-ef5c938d76da

AIinUXdesign HCD RootCauseAnalysis UXResearch NNGroup UX

Date: 2026–07–20 | Author: Krystian M. Frahn

AIinUX: linktr.ee/aiinuxdesign