Why enterprise products fail their users
The problem isn't complexity - it's complexity that was never designed for.
Someone in this story is using a spreadsheet.
Not because the system is broken. Not because they don't know how to use it. Because the system was never built for what they actually need to do.
This happens more often than most product teams realize. And it costs more than anyone is tracking.
But to understand why, it helps to go back further than enterprise software. It helps to go back to the beginning.
I remember the first time I used a computer.
Every simple action required knowing something - a sequence, a shortcut, an invisible rule. If you didn't know it, you found the person in the room who "understood computers." That person was never a designer. The difficulty was just assumed to be part of the deal.
That was the implicit contract: technology is complex, and learning to use it is your problem.
Decades later, most people still operate under a version of that contract. They tolerate friction they shouldn't have to tolerate. They learn workarounds they shouldn't have to learn. And most of them have no idea that there is an entire profession dedicated to the question of why any of this has to be hard in the first place.
That profession is UX design. And the reason it still has to argue for its existence inside product teams is the same reason those early computers came with no explanation: complexity has always been accepted as natural.
It isn't.
This acceptance of complexity doesn't disappear when software goes enterprise. It gets institutionalized.
The request came in as a user story.
Users need the ability to undo changes mid-flow.
It looked small. It looked obvious. The assumption was that this was a missing feature - one button, one interaction, problem solved.
It wasn't.
The undo wasn't the problem. It was a signal. And signals only tell you something is wrong - not what.
After interviews with the people actually using the system, a different picture emerged. These users were running financial scenarios - testing combinations of variables, trying to hit a fixed total without exceeding it. The system recorded outcomes. It had no way to support the process of getting there.
So they built their own system. On paper. Next to the screen.
This wasn't a workaround. It was the only way to do the job.
That image - paper next to screen - is not an edge case. It is one of the most consistent signals in enterprise software.
Nurses in inpatient settings spend an average of 22% of their shift interacting with electronic health record systems. Research published in the Journal of the American Medical Informatics Association identified three categories of workarounds nurses develop around EHR systems: omitting process steps, performing steps out of sequence, and creating unauthorized process steps. Not because nurses are careless. Because the systems were designed around data structure, not clinical workflow.
A study conducted in a Dutch hospital identified 11 distinct workarounds in a single internal medicine department - after the EHR system had been in use for two years. The system was functioning. People were working around it anyway.
In countries where there is no alternative - where a single system serves an entire profession with no competition and no replacement in sight - the problem becomes invisible through familiarity. People adapt. They learn the workarounds. They teach the workarounds to new colleagues. The system's limitations get absorbed into the job description.
The pattern is always the same: a system built to handle data ends up being used by people trying to do work. The gap between those two things is where the friction lives - quietly, persistently, for years.
The most expensive problems in enterprise software are the ones that never get reported.
There is no line item for "time spent compensating for the system." It doesn't appear in a sprint retrospective or a quarterly review. It shows up as longer working days, slower cycles, background noise. People adapt, and adaptation becomes invisible.
Each workaround carries a cost - in time, in errors, in cognitive load. Multiply that by the number of people doing it. Multiply that by years. The number is significant. It is almost never measured.
The most expensive problems in enterprise software are the ones that never get reported. People adapt, and adaptation becomes invisible.
This is what complexity without design produces. Not a crash. Not an error message. Just people spending part of every working day building bridges between what the system does and what they actually need to do.
Enterprise products don't fail their users all at once. They fail them gradually, as the product grows and the distance between what the system does and what people need to do gets wider.
It rarely starts as negligence. It starts as speed. A product is built to solve an immediate problem, under delivery pressure, with limited resources. Design - when it exists at all - focuses on the surface: the screens, the flows, the interactions. The deeper question - what is the actual work this person is trying to do, and does the system support that, or just record the outcome of it - often doesn't get asked until the product is already large.
By then, the architecture reflects decisions made without that question. Changing it is expensive. So the product grows around the gap instead of closing it.
Users adapt. The system ships new features. Nobody connects the two.
And nobody questions whether the difficulty was ever necessary in the first place - because difficulty has always felt natural. We learned that from the very beginning.
The spreadsheet on the desk next to the screen is not a user error.
It is information. It is telling you that the system supports recording, but not thinking. That it handles inputs, but not decisions. That somewhere between what the product was designed to do and what people actually need to do, there is a gap - and people are filling it themselves.
The question worth asking is not "how do we get users to stop using the spreadsheet." It is "what does the spreadsheet know that we don't."
Workarounds are not failure. They are the most honest feedback an enterprise product will ever receive - because they happen without anyone asking.
They happen because the work has to get done and the system isn't enough.
When you don't design for the work, people design around you.
They use spreadsheets. They write on paper. They build their own systems in the margins of yours. And they do it so consistently, so quietly, that it stops looking like a problem and starts looking like the job.
This has been true since the first computers. It does not have to stay true.
The spreadsheet on the desk next to the screen is not a user error. It is a design brief that nobody wrote.