A design system is tokens plus components plus documentation, organised so a whole team can build consistent UI fast. You have all the pieces now — this lesson assembles them into a coherent system.
The anatomy of a system
A practical CSS design system has clear parts: tokens (the values), a base layer (reset and element defaults), components (buttons, cards, inputs, alerts), utilities (single-purpose helpers) and documentation. Loaded in that order, specificity rises naturally with source order.
| Part | Role |
|---|---|
| Tokens | Colours, spacing, type, radii |
| Base | Reset, element defaults |
| Components | Buttons, cards, inputs, alerts |
| Utilities | Single-purpose helpers |
| Docs | How and when to use each |
Building components on tokens
Every component reads only from tokens, never raw values. A button uses <code>--color-accent</code> and <code>--space-*</code>; a card uses <code>--surface</code> and <code>--radius</code>. Re-theme or rescale the whole system by changing tokens, with no component edits.
<div class="card"><h3>Card</h3><p>Built on tokens.</p><button class="btn btn--primary">Action</button></div>:root{--accent:#2563eb;--surface:#fff;--border:#e2e8f0;--radius:12px;--space-4:1rem}
.card{background:var(--surface);border:1px solid var(--border);border-radius:var(--radius);padding:var(--space-4)}
.btn{font:inherit;border:0;border-radius:8px;padding:.6rem 1rem;cursor:pointer}
.btn--primary{background:var(--accent);color:#fff}Variants and utilities
Components expose variants via modifiers (<code>.btn--primary</code>, <code>.alert--danger</code>). Utilities cover one-off needs (<code>.mt-4</code>, <code>.text-center</code>) without bloating components. Together they balance structure and flexibility.
Consistency is the payoff
Once built, the system means any developer assembles correct, on-brand UI by combining documented classes — no reinventing buttons, no off-palette colours, no random spacing. That consistency is the entire point.
Structure the system as tokens → base → components → utilities, build every component on tokens, expose variants as modifiers, and document usage. Keep it small and real rather than exhaustive.
Assemble a mini system: define tokens, then build a button (with --primary and --ghost variants), a card and an alert — all using only tokens. Add two utilities (.text-center, .mt-4).
1. What order keeps specificity sane?
2. Components should read from…
3. What is the payoff of a design system?
- A system = tokens + base + components + utilities + docs.
- Build every component on tokens, never raw values.
- Expose variants as modifiers; cover one-offs with utilities.
- The payoff is consistent, on-brand UI built quickly by anyone.