Can you work with our security and compliance constraints?

Yes. We work with anonymised or synthetic data where required, on client infrastructure where necessary, and we treat compliance requirements as design constraints from the first week rather than as a late review.

What about accessibility in enterprise products?

It is frequently a procurement requirement and increasingly a legal one. We design to WCAG 2.2 AA and build accessibility into components so it is enforced at the system level rather than audited per feature.

Expertise / Enterprise UX Design

Expert users don't want simpler software. They want software that respects what they know.

Most enterprise UX failures come from applying consumer instincts to expert work: reducing density, hiding controls and simplifying defaults, each of which makes the product worse for the person using it all day.

Start a conversationAI & Product Design in full

Who this page is for

For teams building complex software for professional users.

Related capability

Product design
SaaS design
Mobile app design
Enterprise UX
AI product strategy
AI experience design
AI UX

Density is a requirement, not a compromise

Software used for eight hours a day, on a second monitor, by someone who knows it well, should show more per screen rather than less. Whitespace that reduces information density adds scrolling, loses context and slows expert work.

The craft is in hierarchy at density: a strict typographic scale, positional rhythm, restrained colour reserved for meaning rather than decoration, and consistency tight enough that the eye can navigate peripherally. That is harder than adding padding and much less frequently taught.

Design at realistic data volumes

Design files contain twelve tidy rows. Production contains four hundred thousand, some with a value from a 2014 migration and a customer name in a field that was supposed to be numeric.

We design each surface at three volumes: quiet, normal, and the worst day the system will see. Designing for the worst day is what makes the normal day feel calm, and it surfaces the pagination, filtering and sorting decisions that otherwise get improvised during implementation.

Permissions, roles and partial views

In enterprise software, what you can see depends on who you are, and every screen has a version where half the data is withheld. Designing only the administrator's view means every other role experiences a broken product.

The same applies to integration lag, stale data, partial sync and the permission-denied state. These are not edge cases in enterprise software. They are Tuesday.

Signals

When this work is worth doing

If two or more of these are true, the conversation is probably overdue.

Users keep a spreadsheet beside the productWhatever people track by hand is what the product failed to give them. That sheet is the brief you have not been sent.
Onboarding requires training sessionsTraining is compensating for information architecture.
Power users have not adopted new featuresNew work has not matched the density or speed of the old path.
The product breaks at large accountsIt was designed at demo volume rather than production volume.

How we scope it

Three ways this usually runs

Durations are typical rather than fixed. We scope after the first conversation, not before.

Workflow study
3 to 4 weeks
Observation of real shifts in the real environment, mapped against system behaviour and support evidence.
You receive
- Workflow map
- Friction analysis
- Opportunity list
Platform restructure
18 to 26 weeks
Information architecture, core workflow redesign and production design at realistic data volumes.
You receive
- Product architecture
- Production design
- State specifications
Enterprise design system
12 to 18 weeks
A dense component system with documented states, accessibility built in, and tokens engineering consumes.
You receive
- Token system
- Component library
- Contribution model

Enterprise UX Design

Questions we hear before we start

Training is a recurring cost created by the product's structure, and it is usually one of the largest line items in an enterprise software business. Better structure reduces implementation cost, shortens time to steady-state usage and reduces support volume: all of which are measurable.