A confirmation modal appears on screen. The user accidentally clicks "Delete Account". This happens fourteen times before anyone notices. The code works exactly as written. Tests pass. The designer approved the component. The ticket was closed as "Done".
This is the kind of failure that causes the most damage and shows up least in quality reports: the broken experience that no review system was built to catch. It's not a bug. It's something worse — a decision nobody questioned because it was technically correct.
The question that should haunt every product team isn't "does it work?" but "what does the user feel while using it?" That question, uncomfortable and hard to operationalize, is precisely the one most teams avoid.
Code can be impeccable while the experience is actively harmful to users.
Tickets describe behaviours, not emotions or downstream consequences.
Experience quality isn't validated in the sprint review — it's validated in the real world.
The Ticket: A Tool That Measures What It Can, Not What Matters
Task management systems — Jira, Linear, GitHub Issues, whatever you use — are excellent at tracking expected behaviours. "The button should submit the form when the field is filled." "The animation should last 200ms." "The error state should display the right message." All of that is verifiable, automatable, closeable.
But there's an entire category of problems these systems cannot formulate. Not because they're bad tools, but because their underlying mental model is engineering's: correct vs. incorrect, pass vs. fail. User experience operates in a different dimension — trust, anxiety, perceived friction, sense of control. None of that fits in a ticket description field.
The result is a dangerous asymmetry. Teams become very good at solving the problems they can articulate and systematically blind to those they can't. An onboarding flow can pass every QA review, comply with design guidelines, produce zero console errors, and still generate a 60% drop-off rate because at some point the user senses something is off, feels uncertain about what will happen next, or finds that the product's promise doesn't match what's in front of them.
A ticket describes what the product does. Experience is what the user feels while doing it. Conflating the two is the source of products that "work" but that nobody wants to use.
This connects directly to a pattern we've explored before when discussing UX improvements that optimise the wrong things: teams can be measuring and iterating on the wrong metrics while the real experience quietly deteriorates.
Invisible Friction: Three Places Where Experience Breaks Without Breaking
There are three recurring patterns worth naming specifically — places where these silent failures appear most consistently.
Destructive actions without emotional weight
The confirmation modal example is a perfect illustration. Designing a dialog for deleting an account, wiping data, or cancelling a subscription isn't just a component problem — it's a problem of designing for consequences. How much friction is appropriate? What language conveys gravity without being condescending? Where does the destructive button go to minimise accidental clicks without hiding it from users who genuinely want to proceed?
These questions don't have answers in a style guide. They have answers in the real behaviour of real users. Without that data, teams tend to solve the technical problem (the modal appears, the button works) and ignore the experiential one (the action doesn't carry the weight it should).
Intermediate states that communicate nothing
Loading. Processing. Saving. The blank screen that lasts two seconds between an action and its result. These intermediate states are where user trust is most often lost, and they're also where design attention is most often absent. The ticket says "show a spinner during loading". The spinner appears. Ticket closed.
But the ticket doesn't ask: does the user know what's actually happening? Do they know how long it will take? Do they know their action was registered and the system is responding, not frozen? Poorly designed loading states generate a disproportionate amount of anxiety and unnecessary support volume — not because they fail, but because they don't communicate.
Flows that assume context the user doesn't have
This is perhaps the hardest to detect from inside the team. The team knows the product so well that certain things feel obvious. The user arrives without that context and at some point finds themselves facing a decision they don't know how to make — not because the interface is wrong, but because they don't have the information needed to move forward with confidence.
Initial setup flows, integration processes, permissions screens: these are recurring sites for this pattern. The code is correct. The design is clean. The user is stuck.
Experiential QA: What It Means to Test What Can't Be Automated
The problem is identified. The practical question is: how do you catch this before it reaches production?
There's no single answer, but teams that do this well share one counterintuitive starting point: accepting that part of experiential quality can only be validated with real people, and building the process accordingly. That doesn't mean elaborate usability studies for every feature — that would kill delivery pace. It means lightweight, regular mechanisms for real observation.
Five users watching a new flow before launch isn't rigorous research. It's enough to catch the big problems. The problems that make fourteen people delete their account by accident.
The three-question protocol before closing a ticket
In product audits, we recommend adding three questions to the acceptance criteria of any feature that touches a critical user flow:
What is the user feeling at each step of this flow? Not what they're doing — what they're feeling. Confidence, doubt, urgency, confusion. If the team can't answer this, it's a sign the flow hasn't been designed with enough emotional resolution.
What happens when the user makes the most likely mistake? Identify what that mistake is and explicitly design the recovery experience — not as a technical error case, but as a path back: does the user know what went wrong? Do they know how to recover?
What information does the user need that we're not giving them? Review the flow from the perspective of someone arriving without context. Are there decisions being asked of users who don't have the elements to make them? Are there steps where the system's state is opaque?
These three questions don't replace user research — a subject we've written about in depth — but they do raise the bar for what a team considers finished.
The Root Problem: When Product Gets Optimised for the Sprint, Not the User
There's a systemic mechanism underneath all of this that's worth naming directly. Product teams work under delivery pressure. Sprints have deadlines. Tickets have acceptance criteria. Success is measured in features shipped, velocity, test coverage. Every management mechanism points toward a definition of quality that is technical and quantifiable.
User experience, meanwhile, is qualitative, cumulative, and hard to attribute to a specific task. Nobody closes a ticket that says "the user feels the product is reliable." But that sense of reliability — or its absence — is precisely what determines whether someone keeps using the product or not.
What happens is an inadvertent optimisation toward the measurable. And the measurable, in most teams, doesn't include "how did the user feel using this." Over time, the result is a product that accumulates experiential debt the same way it accumulates technical debt: silently, until the cost of paying it back exceeds what the team can afford.
Technical debt shows up in the logs. Experiential debt shows up in churn. And by the time it shows up in churn, it's too late to treat it as a design problem.
This problem is especially acute when code generation or design tools — AI or otherwise — are part of the workflow. These tools are very good at solving what they're asked and completely blind to what they're not asked. Generated code can be technically impeccable and experientially hollow, because nobody asked "what should the user feel here?" As we explored in the post about AI features that nobody actually asked for, the problem isn't the tool — it's who defines what gets built and with what quality criteria.
The solution isn't to slow down or add layers of process. It's to broaden the definition of "done." A flow is done when it works technically and when it has been verified — even lightly — that it doesn't erode trust, doesn't generate confusion at critical points, and that consequential actions carry the weight they deserve.
That doesn't require a bigger team. It requires a different way of thinking about what it means for something to be well made.
If your team closes tickets as "Done" and churn remains a mystery, you're probably measuring half of what matters. At Room 714 we run product audits that start exactly here — not with whether the code works, but with whether the experience is built to generate trust or quietly destroy it. If that sounds familiar, the conversation is a short one.
