Enterprise Software
When listening to users leads you astray
"I work on paths."
It was not the answer I expected.
I had asked people to organize themselves by profession.
No one said, "I'm a transport engineer." No one said, "I'm on the RAN engineering team."
Instead, they described themselves using the objects inside our software.
I was leading the complete redesign of a large enterprise application.
The product had been built years earlier around a traditional, screen-oriented interface. We weren’t simply modernizing the technology. We were rethinking, from the ground up, how enterprise software should guide people through their work.
Instead of exposing database objects and expecting people to navigate between them, we wanted software that led them through complete tasks. Workflows. Automation. Visualization. A framework our customers could extend without having to rewrite the product.
Before committing to the design, we spent three days with one of our largest customers.
The plan was simple. Observe experienced users. Understand how they actually did their jobs. Then design the product around real work instead of our assumptions.
The workshop was carefully planned. Multiple UX facilitators. Breakout sessions. Well-defined agendas. Everything a textbook research exercise should have.
Which is why those introductions unsettled me. People identified themselves by the objects inside our software, not by the engineering work they were there to do. It was subtle. But it didn’t feel right, and I couldn’t quite explain why.
By the second day, the UX team came back energized. They had pages of suggestions. Users wanted buttons moved. Fields reorganized. Navigation simplified. More shortcuts. By every normal measure, it looked like a successful piece of research.
Except something still bothered me.
So I asked to sit directly with the users myself. And I stopped asking them how they used our software. Instead, I asked a different question.
“What are you actually trying to accomplish?”
The answers surprised me.
Many of them couldn’t really describe the engineering work itself. Instead, they described which fields they copied. Which screens they visited. Which buttons they clicked, and in what order.
Their expertise had become the software.
Somewhere over the years, they had unconsciously stopped thinking like transport engineers. They had become experts at operating our application instead.
That realization completely changed how I thought about product management.
The UX team hadn’t failed. The users hadn’t given bad feedback. Everyone had done exactly what they were supposed to do.
The mistake was mine.
I had assumed that experienced users naturally understood the business process. In reality, they had adapted themselves to the software we’d given them. Their suggestions optimized the tool they already had — not the engineering work they were actually there to perform.
From that point forward, our design philosophy changed. Instead of asking, “How should this screen work?” we started asking, “What job is this person trying to complete?”
The software became task-oriented rather than screen-oriented. And it was better for it.
The lesson has stayed with me ever since. Whenever someone tells me, “Our users want…”, my next question is always the same: “What are they actually trying to accomplish?”
Users can become experts in the software they were given. That does not mean the software still reflects the work the business needs them to do.
Before investing in what users are asking for, make sure they are describing the underlying work — not merely the system they have learned to operate.