UI Patterns for Industrial Information Systems
In short In data-heavy enterprise systems, people work with large tables and complex forms for much of the day, for years. This page lists recurring UI problems in such systems, the patterns that solve them, what to specify in requirements, and what to check in a prototype.
Based on: Business analysis training materials (a catalog of typical UI tasks from industrial information systems).
On this page
Key ideas#
Why these systems are different#
Consumer apps are used occasionally and must be understood in seconds. Industrial and other operational enterprise systems are different: the same people use the same screens for hours every day, over years. Efficiency with large volumes of data matters more than first impressions, and small frictions are repeated thousands of times. The patterns below come from that setting, but they apply to any data-heavy system.
Display patterns#
| Problem | Pattern |
|---|---|
| Entities nested up to three levels deep, with thousands of items | A hierarchical view that expands on demand without overloading the screen |
| Nested structures inside a table | A simplified tree within the table rows |
| Row order matters for the user’s choice, as in a queue | A table without pagination, so the whole order is visible |
| Large tables | Frozen header, key column and footer |
| Totals needed while scrolling | Subtotals or averages in the table footer |
| Selected rows have scrolled out of view | A visible counter of selected rows |
| Many buttons repeat the same word | Actions grouped under one shared label |
| Color-coded rows or cells | A legend that explains the colors |
Functional patterns#
- Editing an entity with a nested structure in one place, without jumping between screens.
- Cascading fields: form fields that read other fields’ values and fill themselves in.
- Dependent lists: drop-down options that depend on values chosen elsewhere in the form.
- Adaptive forms: the form’s structure changes with a selected value.
- Drag-and-drop row ordering, with the new order saved.
- Selection order: recording not only which rows were selected but in what order.
- Date-range filters that find records whose period overlaps the chosen range.
- Filters on hidden attributes: filtering by attributes that are not shown as columns.
A harder case: status-dependent controls#
A frequent request is to enable or disable controls according to the business status of an object, for example no editing after approval. The training material flags the difficulty: making this configurable without moving business logic into the front end. Treat it as an explicit design decision to make with the development team, not as a detail.
How to apply it#
- Ask about volumes and duration early. How many records per screen? How many nesting levels? How many hours a day on this screen? The answers decide which patterns you need.
- Specify table behavior explicitly: pagination or not, frozen parts, footer totals, sorting and filtering rules, and selection rules, including selection order if it matters.
- Specify form dependencies. For each dependent field or list, state the source field and the rule. A decision table works well.
- Define date-range semantics. “Overlaps”, “starts within” and “lies fully within” give different results, so say which one you mean.
- Tie status-dependent behavior to a state model. List which actions are allowed in which status, and agree where that rule lives in the solution.
- Prototype with realistic data volumes. A table that looks fine with ten rows may fail with ten thousand.
Review checklist#
- Tables keep headers and key columns visible while scrolling.
- Users can see how many rows are selected, even off-screen.
- Every color code has a legend, and color is never the only signal.
- Dependent fields and lists have written rules.
- Date filters state their range logic.
- Allowed actions per status are documented.
- The prototype was tried with production-scale data.
Example#
The Workshop, a fictional chain of bike-repair workshops, is building a parts-ordering screen for its managers. The catalog has three levels (bike model, assembly, part) and several thousand parts. The analyst specifies:
- an expandable hierarchy with search;
- an order table with a frozen header and a footer showing the order total;
- a supplier drop-down that lists only suppliers stocking the selected part;
- delivery-date filters defined as “overlaps the chosen week”;
- a selected-row counter for bulk changes;
- a state model stating that order lines can’t be edited after the order has been sent to the supplier.
The prototype is then tested with the full catalog, not a sample.
Sources and further reading#
- Business analysis training materials (practice examples and templates): a catalog of typical UI and UX tasks from industrial information systems.