We often talk about broken UX as an inconvenience. A confusing form wastes a few minutes. A badly designed workflow creates frustration. A failed save means we have to do something twice. These are real problems, but they are not the whole story. The cotitst of UX failure changes as software becomes more capable and as we delegate more of our work to it.
Thirty years ago, using software often required a reasonable understanding of the technology underneath it. If you were working at a Unix or DOS prompt, you had to know what you wanted the computer to do and what to type to make it happen. You also had some understanding of the system because you could not get very far without it.
Then software became more accessible. WYSIWYG interfaces removed the need to understand commands. Automation removed the need to repeat many tasks ourselves. Software began generating software. And now AI allows people to accomplish increasingly sophisticated things without necessarily understanding the technology that makes them possible.
The more we delegate to software, the less we need to understand how it works. That is one of the great achievements of good UX. But it also means that when something goes wrong, the user has less ability to diagnose and recover from the failure.
This is the paradox I find increasingly interesting. Better software allows more people to use it, for more important things, without needing technical expertise. That makes software enormously more useful. But it also increases our dependence on the experience being designed well when something doesn't go according to plan.
When a payment isn't just a payment
Imagine you are in sales and your phone is essential to your work. You depend on it to speak to customers, receive calls and conduct your business. Your monthly phone bill is on automatic payment, so there is nothing to remember and nothing to do. The software takes care of it.
Now imagine that the payment doesn't go through.
You may not discover the problem immediately. Eventually, your phone is disconnected. Suddenly, what looked like a small financial transaction failure has become a business problem. You cannot simply continue working while you investigate. You have to find out whether the payment was attempted, whether the money left your account, whether the phone company received it, and what you need to do to restore service.
What started as a failure in a payment system has now affected your ability to earn a living.
The financial transaction was only one link in a much larger chain of dependency. The UX failure occurred in one place, but its consequences appeared somewhere else.
The cost of a UX failure is not always the cost of the thing that failed. Sometimes it is the cost of everything that depends on it.
Consider the same problem at organisational scale. A company with 2,000 employees depends on its payroll system. Something goes wrong and salaries do not arrive when expected. Perhaps the company's account shows that the money has gone, while employees' accounts do not show the corresponding credit. The money is somewhere in the system, but neither the company nor the employees can confidently determine what has happened.
For the organisation, this is no longer a payroll interface problem. Employees still need to be paid. The company may have to find money elsewhere to meet that obligation. People begin making calls, raising tickets, checking accounts and trying to understand a system that was designed precisely so they would not have to think about the underlying mechanics.
That is what makes financial UX particularly interesting. Money is one of the most legible forms of harm. We immediately understand what it means when money is missing, delayed, duplicated or stuck. But financial systems also sit underneath many other activities, so a failure can propagate well beyond the original transaction.
When the stakes become physical
Healthcare raises the stakes further. Here, software does not merely support a financial or administrative transaction. It can sit inside a workflow involving patients, clinicians, records, appointments, medication, diagnosis and treatment.
Imagine a clinician working under time pressure. A step in a digital workflow does not behave as expected. The system does not clearly indicate whether something has been saved, submitted or passed to the next stage. The clinician now has to determine what the system knows, what it does not know, and whether it is safe to continue.
The problem is not simply that the interface is inconvenient. The person using it may already be operating under significant pressure, and the person affected by the workflow may not be in a position to compensate for the software's failure.
This is where detectability and recoverability become as important as the failure itself. A system that fails clearly can often be dealt with. A system that fails ambiguously creates a different kind of problem because the user does not know what state they are in or what action is safe to take next.
The point is not that every healthcare interaction needs to be designed as if catastrophe is inevitable. It is that the consequences of uncertainty have to be considered as part of the experience. In a low-stakes application, uncertainty may cost a few minutes. In a critical workflow, the same UX pattern can have much greater consequences.
Then comes delegation
Agentic AI introduces a different kind of UX problem because the user is no longer necessarily performing the task at all. They are delegating it.
Imagine asking an AI colleague to handle something on your behalf. You describe the outcome you want, provide whatever context is necessary, and move on to another task. That is the promise of an agentic system: you do not need to operate every step yourself.
But now consider what happens if the agent fails.
You may not be watching when the work takes place. You may not know which decisions it made. You may not know which part of the task failed. And you may not even know that there was a failure until the consequence appears somewhere else.
That is fundamentally different from a traditional interface error. If a button doesn't work, you know something went wrong because you are standing there looking at the button. If an automated process fails, the system has an opportunity to tell you. But if an agent is working on your behalf while you are somewhere else, the experience has to account for your absence.
The better software becomes at making something invisible, the more disruptive it can be when that invisible thing fails.
This is why agentic AI deserves to be considered separately from traditional software automation. The question is no longer whether the interface makes the task easy. It is whether the system can establish enough trust around delegated work that the user knows what happened, what remains uncertain and what needs their attention.
I don't think we can yet know exactly how all of these failures will play out. Agentic systems are still evolving, and many of the most consequential failure modes have yet to become familiar. But that is precisely why they deserve attention now. We do not need to wait for a pattern of failures to become obvious before designing for it.
Four questions every critical workflow should answer
Thinking about broken UX only in terms of friction is no longer sufficient for software that people depend on. There are at least four questions worth asking when evaluating the consequences of failure.
- How severe is the consequence? A minor inconvenience and a disrupted livelihood are not equivalent failures.
- How detectable is the failure? Does the user know immediately that something has gone wrong, or could the problem remain invisible?
- How recoverable is it? Can the user understand what happened and take the appropriate corrective action?
- What is the blast radius? Is one person affected, or are there hundreds, thousands or multiple dependent systems downstream?
These questions also change how we think about good UX. The goal cannot be to eliminate every possible failure. Complex systems will fail. Networks will fail. Payments will be delayed. Data will become inconsistent. AI agents will misunderstand instructions. What matters is what the experience does when those things happen.
A good system makes consequential failure visible. It communicates uncertainty instead of hiding it. It gives the user enough information to understand what happened and enough control to recover where recovery is possible.
And perhaps most importantly, it does not assume that the user can simply look underneath the interface and figure things out. We deliberately designed modern software so that they wouldn't have to.
The responsibility that comes with better software
We can't and shouldn't go back to the command line. We should not expect people to become more technical simply because the systems they use have become more complex. Quite the opposite. The ability to hide complexity from users is one of the most valuable things good design can do.
But there is a responsibility that comes with that abstraction. When users no longer need to understand the machinery, the product has to take more responsibility for communicating when the machinery doesn't behave as expected.
The trajectory of software has been toward greater capability and less visible complexity. That has expanded who can use technology and what they can accomplish with it. The next generation of systems will take that delegation even further.
So perhaps the question we should ask when designing the next generation of software isn't only, “How easy can we make this?”
It is also, “What happens when the person using it has no idea how it works—and it fails?”
That is where UX stops being about making software pleasant to use and becomes something more fundamental: making complex systems understandable and recoverable when they inevitably go wrong.
