Why enterprise UX fails

The standard explanation for bad enterprise software is that users have no choice, so quality does not matter. It is a comfortable story and it is mostly wrong: plenty of enterprise products are excellent, and plenty of consumer products with enormous choice are dreadful.

The real causes are structural, and they are fixable.

The person signing a seven-figure contract evaluates on a feature matrix, a security review, an integration list and a procurement process. They will use the product for perhaps two hours a year. The person using it for six hours a day has no vote.

This produces a predictable product: comprehensive on paper, exhausting in practice. Feature parity wins deals; workflow quality determines renewals, and by the time that signal arrives the roadmap is three years downstream.

The fix is not to ignore the buyer. It is to instrument the user, and to bring usage evidence into the same conversation where feature requests are prioritised, so 'the top three customers asked for this' can be weighed against 'this workflow takes eleven steps and generates 40% of support volume'.

2. Feature requests are treated as requirements

Enterprise customers ask for specific solutions, articulately, in meetings with your executives. Building exactly what was asked for is the path of least resistance, and it accumulates a product that is the union of everyone's workarounds.

A request is evidence of a problem, not a specification for a solution. The discipline is to ask what the customer was trying to finish, how they do it now, and what happens if they cannot: then design for the problem, which is frequently shared across twenty accounts rather than one.

A designer whose instincts were formed on consumer products will reduce density, add whitespace, hide advanced options behind progressive disclosure and simplify the default view. Applied to expert software used all day, each of these makes the product worse.

• Whitespace that reduces information per screen adds scrolling and lost context
• Progressive disclosure hides controls that experts use every few minutes
• Simplified defaults remove the configuration that made the tool valuable
• Friendly onboarding insults users with ten years of domain knowledge

Expert software should be dense and learnable, not sparse and simple. The craft is in hierarchy, rhythm, typography and consistency at density, which is harder than adding whitespace, and much less frequently taught.

Enterprise data is messy in ways demo data never is. Permissions are partial, integrations lag, records are incomplete, fields contain values from a migration in 2014, and some accounts have four hundred thousand rows where the design assumed forty.

Design files show the happy path. Production shows everything else, and the difference between a product that feels solid and one that feels broken is almost entirely in states that were never designed at all.

When one team owns provisioning, another owns billing and a third owns the admin console, users experience three different products stitched together. Conway's law is visible in enterprise software more clearly than anywhere else.

This is not a design problem that design can solve alone, and it is dishonest to pretend otherwise. What design can do is make the seam visible and expensive: map the journey end to end, show leadership where the handovers cost real money, and make ownership of the whole journey a named responsibility.

1. Observe real shifts, in the actual environment, rather than running interviews in a call
2. Read support tickets as a body of evidence. They are your cheapest research
3. Design at realistic data volumes from the first sketch
4. Treat density as a requirement, and invest the craft in hierarchy instead
5. Design every state before anything ships, not as a QA discovery
6. Instrument the core workflow so usage evidence can argue with feature requests

Enterprise users do not want simpler software. They want software that respects how much they already know.