2026-03 · 4 min read
Decisions without perfect knowledge
Enterprise users are often described as experts. In reality, most of them spend their day navigating uncertainty. That changes what design is for.
Enterprise software is often designed as if people know exactly what they need to do.
Most of the time, they don't.
Policies change. Processes evolve. Exceptions appear. The case in front of someone is rarely identical to the one described in training material — and the training material is rarely current.
What we call expertise is often something much less certain. Not perfect knowledge. Pattern recognition under uncertainty. The "expert" is usually the person who has seen enough situations to make a reasonable decision when the rules no longer fully apply. Which, in practice, is most situations.
The best enterprise products are not the ones that assume perfect knowledge. They are the ones that help people make good decisions when perfect knowledge is unavailable.
One of the patterns I keep encountering is that users are usually better at describing symptoms than causes.
A claims handler might say that a screen feels frustrating. Press once, and they point to a button. Press twice, and the button turns out to be perfectly fine. The real issue is that a field further up the form forces them to commit to a categorization before they have enough information to make that decision confidently.
The button was the symptom. The premature commitment was the cause.
Design starts with that distinction. The form is not frustrating because of its layout — the layout is often just where a deeper problem becomes visible. A workflow might feel cumbersome because it encodes a policy that no longer reflects how the organization operates. A dashboard might feel confusing because it answers a question the team stopped asking two reorganizations ago.
The screen is where the problem surfaces. The work is understanding where it originates.
This is why fixing the screen is rarely the right scope.
Good interfaces enable action. Good systems enable judgment. Those are different jobs.
An interface that says "Click here to escalate" communicates that an action is available. A system that explains why escalation is appropriate, what happens next, and how the case will change afterward helps someone decide whether escalation is actually the right thing to do.
The first scales functionality. The second builds capability.
Enterprise software is generally much better at the first than the second. There are understandable reasons for that. Interfaces are easier to measure than understanding. Clicks are easier to count than confidence. Design teams are usually responsible for screens, not decision quality.
The cost appears later — usually when someone encounters a situation the workflow did not anticipate and discovers they have no mental model to fall back on.
The work I find most rewarding sits precisely in that space. Not simplifying decisions. Improving the conditions under which decisions are made.
The most valuable design artifact is often not a screen. It is shared understanding.
A team that agrees on what a case represents, what users are actually trying to achieve, and where a process genuinely breaks down can produce dozens of good interfaces. A team that disagrees about those fundamentals can produce dozens of polished screens and still fail to solve the underlying problem.
Most of my work involves translating between different perspectives on the same situation: users, business stakeholders, engineers, and increasingly, intelligent systems. Each sees only part of the picture. The leverage rarely comes from choosing the right interface pattern. It comes from creating enough shared understanding that these perspectives become legible to one another. The screen is often downstream of that work.
Over time, I've come to think of Enterprise UX as the design of decision-making conditions — the conditions under which someone without perfect knowledge can still arrive at a reasonable answer, given the information available, the time available, and the consequences they will ultimately have to live with.
That framing has changed how I approach projects. The question is no longer "What does this screen need to show?" The question is: "What does this person need to understand about their situation in order to act with confidence?"
The most valuable design outcome is rarely a cleaner interface. It is a person who understands their situation well enough to make a better decision.
Once that condition exists, the interface becomes surprisingly easy to design.