The defining fact of enterprise software is that the person who pays for it does not use it. Consumer products collapse those roles into one human being; enterprise products split them across three, and often more. A finance director signs. An IT team approves. Two hundred people in operations then live inside the thing for six hours a day, having had no say in any of it.
Every real difficulty in enterprise UX follows from that split. It is why products get bought and never adopted. It is why feature lists win deals that the product then loses in year two. And it is why “make it more intuitive” is not a strategy — it does not say whose judgement you are trying to survive.
The short version
- Enterprise UX strategy is the decision about whose judgement you are designing to survive.
- Three audiences hold a veto: the user, the economic buyer, and IT or compliance. They fail you in different ways.
- There is no single correct strategy. There are four, and the right one depends on which veto is currently live.
- Winning procurement and losing adoption is the most expensive outcome available, because it is invisible for about eighteen months.
- In enterprise, the incumbent is rarely a competitor. It is a spreadsheet and eleven years of habit.
- Accessibility is not a nice-to-have here. It is frequently a procurement requirement with a scoring weight attached.
The three vetoes
Before choosing a strategy, name who can stop you. Each of these groups can kill an enterprise product, and each does it differently.
The user can kill it quietly
They cannot refuse to buy it. They can refuse to use it, and they do — by keeping the old spreadsheet alongside, by using one screen out of forty, by routing around the workflow they were given. The product is paid for and the value never arrives.
Their judgement is formed on repetition. Not on whether something is learnable once, but on whether it is tolerable on the four hundredth repeat. Keyboard paths, how many clicks the common task takes, whether the system remembers what they did yesterday.
Failure mode: shelfware. Renewal conversations where nobody can name a benefit.The economic buyer can kill it before it starts
They are comparing you against two alternatives and a spreadsheet, usually in a structured evaluation. They judge on risk reduction, on the business case, on what their peers at other companies chose, and on whether a feature matrix has gaps where a competitor has ticks.
They will see your product for a few hours, largely in demonstrations where someone who knows it well is driving. This is worth sitting with. The person signing has never experienced your product the way the people using it will.
Failure mode: the deal is lost on a checklist, often to a worse product with better coverage.IT, security and compliance can kill it at any point
Single sign-on, audit logs, data residency, role-based access, accessibility conformance, integration with the four systems already in place. These rarely appear in a design brief and routinely decide procurement, because a failure here is a hard no rather than a preference.
Their judgement is about administration: can we provision two thousand people, revoke access on the day someone leaves, prove to an auditor who changed what. The admin experience is a product in its own right and is usually designed last, by whoever was free.
Failure mode: blocked at review, or approved with restrictions that break the experience you designed.The person signing has never experienced your product the way the people using it will.
The four strategies
Each of these is a legitimate strategy. Each concentrates effort somewhere specific and accepts a known weakness elsewhere. The mistake is not choosing the wrong one — it is choosing none and spreading effort evenly, which produces a product that is adequate to everyone and compelling to no one.
Adoption-first
Design for the daily user and let demonstrated usage carry the commercial argument. Depth on the three tasks that consume most of the working day, a short path to the first real outcome, and instrumentation good enough to show a buyer exactly what adoption looks like.
Right when usage is voluntary or partially voluntary, when the user population is large relative to the deal, and when you can get in without a formal procurement process. It is also the strategy with the longest payback, which makes it hard to defend in a quarterly review.
Accepts: losing deals on feature coverage. You will lose some, and the discipline is not to chase them.Procurement-first
Design to win the evaluation. Coverage against the matrix, a demonstration path that holds together under questioning, security and compliance evidence ready before it is asked for, and a reference customer who looks like the buyer.
Right when purchases are centralised and formal, when deals are large and few, and when the product cannot get in the building any other way. It is a real strategy and it is often the only viable one in regulated sectors and government.
Accepts: a product optimised for being chosen rather than used. Plan the adoption work for immediately after signature, with budget, or you are simply deferring the failure.Migration-first
Treat the incumbent as the design problem. In most enterprise categories your real competitor is not another vendor — it is a spreadsheet, an internal tool built in 2014, and eleven years of accumulated habit that works well enough.
The work here is switching cost: importing existing data without loss, mirroring familiar vocabulary even where yours is better, running in parallel without penalty, and making the first week survivable for someone who did not ask for this change. Right whenever people already have a way of doing the job, which is most of the time.
Accepts: carrying some of the old model’s awkwardness into your product, temporarily and deliberately.Consolidation-first
Win by replacing several tools at once. The design problem is breadth and the seams between areas: a coherent object model across what used to be separate products, one administration story, one permission model, and honest handling of the areas where you are the second-best option.
Right for established platforms selling to organisations tired of integration overhead. The buyer’s argument is cost and simplification; the user’s experience of it is whether the seams show.
Accepts: being beaten on depth by specialists in every individual area. The argument has to be the whole, and it has to actually be true.Which one fits your situation?
Three inputs. The strongest signal is usually not your product category but which veto is live right now, and that changes over a product’s life — the strategy that got you in the building is rarely the one that keeps you there.
Strategy chooser
Three inputs, one recommendation, and the trap that comes with it.
Who can stop this product today?
What are people doing instead right now?
Where are you?
Three inputs, one strategy
Pick who holds the veto, what people are using now, and where you are in the product’s life.
Concentrate effort here
—
Deliberately do less of this
—
0 of 3 chosen
What an enterprise UX strategy actually contains
Not a vision statement. A short set of artefacts that other people can make decisions from when you are not in the room.
| Artefact | What it settles |
|---|---|
| The role model | Which roles exist, what each is trying to accomplish, and which ones you are optimising for when they conflict. Three or four real roles, named from actual customers. |
| The task inventory, weighted by frequency | Which tasks consume the working day. The ones performed hundreds of times deserve a different design standard from the ones performed twice a year, and without this everything gets treated equally. |
| The migration path | What someone is doing today and exactly how they get from that to this, including data, vocabulary and the parallel-running period. |
| The administration experience | Provisioning, permissions, audit, configuration. Owned by someone, designed properly, not left to whoever had capacity. |
| The accessibility standard | The conformance level you meet and how you evidence it, because in enterprise procurement this is frequently scored rather than assumed. |
| The configurability line | What customers can change and what they cannot. Written down before the first large customer asks, or it will be decided by whoever is negotiating that deal. |
| The rollout plan | How two hundred people are moved onto this, who trains them, what happens in week one, and who they ask when it goes wrong. |
The configurability line deserves particular attention, because it is where enterprise products most often lose control of their own design. Every large customer asks for an exception. Each one is reasonable. Thirty of them produce a product with no coherent model, a support burden that scales with revenue, and a release process that cannot move without breaking somebody. Decide what is configurable and what is not while you still have the leverage to say no.
What genuinely differs from consumer work
Expertise is the normal state, not the exception. Your user has done this job for nine years and knows more about the domain than you do. Designing for first-time comprehension at the expense of the four-hundredth repetition is the most common and most damaging error in enterprise work. Keyboard paths, density, bulk operations and the ability to skip explanation all matter more than onboarding polish.
Change is genuinely costly for the people absorbing it. A redesign that improves the product by fifteen percent and costs each of two thousand people a week of relearning is not obviously a good trade. Consumer instincts about refreshing an interface translate badly here.
Power users will oppose improvements. The people who shout loudest have optimised their working life around the current behaviour, including its flaws. They are not wrong to object and they are not representative. Listen to the specific cost they are naming, not the general objection.
The spreadsheet is the real incumbent. It is flexible, free, requires no approval, and already contains the data. Any strategy that does not account for it is describing a different market than the one you are in.
Access is harder, so research gets skipped. You cannot recruit enterprise users from a panel, and the buyer often controls whether you meet them at all. This is the reason enterprise products are so frequently designed from assumptions — and it is a solvable problem, usually by making access to users a term in the contract rather than a favour requested later.
Where this goes wrong
| Failure | Looks like | Prevention |
|---|---|---|
| No strategy, even effort | Adequate everywhere, compelling nowhere | Name the live veto and concentrate on it. |
| Won procurement, lost adoption | Signed, rolled out, barely used by month nine | Budget the adoption work before signature, not after. |
| Designed for the demo | Beautiful on five screens, unbearable on the sixth | Weight design effort by task frequency, not by what gets shown. |
| Admin experience as an afterthought | IT blocks the rollout or approves it with restrictions | Treat administration as a product with an owner. |
| Migration ignored | Pilot stalls because nobody can move their data | Design the switching path alongside the product itself. |
| Configurability by negotiation | Thirty exceptions, no coherent model, releases that break customers | Draw the configurability line in writing, early. |
| Accessibility discovered at procurement | A conformance questionnaire nobody can answer, weeks before signature | Set the standard at the start and keep the evidence current. |
| Loudest user treated as representative | Roadmap shaped by three power users | Weight feedback by task frequency across the population. |
Where to start
Write down, in one sentence each, who can stop your product today and what would make each of them do it. Most teams find they can answer confidently for one of the three and are guessing about the other two — and the one they are guessing about is usually the one that will decide the outcome.
Then take your task inventory and sort it by how often each task is performed, not by how important it feels. Compare that ordering against where your design effort has actually gone over the last two quarters. The gap between those two lists is your strategy problem, stated more precisely than any workshop will state it.
How we work at Adi Design. On enterprise engagements we start by naming the live veto and the task inventory, design the administration experience as a first-class product, and write the configurability line down before the first large customer asks for an exception. If you are weighing a platform redesign or trying to work out why a product that sold well is not being used, get in touch.
