Most conversations about software UX assume a user who chose to be there: someone who downloaded an app, compared it to alternatives, and will leave if it’s frustrating. ERP users aren’t that person. They’re doing the same goods-receipt screen forty times before lunch, they didn’t pick the software, and leaving isn’t really an option. Designing for that is a genuinely different discipline, and treating it like consumer UX is where a lot of “modern-looking” ERP interfaces quietly go wrong.
Optimise for the fortieth use, not the first
A consumer app gets judged heavily on first impressions: onboarding, discoverability, a friendly empty state. An ERP screen is used by the same person hundreds of times a week. The interface that actually matters is the one that’s fast and low-friction on the fortieth pass, which usually means the opposite of what looks impressive in a demo. Fewer clicks. Keyboard shortcuts that work properly. Sensible field defaults. A layout that doesn’t make an experienced user relearn where things are every time a new feature ships.
The task should shape the screen, not the data model
It’s tempting to build a form that mirrors the underlying doctype field for field, because that’s the fastest thing to ship. But the way a warehouse clerk thinks about receiving stock and the way the data model represents a Purchase Receipt aren’t the same shape at all. Good ERP UX starts from the actual task: what does someone need to see and enter, in what order, to get this done correctly. Only then does it map that onto the underlying records.
Errors need to surface before submission, not after
In a system where a Purchase Receipt lands stock at landed cost and a Stock Entry posts its GL Entry in the same transaction, a data-entry mistake doesn’t stay contained to one screen. It propagates into stock and the ledger immediately. That raises the bar on validation: catching a mismatched quantity or an invalid cost centre right at the point of entry, with a clear and specific message, isn’t a nice-to-have. It’s the difference between a five-second correction and a reconciliation problem discovered at month-end.
What this actually looks like in practice
Concretely: keyboard-first flows for high-frequency entry screens, defaults that pre-fill what’s predictable from context so a person only touches what actually varies, inline validation instead of a wall of errors after submit, and consistent layout patterns across modules so a skill learned in one screen carries over to the next. None of it is visually dramatic. All of it decides whether the system that went live at go-live is still the one people are actually using a year later, rather than the one they’ve quietly built workarounds around.