Centrim Design System — a token-first, accessible React component system.
Centrim Design System
A token-first, accessible React design system for data-dense product interfaces. This documentation explains not just what exists, but when to use it, how to use it, and what to avoid.
Release status
Centrim Life Design System V2.0 is complete and frozen as the source of truth for all new product UI.
| Area | Baseline |
|---|---|
| Status | Completed — release baseline, frozen |
| Typography | Nunito, single family, display and body |
| Primary brand blue | #006DEA via --ds-blue-500 and the primary semantic tokens |
| Sidebar background | #050B42 via --color-sidebar, both themes |
| Icons | lucide-react only, sized from the icon tokens |
| Top navigation | White surface header: brand, location, search, calendar, notifications, theme, profile — no text link bar |
| Accessibility | WCAG 2.2 AA, including 24px / 44px coarse pointer targets |
| Themes | Designed light and dark palettes, verified together |
Principles
Four decisions that explain almost every rule in this documentation.
Token-first
Every visual value lives in a token. Primitives hold raw values, semantic tokens hold roles, and components only read roles — so the whole system can be rebranded from one file.
Hierarchy from type and space
Typography and whitespace carry hierarchy. Surfaces and elevation are reserved for content that genuinely needs containing or genuinely floats.
Accessible by construction
WCAG 2.2 AA is met at the token and component layer: contrast in tokens, one focus treatment, a 24px minimum target on every control.
Composable and predictable
Variants are CVA props, not call-site overrides. Every component forwards refs, merges className and takes children, so composition never needs a fork.
How this documentation is organised
Five sections, read top to bottom in the sidebar. Press ⌘K to search any of them.
Foundations
Colour, typography, spacing, radius, elevation, motion and icons — the decisions everything else inherits.
Components
Actions, primitives, forms, navigation, feedback, data display, charts and overlays, each with usage and accessibility notes.
Patterns
Repeatable multi-component solutions: search and filter, table management, forms, feedback and recovery.
References
Complete screens showing how the system composes, with anatomy annotations and responsive previews.
Guidelines
Accessibility, responsive behaviour, composition and the hard do / don't rules of V1.
Every page answers the same four questions
So you can decide quickly, without reading the source.
| Question | What you get |
|---|---|
| What is this? | A plain description of the thing and the tokens or primitives behind it |
| When should I use it? | The situations it is designed for, and the closest alternatives |
| How should I use it? | Concrete usage rules, live examples and the API surface |
| What should I avoid? | Misuses that break hierarchy, accessibility or the token layer |
Start here
- 1. Read Colour and Spacing — they explain the two rules that govern everything else.
- 2. Skim Do & don't so you know the hard constraints before you build.
- 3. Copy the closest reference screen and replace its content rather than starting from an empty page.
Everything consumers receive lives under src/design-system/; src/showcase/ is documentation only.