Enterprise UX Design: How to Design Software People Use All Day

Enterprise UX design is the work of shaping software that trained staff use for hours a day to run a business process, such as approving orders, scheduling crews or reconciling accounts. It differs from consumer UX because the people using it are repeat experts with different roles and permissions, so speed on familiar tasks, dense information and safe recovery from mistakes matter more than a smooth first visit.

That short answer hides most of the work. The rest of this guide walks through where enterprise software UX design actually gets hard, and what you can check in your own product before you hire anyone.

Who enterprise users are

A consumer app usually has one kind of user who tries it, likes it or leaves. Enterprise software has several kinds of user, and none of them chose the product. Their employer did.

Take a typical operations tool. A coordinator might live in it all shift, while a manager opens it twice a day to approve exceptions and an auditor logs in once a quarter. Behind them, an admin sets up the roles nobody else sees. Each of those people has a different job, a different screen and a different idea of what "fast" means.

So the first step is research with real roles, done where the work happens. Interviews help, but watching someone do the task tells you more. You will see the spreadsheet open in the next window, the sticky note with the codes nobody remembers, and the three tabs they flip between because the product splits one job across three screens. Those workarounds are the most honest requirements document you will get.

A few questions are worth answering for every role before any screens get drawn:

• How often does this person do the task, and how long does it take today?
• What do they need to see at the same moment to make the decision?
• What happens, and who notices, when they get it wrong?
• What are they not allowed to see or change?

Our service page explains in more detail why consumer design patterns fail in enterprise software. In short, patterns tuned for a first visit slow down someone running the same task hundreds of times a week, white space costs context, and most of the day is spent on the unhappy path. We will not repeat that argument here. This guide is about what to do instead.

Data-dense screens and tables

Most enterprise work happens in a table, a list or a record view. That is where design time should go first, because a table that fits the work saves time on every single use.

Good data views in enterprise software usually share a few traits:

• Density the user can control. Experts often want compact rows and many columns. Occasional users want fewer. A density setting and saved column sets let both work from the same screen.
• Filters that stick. If a coordinator filters to "my region, open, over 3 days old" every morning, the product should remember it or let them save it as a view.
• Bulk actions with clear scope. When a user selects 40 rows and clicks "Approve", the screen should say exactly what will happen to those 40, and what happens to the 3 they do not have permission to approve.
• Context without losing place. Opening a record in a side panel or split view keeps the list in view. Sending the user to a new page and back to the top of the list does not.
• Numbers that line up. Right-aligned numerals, consistent units and visible totals make scanning faster than any visual polish will.

A useful test: ask an expert user to find and fix one specific record while you watch. Count the clicks, page loads and scrolls. Then ask them what they normally do instead. Often the answer is "export to Excel", and that tells you what the table is missing.

Workflows, states and errors

Screens are only the visible part. The real design object in enterprise software is the workflow: a record moving from draft to submitted to approved to posted, with different people acting at each step.

Map the states before you design the screens. For each state, write down who can act, what they can do, and what the record looks like to everyone else. Then design the states most specs leave out, which tend to be loading, empty, partial, error, permission denied and offline. Those are the screens that generate support tickets.

Errors deserve special attention. In a system of record, some mistakes will happen however many confirmation dialogs you add. People click through dialogs they see fifty times a day. What protects them better is:

• Undo for recent actions, where the data model allows it.
• Clear recovery paths when undo is not possible, such as reversing entries instead of silent deletes.
• An audit trail that shows who changed what and when, visible to the people who need it.
• Validation at the point of entry, written in the user's language, with the field that needs fixing in view.

Undo gets harder when several people work on the same thing. We ran into this directly when we built a collaborative whiteboard and diagram editor, an embeddable canvas with shared scenes and exports that can be reopened and edited. If one person moves a shape while another changes the scene around it, undoing the first person's action should not restore an old snapshot and wipe out the second person's work. In that editor, history stores changes rather than snapshots, and remote updates stay out of the local undo stack, so undo applies your own change to the current shared scene. It is not an enterprise admin tool, but the same question comes up in any multi-user workflow: when someone reverses an action, what exactly gets reversed, and whose work is protected?

Onboarding and help for occasional users

Most of this guide is about expert speed. The manager who approves exceptions twice a day uses the product too, and so does the auditor who logs in once a quarter. Both forget the interface between visits. A long product tour on first login does little for them, because nobody remembers a tour from three months ago. The product has to teach them at the moment of use, without slowing down the coordinator who works in it all shift.

Help works best when it sits next to the task. The patterns below put it there:

• Contextual help at the field or column that needs it, such as a short note on what a status code means or which approval limit applies. WCAG 2.2 lists context-sensitive help as success criterion 3.3.5 Help. It is a Level AAA criterion, so it works as a design goal rather than part of a typical AA target. W3C describes its purpose as letting users learn an operation without losing track of what they are doing.
• Labels and instructions on complex forms. Criterion 3.3.2 Labels or Instructions (Level A) asks for them wherever content requires user input. They help most when they use the words of the business process rather than the field names in the database.
• Progressive disclosure. The screen shows the common options first and keeps advanced settings one step away. IBM's Carbon design system follows this model for in-line documentation, with a short note about one feature and a link to fuller docs. Experts still reach everything, and occasional users face fewer choices.
• Sensible defaults, so a form opens with the values most people use. The occasional user then changes only what is different for this case.
• Empty states that teach. Carbon names three basic types of empty state: no data yet on first use, no result after a user action such as a search, and an error such as a missing permission or setup step. A first-use empty state can say what belongs in the list and how to add the first item. For complex setups, Carbon also suggests starter content, meaning sample data people can try things on before they enter real records.
• A help link that stays in one place. WCAG 2.2 added criterion 3.2.6 Consistent Help at Level A. It applies to help options that repeat across a set of pages, such as contact details or a self-help page. Each one must appear in the same order relative to the other content. We go further than the criterion and keep help in the same spot on every screen, so occasional users know where to look.

Tours still have a place when a new feature ships to people who already use the product. Atlassian publishes guidance for this in its Spotlight component, which replaced the older Onboarding component. The guidance is to keep the experience to one spotlight where possible. When a tour is needed, it should have no more than three steps, stay on one screen and show a step count. Carbon adds that users can skip onboarding flows, so these always need basic empty states as well.

For a permission error, Carbon's guidance is to tell users they lack permission and suggest how they can request access. The permission-aware UI section covers that request path.

Help text changes in the same release as the workflow it describes. If a screen changes and the note beside it does not, the occasional user follows steps for a version that no longer exists. The team that changes a workflow should update its field notes and empty-state text as part of the same work.

AI features in enterprise tools

Suggested field values, anomaly flags and summaries of long records are AI features that act on business data. In a system of record, the design question is who stays responsible for the result. Our position is that the person using the tool does, and the interface should make that plain at every step.

Five design rules follow from that position:

• The user approves before anything is saved. A suggestion appears as a suggestion, and the record does not change until a person accepts it. AI changes to many rows need the same clear scope as any other bulk action in the data section above.
• AI output carries a label. IBM's Carbon for AI guidance tells teams to use its AI label and styling to mark any instance of AI use. In Carbon, that label is the main sign that AI is present, and it opens a popover with the first layer of explanation.
• The reason is one click away. The interface shows what a suggestion was based on, such as the fields or records it used. Carbon advises showing explanations only when the user needs or asks for them, which keeps the default screen clear for experts.
• Edits stay visible and reversible. When a user overrides an AI-filled value in Carbon, the component switches from its AI style back to the default style. A "revert to AI" button lets the user go back to the suggestion. Carbon offers AI variants of common enterprise components, including the data table, the form and the date picker.
• Every AI action lands in the audit trail. The trail records what the system suggested and the input it used. It also records who accepted or changed the suggestion, and when. The audit trail then answers the same questions for AI suggestions that it answers for human edits.

Permissions apply here as well, so an AI feature should never show or change data that the user's role cannot see.

Teams that want a governance reference can use the NIST AI Risk Management Framework. NIST released AI RMF 1.0 in January 2023 for voluntary use, and added a Generative AI Profile (NIST-AI-600-1) in July 2024.

Three of its outcomes, under the Map and Manage functions, line up with the design rules above. MAP 3.5 asks that processes for human oversight be defined, assessed and documented, and the approval step and the override control are where that oversight takes place. The audit trail supports MANAGE 4.1, on monitoring, because it captures input for review once the system is live. Under MANAGE 4.3, incidents and errors are shared with the relevant AI actors, NIST's term for the people and teams involved. The trail shows them what the system suggested and who acted on it. NIST says the framework is being revised as part of the White House AI Action Plan, so a policy that cites it should name the version it uses.

Some products also fall under the EU AI Act (Regulation (EU) 2024/1689). Its rules on logging and human oversight apply to high-risk AI systems as the Act defines them, and legal counsel should decide if a feature is one. Under Article 12, a high-risk system must technically allow events to be recorded automatically in logs over its lifetime. Article 14 covers the people assigned to oversee such a system. The system must let them disregard, override or reverse its output. They must also be able to stay aware of automation bias, which means relying on the output automatically or too much. Article 14 qualifies these two oversight duties with the words "as appropriate and proportionate".

For a product in that scope, override controls and an event log belong in the first design. Adding an event log to a live system later can mean changing its data model as well, because the earlier events were never captured.

Permission-aware UI

Permissions in enterprise software often follow the org chart, the region and sometimes the individual record. If the interface ignores that, users meet permissions as surprise errors after they have already done the work.

Design the interface around what each role can do:

• Hide what a role will never use. An auditor does not need the "Create order" button.
• Disable and explain what a role cannot do right now. If a user can usually approve but not this record, say why: "Approvals over your limit go to a regional manager."
• Show read-only data as read-only. Editable-looking fields that reject input on save waste time and trust.
• Design the request path. When someone needs access they do not have, the product should tell them who can grant it or let them ask.

Test with real role configurations, not an admin account. Designers and developers often work as admins, which is exactly why permission problems slip through to production.

Design systems for enterprise products

Enterprise products grow by accretion. New modules arrive over years, built by different teams, and each one solves tables, forms and filters a little differently. Users then have to relearn the basics in every module.

A design system fixes this by turning repeated decisions into shared components. For enterprise software the useful components are rarely the glamorous ones. They are the data table, the filter bar, the form field with validation, the status badge, the side panel, the empty state and the permission-denied message.

A design system earns its cost when each component documents its behavior as well as its look. That means its states, keyboard behavior, accessibility requirements and when not to use it. It also needs to exist in code, for example in Storybook with design tokens, so designers and engineers change it together. A component library that only lives in a design file drifts from the product within a few releases.

Several large software firms publish their design systems. A team that builds its own system can study how each one documents the components it also needs. IBM's Carbon treats empty states as a pattern, with separate guidance for first use, for a search with no results and for errors. Its Carbon for AI extension adds an AI label and AI variants of the data table and the form. That extension has code for React and Web Components. Microsoft's Fluent 2 is a reference for products that run on more than one platform. It offers Figma UI kits and components for the web in React and for iOS, Android and Windows. The Atlassian Design System publishes the Spotlight rules for feature tours described earlier.

Teams that build on Salesforce or SAP have two more references. Salesforce calls SLDS 2, the new version of its Lightning Design System, "the latest design system for Salesforce products built on the Lightning platform". SAP publishes the SAP Fiori design guidelines.

A design system also needs an owner. That person or small group approves changes to shared components and decides when a team may add a new one. Without that role, each module team builds its own variant, and the drift described at the start of this section comes back.

If you are starting from nothing, do not try to systematize everything at once. Start with the components used on the busiest screens, usually tables and forms, and grow from there.

Accessibility as a build requirement

Accessibility in enterprise software is often treated as a launch checklist. It works much better as a requirement for every component in the design system, because a fix made once in a shared table component reaches every screen that uses it.

WCAG 2.2 Level AA is a common conformance target. A few of its success criteria matter more than usual for dense, keyboard-heavy business tools (W3C WCAG 2.2):

• 2.1.1 Keyboard (Level A): all functionality has to be operable through a keyboard. Power users often prefer the keyboard anyway, so this tends to help everyone.
• 2.4.7 Focus Visible (AA) and 2.4.11 Focus Not Obscured (Minimum) (AA): the focus indicator has to be visible, and the focused component cannot be entirely hidden by author-created content such as sticky headers, toolbars or side panels.
• 1.4.3 Contrast (Minimum) (AA): text needs a contrast ratio of at least 4.5:1, with listed exceptions. 1.4.11 Non-text Contrast (AA) asks for at least 3:1 for things like control boundaries and meaningful graphics, which matters for faint table borders and status icons.
• 2.5.7 Dragging Movements (AA): functionality that uses dragging must also be achievable with a single pointer without dragging, with some exceptions. Drag-to-reorder lists and kanban boards need an alternative.
• 2.5.8 Target Size (Minimum) (AA): pointer targets need to be at least 24 by 24 CSS pixels, with exceptions such as adequate spacing. Compact table rows with tiny icon buttons are where this bites.
• 3.3.7 Redundant Entry (Level A): information the user already entered or was given in the same process should not have to be typed again, with exceptions. Long multi-step forms often break this.
• 4.1.3 Status Messages (AA): messages such as "Saved" or "3 records failed" need to be programmatically determinable so assistive technology can announce them without moving focus.

Criteria 2.4.11, 2.5.7, 2.5.8 and 3.3.7 are new in WCAG 2.2, so older audits will not have checked them. Automated tools catch some issues. Keyboard and screen reader testing by a person catches the rest.

How to measure enterprise UX

"Users like it" is a weak signal for enterprise software, because users often have no alternative. Measure the work itself instead:

• Task time for the handful of tasks people do most often.
• Error rate, meaning how often a task ends in a correction, a reversal or a support ticket.
• Task completion without help, especially for occasional users.
• Workarounds, such as exports to spreadsheets, copy-paste between screens and side notes.
• Support and training load tied to specific screens.

Take a baseline before a redesign, using the same tasks and the same kinds of users, and measure again after release. Without a baseline, you cannot tell whether the new design helped or just looks newer. Keep the task list short. Five well-chosen tasks measured honestly tell you more than thirty measured loosely.

When to get a UX assessment

You do not always need a full redesign. Sometimes you need an outside read on where the current product breaks down, so you can decide what to fix first.

Signs that an assessment is worth it:

• Experts use the product all day and say it slows them down.
• Screens cannot hold enough information at once, so people keep spreadsheets alongside it.
• People make mistakes the system will not let them undo.
• The edge cases nobody designed turn out to be the real job.
• A redesign is on the table, but nobody agrees on what is actually wrong.

Our Two-Week UX Assessment is built for this. Over two weeks we sit with real users of the product, find the points where their workflow breaks down, and give you a ranked list of fixes with the value of each one. Your own team can act on the findings, or we can continue into design and build alongside our web application development team.

If you are also working on the marketing site that sells the product, our guide to B2B SaaS website design best practices covers that side. For the product itself, our UI/UX design services for enterprise software page explains how design runs inside the engineering engagement. When you are ready for a number, you can get a range for your design work.

FAQ

What is enterprise UX design?

It is the design of software that staff use to run business processes, often for hours a day. It focuses on expert speed, dense information, role-based permissions, multi-step workflows and safe recovery from errors.

How is enterprise UX different from consumer UX?

Consumer UX is tuned for first visits and voluntary users. Enterprise UX serves repeat experts with different roles who did not choose the tool, so efficiency on familiar tasks and handling of edge cases matter more than onboarding polish.

Do we need user research if we already know our users?

Usually, yes. Your team knows the intended workflow. Watching people work shows what they actually do, including the spreadsheets and workarounds, and that is where many of the useful fixes come from.

Which accessibility standard should enterprise software target?

WCAG 2.2 Level AA is a common target. Your legal and procurement requirements may set a specific standard, so confirm that with your own counsel or contracts.

How do you measure whether an enterprise UX redesign worked?

Compare task time, error rate, unassisted completion and workarounds for the same core tasks before and after release.

How should enterprise software handle AI suggestions?

The product should present each one as a suggestion. The user accepts, edits or rejects it, and only then does the record change. AI output should carry a label, and the reason for a suggestion should be available on request. Each suggestion and each decision about it should go into the audit trail.