Designing ERP for Non-Technical Users

Every ERP implementation I've been involved with has the same conversation at month three or month four. The project managers and operations directors call and say, "Our people won't use the system. They keep doing things in Excel." And I get why they're frustrated. The system was implemented on time, it's configured correctly, the training was done. But nobody's actually using it because using it is exhausting.

The problem isn't the system's capability. It's the interface. Most enterprise resource planning systems were designed by engineers who think like engineers. They optimize for completeness and configurability. They expose every option. They assume users want to optimize their workflow by learning keyboard shortcuts and command structures.

That's not how non-technical people work. A warehouse manager doesn't want to learn that Ctrl+Shift+P opens the purchase order screen. They want to walk to a station, see what's in front of them, and act on it. An accounting clerk doesn't want to navigate five menus to close a journal entry. They want to see which entries need closing and close them.

The Gap Between Designed and Reality

Let me be specific about what's broken. Most ERP interfaces organize around the system's data model. Purchase orders live here, inventory here, shipments here. The interface mirrors that organization. A user sits down and has to translate their actual task—"I need to check if we have stock, if not, order it"—into "navigate to inventory module, search for SKU, if results show insufficient stock, navigate to purchase orders module, create purchase order." That's multiple different contexts.

A well-designed interface for that user would be task-based: "Check this item" and the system shows you everything about that item—current stock, recent purchases, upcoming demand. One place. One workflow.

The difference isn't trivial. An accounting clerk using a well-designed system can process 20-30% more transactions per hour than someone using the same underlying system but with a poorly designed interface. That's not because the system changed. It's because the cognitive load dropped.

I've watched this play out multiple times. You implement a well-configured ERP with a bad interface and 40% of your user base circumvents it with spreadsheets within two months. The system doesn't fail. Users just declare that the ERP is for special cases and they'll do their actual work somewhere else.

What Good Design Actually Looks Like

Three principles make the difference.

First: hide complexity by default. Most ERP interfaces show everything at once. Every possible field, every option, every configuration choice. Real users don't need that. They need the 80% of functionality they use regularly, visible and obvious. The edge cases and configuration options should be accessible but hidden behind "advanced" sections or available to people who actually need them.

Second: task-based workflows, not data-based organization. Don't build interfaces around "purchase orders," "inventory," "shipping." Build them around "I need to order stock," "I need to check what we have," "I need to ship this order." Let the interface figure out which systems to call to accomplish the task.

Third: respect the user's language. Don't use technical jargon that means something specific in your ERP implementation but nothing to the person using it. If your warehouse team calls something a "bin," call it a bin in the interface, even if internally the system calls it a "storage location."

Where This Gets Hard

The complication is that every company's ERP is configured differently. Your warehouse workflow is different from another company's. Your chart of accounts is structured differently. The out-of-box interface has to work for a broad market.

That's why the successful enterprise software companies are building customizable UI layers. They ship a base interface that most users see, but power users and system administrators can configure which fields show up, in what order, with what labels. It's not trying to be everything to everyone. It's accepting that different users need different interfaces and making that configurable without requiring custom development.

Some vendors are starting to do this well. The ones that aren't are going to have a competitiveness problem.

What Actually Needs to Change

I think over the next 18-24 months, ERP vendors who want to compete for new implementations are going to have to solve this. They're going to realize that a system nobody uses because the interface is painful isn't actually being used, regardless of how powerful it is. So they're going to either:

One, build better out-of-box interfaces that are genuinely designed for non-technical users. That's possible. It requires UX research with actual users, not just engineers. It requires iteration and testing. Most vendors treat the UI as secondary to the backend systems and it shows.

Two, build better customization tools for interfaces so that companies can make the system work for their specific users. That's the medium-term solution for companies with custom requirements.

Or they lose deals to competitors who figure this out first.

The weird thing is that this isn't a new problem. Salesforce solved this ten years ago by building an interface that non-technical sales people could actually use. Yet somehow ERP vendors haven't applied the same lessons to their products. That gap is one of the biggest opportunities in enterprise software right now.

If you're evaluating a new ERP or upgrading, the interface should be weighted as heavily as the underlying functionality. How it feels to use is how it actually gets used. Everything else is an implementation detail.