Design systems at ERP scale
A design system at ERP scale is a component library with usage rules that stays consistent across many modules, teams and years.
Its difficult parts are the dense components: tables, line-item editors, forms and filters.
Key facts
- The hardest components in business software are data tables, line-item editors, forms, filter bars and status tags.
- Density is set at system level: compact rows for planners, comfortable rows for occasional users.
- When each module team builds its own table, the product ends up with several tables that filter differently.
- A product built on a standard component library looks like other products built on the same library unless the brand is translated into tokens.
What it covers
| Component | What makes it hard |
|---|---|
| Data table | Sorting, filtering, inline edit, bulk selection, column settings, large volumes |
| Line-item editor | Nested lines, totals, validation per row |
| Form | Dependent fields, conditional validation, drafts |
| Filter bar | Saved filters, many field types, readable summaries |
| Status tag | One vocabulary across every module |
Beyond components, the system documents patterns: how to delete, cancel, lock, correct and show history in the same way everywhere.
A design system can start from scratch or from an existing library such as MUI (Material UI). On products that grow over years, it is versioned by module, so each module keeps its own versions and complete designs. It can be handed to developers as design tokens for their stack, for example Tailwind.
Who uses it
Designers and frontend developers use the system to build new modules. Product managers rely on it to keep a growing product consistent. End users never see the system itself, but they notice when two modules behave differently.
What makes it hard to design
Density. Planners work in compact rows and occasional users in comfortable ones.
Patterns drift. Deleting, cancelling a posted document and showing a locked record drift between modules even when components are shared, so these patterns need their own documentation.
Brand. A product on a standard library looks like other products on the same library. A UI palette derived from the brand, typography and density choices with character, and a few signature components make it recognisable.
In a redesign, the first module sets the foundation. Choosing a central, daily-used module gives the system its hardest components early.
Trade-offs
- A strict system slows teams that need a new component this sprint. A loose one lets them ship and produces drift that surfaces later in training and support costs.
- Heavy customisation makes the product recognisable, and each library upgrade then costs more. Light theming keeps upgrades cheap and leaves the product looking like everyone else’s.
Common mistakes
- Each module team builds its own table. Two years later the product has five tables with different filter behaviour.
- One-off components in the first module that later modules cannot reuse
- Library defaults kept as the final look
- Patterns left undocumented because components are shared
Where Redbrix has worked on this