When Nobody Clicks Away, There Is No Warning Signal
A poorly designed website provides honest feedback: visitors leave. In enterprise software, that feedback is absent. Anyone who needs to approve an invoice or create an order has no alternative. They do not look for a workaround in the next tab — they look for one in their own head. That is precisely why poor usability in enterprise software stays invisible for so long. It does not produce a bounce rate. It produces spreadsheets maintained alongside the system, recurring support tickets and overtime that nobody connects directly to the software.
That is the real problem: poor usability in enterprise software generates cost without attracting attention. And because it does not attract attention, it is rarely identified as the cause and even more rarely addressed.
What Usability Actually Means
Usability and user experience are often mentioned together but mean different things. User experience covers the full range of interactions around a product. Usability is the measurable part: it describes how well a system allows users to achieve their goals. The ISO standard 9241 defines it through three factors that can diverge significantly in practice.
| Factor | Question | Measure |
|---|---|---|
| Effectiveness | Does the user achieve their goal at all? | Completeness, accuracy |
| Efficiency | How much effort does it take? | Time, clicks, context switches |
| Satisfaction | How does the user experience the process? | Subjective rating, frustration |
What is almost always missing from this discussion is the context of use. Who works with the system, for which task, how often and under what time pressure? An approval function buried three menu levels deep is no problem for someone who uses it daily. For someone who looks for it once a quarter, it is practically inaccessible. Same technical implementation, two completely different experiences. “Is implemented” and “is usable” are two different things.
Why Enterprise Software Is a Different Playing Field
What works for consumer apps and websites cannot simply be transferred to enterprise software. The conditions are fundamentally different, and that has direct consequences for how usability needs to be approached.
The most obvious difference is mandatory use. Nobody switches their internal ERP because the navigation is inconvenient. Frustration therefore does not manifest as a bounce rate — it manifests as shadow IT: spreadsheets maintained in parallel, unofficial workarounds, informal documentation that supplements or bypasses the official system. These signals are harder to read than a conversion rate, but they are there.
Another difference concerns the users themselves. Someone who opens the same screen two thousand times a year is not a first-time visitor who needs to be guided. They are an expert who needs efficiency: keyboard navigation, sensible defaults, bulk actions. A simple but slow interface is not a good interface for this user.
There is also a structural problem that is almost always overlooked during software selection: the buyer is not the user. Procurement, IT and department heads choose the software. Someone else operates it. Anyone not in the selection meeting has no influence on the decision. That is why usability rarely appears in requirements specifications and only becomes visible once the system is in production.
Usability Is an Architectural Decision, Not a Design Decision
This is the point that is most underestimated in practice. Most usability problems in enterprise software are not design errors. They are architectural decisions made early in the process, without anyone thinking about how the system would actually be used. And because these decisions are made early, they are almost impossible to correct later.
Several patterns appear repeatedly in practice.
The data model determines the form. A screen has forty-seven fields because the underlying table has forty-seven columns. Nobody made that decision consciously. It was simply passed through from the database schema to the frontend.
Saving progress is an API question. The ability to pause a process and continue later is requested in the design and ruled out during interface design. Without partial validation and an endpoint for drafts, there is no way to recover a half-completed form.
Undo requires a persistence concept. Error tolerance is not a UI element that can be added retrospectively. Without soft delete and versioning, every click on “Delete” is final. Users notice this and become correspondingly cautious, slower and less confident.
Bulk actions require endpoints. Processing two hundred records one by one is not a user problem. It is a missing route in the API.
Tables are only as good as their interface. Filtering, sorting and pagination need to work server-side. If the API cannot support that, no frontend will compensate.
What follows from this is straightforward: anyone who reviews usability only at acceptance testing is reviewing too late. By that point, the decisive choices have long since been made.
The Seven States Nobody Draws
In mockups, the world always looks good. The table is populated, the user is authorised, the connection is stable. What almost never appears in mockups are the other states — the ones where users actually spend most of their time.
Empty. What does the system show when no data exists yet? An empty table with no guidance is almost impossible to interpret for a new user.
Loading. How does the system communicate that it is working? A missing loading indicator leaves users unsure whether to wait or reload.
Partially loaded. What happens when some data is available and some is not? Is that communicated or silently ignored?
Error. Are technical error messages passed directly to the frontend? This is the most common form of missing error handling.
Too much data. What happens with a hundred thousand records? Does performance break down, or was that accounted for in the design?
No permission. Can the user see that something exists even though they cannot access it? Or does it simply disappear?
Connection lost. What happens to unsaved input when the connection drops?
These states are rarely drawn, rarely specified and rarely included in acceptance criteria. Yet they are precisely where users have their bad days. They belong in the concept, not in the bug tracker.
What Good Usability Concretely Means
Usability discussions tend to stay vague because concrete criteria are missing. The following points are partly derived from WCAG 2.2 and partly from established frontend development practice. All of them are verifiable and none of them are matters of taste.
One purpose per screen. Every view has exactly one task: reviewing data, checking details or editing records. Anything that does not serve that purpose is questioned.
Three recurring patterns. List view, detail view and edit view structure the navigation. The edit view follows the structure of the detail view so that users recognise content rather than having to reorient themselves each time.
Single-column forms, labels always visible. Placeholder text supplements a label. Error messages appear directly at the affected field and explain the problem in plain language.
Divide long forms into steps. Logical steps with a progress indicator and, where possible, saved intermediate results make complex inputs manageable and reduce the risk of data loss.
Contrast ratios measurable and binding. At least 4.5:1 for normal text, 3:1 for large text and for interactive elements. Colour must never be the only means of identifying a state.
Full keyboard navigation. With a visible focus state that also meets 3:1 contrast, and a focus order that follows the visual layout. In professional applications, keyboard navigation is not a comfort feature — it is the daily working foundation for the majority of users.
Readability as a requirement. Line height at least 1.5 times the font size, text columns no longer than approximately eighty characters.
Keep menus manageable. As a rule of thumb, no more than seven entries per level, with the three to five core tasks directly visible. If a menu becomes too long, that signals an issue with the information architecture, not with the menu itself.
Progressive disclosure. Rarely needed features are accessible but not permanently in the foreground. Full view on demand, lean view as the default.
The value of such criteria lies in the discussions they replace. Contrast ratios and form structures should not need to be renegotiated in every project. We have compiled these points for our own frontend development and are working to establish them as a binding standard.
Accessibility Is Not an Add-On
The specific values above come from WCAG 2.2. There is a legal dimension to this: the European Accessibility Act has applied since June 2025, though for consumer-facing products. Pure B2B applications are not in scope. Public sector clients and increasingly large enterprise procurement processes are asking about accessibility regardless.
The more important reason is a practical one. Almost every accessibility measure improves usability for everyone. A visible focus state helps anyone who uses the keyboard, and in professional applications that is the majority. Sufficient contrast helps in a bright office just as much as it helps users with limited vision. Semantically correct structures benefit screen readers and long-term maintainability equally. Accessible interfaces reduce cognitive load and remain robust across different usage situations. In practice, accessibility and good usability are barely separable.
Usability Starts with Architecture
Poor usability in enterprise software stays invisible in everyday work. It becomes visible in processing time, in rework, in support tickets and in the spreadsheets that run alongside the system. These are the real costs, even if they are rarely labelled as such.
The lever sits earlier than most people assume: in the data model, in the interface, in the states that nobody drew. Anyone who accounts for these from the start builds an application that actually gets used — and not one that a spreadsheet has to compensate for.
