Search and ERP UX Patterns

ERP UX has a reputation, and mostly it’s deserved. But ERP users are not consumer users, and designing for them like consumers produces something worse, not better.

Who you’re designing for

User type Characteristics Needs
Power user (order entry clerk, accountant) Same 5 screens, 200×/day, for years Speed and keyboard. Will learn anything once
Occasional user (a manager approving) A few times a month Guidance, clarity, defaults
Field/shop-floor user Gloves, noise, standing, poor lighting Big targets, minimal input, offline tolerance
Executive Rarely, on mobile Summary, one decision, one tap
Integration No human A good API

The classic mistake is designing for the occasional user and slowing the power user. A clerk entering 300 order lines a day does not want a friendly wizard. They want to type, tab, type, tab, and never touch the mouse.

Power-user patterns

Keyboard first

  • Tab order that follows the actual data-entry sequence
  • Enter submits, Escape cancels — consistently
  • Function key shortcuts, discoverable but not required
  • No mouse-only actions, ever
  • Type-ahead that doesn’t steal focus or reorder while you type

A rule that pays for itself: any high-frequency screen must be fully operable without a mouse. Time a real clerk doing 20 entries with and without; the difference is often 40%.

Fast entry patterns

  • Copy from previous — most documents resemble the last one
  • Templates — recurring order patterns
  • Multi-line paste from Excel into a grid
  • Bulk edit — change the delivery date on 40 lines at once
  • Defaults from master data, always, with a visible indication that it was defaulted
  • Inline validation as you type, not on submit

Grids, not forms, for line items

Line-item entry belongs in a spreadsheet-like grid: tab across, enter down, paste blocks, column reorder, inline totals. Anything else is slower and users will tell you so.

Search and value help

This is where ERP UX most often fails.

The search problem 

User needs to find a material. They might know:
  - the material number         (10023)
  - part of the description     ("navy jersey")
  - the old/legacy number       (F-1024-N)
  - the manufacturer part no    (MPN-88213)
  - the customer's own number   (ACME-FAB-01)
  - the barcode                 (8901234567890)
  - "the one we used on the Rahman order last month"

A search box that only matches the number is useless. Requirements:

  1. Multi-field fuzzy search across code, description, alternates, and identifiers
  2. Scoped filtering — by plant, sales org, material type, status, so results are relevant
  3. Recent and favourites — users touch the same 40 items repeatedly
  4. Context awareness — searching for a material inside a sales order should default to materials sellable in this sales area
  5. Show enough to disambiguate — description, UoM, stock, status, not just the code
  6. Fast — under 300ms or people stop using it
  7. Barcode input — the field should accept a scanner’s keyboard-wedge input transparently

Implementation 

PostgreSQL:  pg_trgm for fuzzy, tsvector for full text, GIN indexes
             Combine: exact code match first, then prefix, then fuzzy, ranked
Elasticsearch/OpenSearch: when you need real relevance ranking, synonyms,
             multi-entity search, and typo tolerance at scale

Index the searchable projection separately from the transactional table, updated via the outbox. Don’t run trigram searches against a hot OLTP table at scale.

Pattern Use
Role-based home page Show the 6 things this role does, not 400 menu items
Global search / command palette Power users navigate by typing, not clicking
Transaction codes / direct entry SAP’s t-codes exist because typing VA01 beats six clicks. Modern equivalent: a command palette
Worklists / inboxes Push work to people rather than making them look for it
Recently used The same documents get revisited
Deep links Every object needs a stable URL for emailing and bookmarking

Worklists are the single biggest UX improvement available in most ERPs. Instead of “go to the invoice screen and search for blocked invoices”, the user sees “You have 14 blocked invoices” on their home page and clicks through. Same data, dramatically better experience.

Object pages and drill-down 

Sales Order 4711
├── Header: customer, dates, status, value, blocks
├── Items grid
├── Related documents: quotation ← THIS → deliveries → invoices → payments
├── Partners, texts, attachments
├── Change history
└── Actions: copy, reject, print, credit-check release

The document flow view is the most valuable single screen in an ERP. Users constantly need to answer “what happened to this order?” — clicking from an invoice back to the delivery, back to the order, forward to the payment. Build it well and users will forgive a lot elsewhere.

Messages and errors

ERP error messages are notoriously bad. The requirements:

Bad Good
“Error in posting” “Cannot post to period 02/2026 — the period is closed for GL postings. Use a posting date in period 03/2026, or ask Finance to reopen.”
“Field required” “Cost centre is required for account 600100 (Salaries). Suggested: your default cost centre CC-ADMIN.”
“Credit limit exceeded” “Order value 340,000 exceeds available credit of 210,000 for payer Rahman Textiles. Current exposure 590,000 of 800,000 limit. This order needs release by Credit Control.”

Every message should carry: what went wrong, why, which record, and what to do next. Message severity matters too — an error blocks, a warning can be acknowledged, information is just noise if overused.

Message classes with stable IDs are worth the discipline: FI_PERIOD_CLOSED, SD_CREDIT_BLOCK. Users and support can search them, and they can be translated properly.

Mobile and shop floor

Different constraints entirely:

  • Large touch targets — gloves, cold, movement
  • Minimal input — scan, don’t type
  • High contrast — sunlight, poor lighting
  • Offline capable — warehouse dead spots and factory network drops are normal
  • One task per screen — no dense forms
  • Audio/haptic feedback — you can’t watch a screen while handling goods
  • Rugged device support — Zebra, Honeywell, Datalogic handhelds with hardware scan triggers

Offline is not optional for warehouse and field apps. Queue actions locally, sync when connected, handle conflicts explicitly, and never lose a scan.

Personalisation

Users need to adapt screens without a developer:

  • Column selection and order in grids
  • Saved filter variants (“my open orders”, “overdue Dhaka”)
  • Default values per user
  • Screen layout variants per role
  • Favourites and shortcuts

Saved variants are the highest-value personalisation feature. A user who saves their five common filters stops re-entering criteria a dozen times a day.

Accessibility

Legally required in public sector and increasingly in private (EU Accessibility Act, ADA, Section 508):

  • Keyboard operable throughout — which power users want anyway
  • Screen reader labels on every control
  • Sufficient colour contrast; never colour alone to convey status (add an icon or text)
  • Resizable text without layout breakage
  • Focus indicators visible

Accessibility work and power-user work overlap almost entirely. Building for keyboard and clear labelling serves both.

Localisation in the UI

  • Translation of labels, messages, and help
  • Number formats: 1,234.56 vs 1.234,56 vs 1 234,56 vs the Indian/Bangladeshi lakh-crore grouping 12,34,567
  • Date formats: DD/MM/YYYY vs MM/DD/YYYY vs YYYY-MM-DD
  • Calendars: Gregorian, Hijri, Bengali, Thai Buddhist, Japanese eras
  • RTL layouts for Arabic and Hebrew — a full mirror, not just text direction
  • Text expansion — German is ~30% longer than English; design for it
  • Sorting — locale-aware collation

Anti-patterns

Anti-pattern Why
40 fields on one screen because “the table has 40 columns” The table is not the UI
Mouse-required actions on high-frequency screens Slows power users
Modal dialogs stacked three deep Users lose their place
No indication of what’s mandatory until submit Wasted work
Silent success Users re-submit; you get duplicates
No progress indicator on long operations Users click again; you get duplicates
Technical error text shown to end users Confusing and a security leak
Search that requires exact codes Users keep a spreadsheet of codes on the side
Forcing a wizard on someone doing it 200×/day The most-hated ERP pattern

Developer notes

  1. Design for the power user on high-frequency screens, the occasional user elsewhere.
  2. Keyboard-first on data entry.
  3. Search must be fuzzy, scoped, and fast.
  4. Build the document flow view.
  5. Every error says what, why, which record, and what next.
  6. Worklists push work to people.
  7. Saved variants and personalisation, without a developer.
  8. Offline for anything on a warehouse floor or in the field.
  9. Deep-linkable URLs for every object.

Next