Enterprise work has always been complex. Enterprise software doesn't always need to be. Yet the two are often treated as if they're the same thing.

After years of designing enterprise products for highly specialised domains, I've come to believe that we often use the same word — complex — to describe two very different things. The first is the complexity of the work itself. The second is the complexity introduced by the software. Only one of these is unavoidable.

Two kinds of complexity

Professionals working in enterprise environments solve inherently difficult problems every day. Geoscientists interpret uncertain subsurface data. Engineers evaluate technical trade-offs before making operational decisions. Analysts synthesise large volumes of information where accuracy matters far more than speed. Their work involves uncertainty, dependencies and judgement. That complexity belongs to the domain. Good software should respect it — not try to oversimplify it.

What doesn't belong to the domain is the effort spent navigating inconsistent workflows, searching for information scattered across multiple screens, remembering system-specific exceptions, or performing repetitive steps simply because the interface evolved that way over time. This is avoidable complexity.

The adaptable expert

One observation has stayed with me throughout my career: experienced users are remarkably adaptable. They learn complicated workflows. They memorise shortcuts. They create personal workarounds. They develop mental models that help them navigate systems that have grown over many years.

I remember working with a petrophysicist who had spent more than twenty years in the field. She was trying to answer what sounded like a simple question:

How do these wells compare?

To do that, she exported the data into her own spreadsheet — every single time — because the application couldn't present the values side by side. Taped beside her monitor was a handwritten list of the exact steps needed to get there. She didn't see it as a problem. It was simply how the work was done, and over the years she had taught the same routine to every new member of her team.

Enterprise products rarely become difficult overnight. Complexity accumulates gradually. New capabilities are added. Customer needs evolve. Regulations change. Different teams contribute to the product over many years. Every decision makes sense in isolation. Over time, however, those well-intentioned decisions can combine into an experience that demands more effort than the work itself.

This is what makes enterprise product design such an interesting challenge. The objective isn't to make sophisticated work appear simple. It's to ensure the software doesn't become another problem experts have to solve.

Every unnecessary click, context switch or workaround consumes attention. On its own, the impact seems insignificant. Across hundreds of users, repeated thousands of times over months and years, that cognitive overhead quietly becomes slower decisions, longer onboarding, inconsistent ways of working and reduced confidence in the product.

Good enterprise software doesn't reduce the number of decisions people make. It reduces the effort required to reach those decisions. The most valuable enterprise software doesn't make experts less expert — it allows them to spend their expertise where it creates the most value.

Fixing problems like this is rarely about designing a better screen. It means making the case — across product, engineering and domain experts — that a workaround people have quietly accepted for years deserves priority over the next new feature. That's often the real work of enterprise product design: not adding more, but deciding what deserves to be simplified.

When enterprise software removes unnecessary friction, experts can spend their expertise where it creates the most value. That's what great enterprise UX is really about. Not software that hides complexity. Software that refuses to add to it.

A reservoir engineer isn't hired because they know where data lives. They're hired because they know what it means.

Give one a set of well logs and they can tell you, often in minutes, which zones are worth a second look and which aren't. That judgment is the product of years — formations studied, mistakes made, patterns learned. It's the reason they're in the room.

So it's worth asking how much of their day actually calls on it.

Consider a familiar morning. An engineer needs to compare a handful of wells — a question their expertise can answer almost at a glance. But the data doesn't sit in one place. Some of it is in the interpretation software. Some is in a spreadsheet a colleague sent last week. Some lives in a system that exports, reluctantly, to a format that needs cleaning before it can be used.

So the morning goes to finding, exporting, reconciling and lining things up — until, sometime after lunch, the comparison finally sits on one screen and the real work begins.

None of the hours before that required a reservoir engineer.

Two kinds of work

Not all of an expert's day needs their expertise. Some of it does — reading the formation, weighing the risk, making the call. And some of it is simply the cost of assembling what they need before they can begin: finding the file, switching the tool, rebuilding a picture the software handed over in pieces.

The first kind is why they were hired. The second is why they're slow.

What the best products actually do

It's tempting to solve this with more intelligence — features that suggest, predict, or decide on the expert's behalf. But the engineer in our story didn't need a smarter tool. They needed the comparison in front of them, so the expertise they already had could go to work.

They do it by removing what stands between the expert and their own judgment — the export, the reconciliation, the fifth place the data was hiding. Not by adding knowledge, but by clearing the path to the knowledge that's already there.

Every roadmap I've worked on was longer than the year that had to hold it. There were always more good ideas than time to build them. The hard part was never generating options — it was deciding which ones deserved the team's attention, and which were quietly better left unbuilt.

We tend to measure design by what appears on the screen: the layout, the flow, the moment something finally feels obvious. That work matters.

But there's another kind of contribution that happens before anything is drawn. It's the judgment about which problem is actually worth solving. I've come to believe that's what separates a designer who ships work from a designer who shapes the business.

Five teams, five requests, one real problem

In one enterprise product I worked on, five different teams were asking for what looked, at first, like five different capabilities. Each wanted the tool to work a little more like the way they already worked. On paper, the job was clear: build a better version that satisfied all five.

But the five teams were all estimating the same project — and each did it in their own tool. Five tools, five spreadsheets, five different numbers, with a $7M spread between the lowest estimate and the highest. Early, high-consequence decisions — including what to promise a client — were being made on numbers nobody fully trusted. And the tool meant to bring those numbers together had, over time, become one more form to fill in.

So I stopped treating the five requests as requirements and started treating them as symptoms. Underneath all of them was a single, shared problem: no two teams trusted the same number. And that is not something another estimation feature can fix.

The obvious solution wasn't the valuable one

The obvious move — build the tool they'd asked for, only better — would have shipped, demoed well, and changed almost nothing. The valuable move was smaller and harder to sell: reframe the product from a place where people entered estimates into a place where they aligned on them. Estimation became alignment. Assumptions became visible. Scenarios became comparable.

The most useful thing I did on that project was help the team not build the tool they had asked for.

What the job actually is

A designer's job starts before the interface. It's to help the organisation understand which problem is worth solving in the first place. Deciding what not to build is a design act — because the cost of solving the wrong problem is far greater than the cost of getting a screen wrong.

The product happened to be an energy platform, but the question is universal: which problem actually deserves the team's next quarter?

The real deliverable

Senior design, more than anything, is about creating clarity around investment decisions — where a team's time should go, and where it shouldn't. A beautiful feature nobody needed still cost a quarter. A plain decision that resolved the right disagreement can change how an organisation works.