In enterprise, the design engagement is rarely the hard part. Getting your own organisation ready for it is.
This is the single strongest predictor of whether the work succeeds, and it is entirely within your control.
Enterprise research means time with the people who use the software eight hours a day: claims processors, dispatchers, analysts, nurses, warehouse supervisors. Their managers control their time and are frequently reluctant to release it. If access is not arranged before the engagement starts, the firm interviews stakeholders instead, and you get software designed around what management believes the job involves.
Get written commitment from the relevant department heads for a specific number of hours, from named roles, in the first six weeks. Do this before the RFP, not after signing.
Enterprise design decisions get overturned late by people who were not in the room. Map the chain properly: who approves the direction, who owns the technical constraints, who owns compliance sign-off, and who has informal veto because the CEO listens to them.
Then decide how disagreements get resolved. A named decision-maker with authority beats a steering committee that meets fortnightly and defers.
A meaningful share of enterprise UX briefs describe problems design cannot fix. If two departments refuse to share a data definition, if the process itself is broken, or if the real issue is that nobody was trained, a redesign will produce a better-looking version of the same failure.
Good firms will tell you this in discovery. It is cheaper to work it out first.
What can the underlying system actually do. Which data models can change and which cannot. What the release cadence is. Whether the frontend can be replaced independently of the backend.
Firms will discover this anyway, in week five, at your expense. Handing it over upfront buys you real design time.
Security questionnaires, insurance verification, data processing agreements, and vendor registration routinely take longer than the discovery phase. Start them the moment you have a shortlist rather than after selection.
Ask each firm on the first call whether they have been through enterprise security review before. Those that have will have the documentation ready. Those that have not will consume your timeline learning.
Procurement templates ask for deliverable lists, which produces proposals padded with artefacts nobody uses. A hundred-page research report satisfies a requirement and helps no one.
Ask instead what the firm will establish, what decisions the work will enable, and how they will know it worked. Let them propose the artefacts.
Enterprise procurement defaults to wide fields for fairness. In design services this produces shallow responses, because serious firms decline or under-invest when the odds are poor.
Three or four, properly briefed, with real access to your context, produces better thinking from all of them. If procurement rules require more, use a short qualification round first and take three through to full proposal.
Research specialists, delivery firms, domain specialists, and global consultancies price and behave differently. Comparing their proposals side by side tells you they are different companies, not which is better for you.
Enterprise case studies describe success. The useful question is what they could not change and how they designed around it.
Worth asking: describe a project where the legacy system prevented the obvious solution. What did you do when a stakeholder overturned an approved direction. How do you handle it when the users want something compliance will not allow. Tell me about a design that was delivered and never implemented, and why.
That last question separates firms with real enterprise history from those with a few enterprise logos. Everyone experienced has one. Candid answers indicate someone you can work with when it happens to you.
No firm will understand your domain on day one and any claiming otherwise is overselling. What matters is a repeatable process for learning it fast: expert interviews, shadowing, iterative validation with real operators.
Ask how they onboarded to an unfamiliar domain on a recent engagement and how long before they could argue with a subject matter expert.
Named people, their tenure at the firm, their role on your programme, what share of their time you get, and what else they are working on. Ask what happens if that person leaves mid-engagement.
This matters most with consultancies, where the pitch team and the delivery team are most often different people.
Task completion time, error rates, support ticket volume, training time, adoption against the system being replaced. Firms that measure outcomes will have opinions about baselines immediately. Firms that do not will talk about deliverables.
Research and recommendations, design through to specification, or design with implementation support. Proposals are frequently ambiguous here, and the ambiguity always costs the client.
If the firm stops at specification, your engineering team inherits every unresolved edge case, permission variant, and error state. That is real work and it needs to be planned and resourced.
Commonly scoped separately and commonly assumed included: accessibility audit and remediation, design system creation, content and microcopy, change management and training materials, implementation support during build, and post-launch iteration.
Every enterprise timeline assumes stakeholders are available, approvals happen on schedule, and security review does not stall. Add contingency for your own organisation, and be honest about holidays, quarter close, and release freeze windows.
Where research recordings, user data, and system access live, who can see them, and what happens at the end of the engagement. This will be scrutinised by your security team, so agree it early.
How the firm gets into your systems, how long it takes, and who sponsors it internally. Environment access delays are among the most common causes of enterprise project slippage.
Design files, source files, research data, and any code all transfer on payment. Check what the firm retains, usually anonymised portfolio rights, which may still need approval under your confidentiality terms.
If the work cannot be published, say so in the contract. Firms rely on portfolio rights and would rather know upfront than negotiate afterwards.
If you selected a firm for specific people, name them in the contract with terms covering replacement.
Enterprise design work rarely finishes cleanly. Agree the rate and mechanism for extension before you need it, rather than negotiating mid-programme.
A specification handed to an engineering team under deadline gets interpreted, and the interpretations accumulate. Budget for design involvement during build, even light-touch review, or accept that the shipped product will differ from the approved design.
Communication, training, champions in each affected team, and a period of parallel running. The best-designed system loses to a spreadsheet people already know.
Users get slower before they get faster, typically for several weeks. Anticipate it publicly so it does not get read as failure by people looking for reasons to revert.
Against the baseline you agreed at the start. Launch metrics tell you nothing about whether the software actually works.
Enterprise software keeps changing. Someone internal needs authority over design decisions after the firm leaves, or consistency erodes within two release cycles.
Briefing a redesign when the underlying problem is process, then shipping a better interface to the same broken workflow.
Running research with stakeholders because operator access was too hard to arrange, and designing for a job nobody actually does.
Selecting on portfolio polish when your product is a dense multi-role platform, then paying the firm to learn what data density requires.
Buying a specification with no implementation support and no internal design capacity to defend it during build.
Treating launch as completion, so adoption is nobody's job and the old system quietly stays in use.