Centrim Design System — a token-first, accessible React component system.
Composition
Components are only half the system. How you arrange them — what leads, what supports, what stays quiet — is what makes a screen feel designed. These are the composition rules the reference screens demonstrate.
What is this?
A set of composition rules: build hierarchy from typography and whitespace, keep content on the open page canvas, reserve surfaces for content that genuinely needs containing, and cover all four lifecycle states.
When to use it
- Building any new screen or major page section
- Deciding whether something needs a card, a divider or just space
- Reviewing whether a screen has a clear primary story
How to use it
- Order the page by decision value: context → summary → the main story → detail
- Separate sections with space and hairlines before reaching for a surface
- Give every screen a populated, loading, empty and error state
What to avoid
- Nesting cards inside cards, or wrapping the whole page in one
- Several elements competing to be the most prominent thing
- Metrics or charts that carry no decision
Page rhythm
| Position | Region | Purpose |
|---|---|---|
| 1 | Breadcrumb + PageHeader | Where am I, what is this, what can I do |
| 2 | Summary line or metric row | State of things, quietly |
| 3 | Primary story | The one chart, table or record the page exists for |
| 4 | Interpretation | A Callout reading the primary story out loud |
| 5 | Actionable detail | Lists and tables of work that needs attention |
| 6 | History and activity | Context that is useful but rarely urgent |
When a surface is justified
Content lives on the open page by default
Use a Card or raised surface only when the content is a genuinely separable object — a chart, a table, a floating panel, a repeated summary tile. Headings, metrics, lists and forms belong directly on the page canvas, separated by space and hairline dividers.
Never nest a card inside a card. If two surfaces are needed to express a relationship, the relationship should be expressed with spacing and typography instead.
Hierarchy
| Order | Tool | Example |
|---|---|---|
| 1 | Typography weight and scale | Heading over label over caption |
| 2 | Whitespace | 32px between blocks, 12px inside a group |
| 3 | Text colour | text-primary leads, text-secondary supports, text-tertiary recedes |
| 4 | Hairline dividers | Section boundaries inside a continuous form |
| 5 | Surface | A chart or table that must be containable |
| 6 | Elevation | Only when something floats |
State coverage
Four states, every time
Every data-bearing screen ships with a populated state, a loading state built from Skeleton, an empty state that explains the next action, and an error state that offers a retry. A no-results state after filtering is distinct from a true empty state and needs its own copy.
Do & don't
Do
- Give each screen a single dominant element and let the rest support it.
- Align every region to the same content grid and gutters.
- Use quiet one-line summaries instead of a row of decorative KPI cards.
- Reuse the reference screens as the starting point for a new page.
Don't
- Do not wrap the whole page in a card to make it look contained.
- Do not repeat the same information in a metric, a chart and a table.
- Do not introduce a new section pattern when an existing pattern fits.
- Do not let brand colour appear anywhere other than actions and emphasis.
Why it is designed this way
Data-dense products degrade fastest through container inflation: every team adds a card, and hierarchy flattens into a grid of boxes. Keeping content on the open canvas forces hierarchy to be expressed by typography and space, which scales indefinitely and survives both themes.