Skip to content
Motif
Design systems & tokensLesson 2 of 4Beginner14 min

What is a design system?

A design system is four layers working together — tokens, components, patterns, and governance. See what each layer does and why the order matters.

Kept on this device only.

In one line: a design system is four layers stacked on each other — tokens, components, patterns, and governance — and each layer is only as strong as the one beneath it.

What it is

A design system is not a component library, and it is not a Figma file. It is a foundation stack with four layers, each built from the one below:

  • Tokens — the raw, named decisions: color, spacing, type, radius, motion. Decided once, referenced everywhere.
  • Components — reusable UI assembled from tokens: button, input, badge, modal.
  • Patterns — repeatable solutions composed from components: a form layout, an empty state, an error page.
  • Governance — the rules and people that keep it coherent: how you contribute, version, deprecate, and document.

Take away any layer and the ones above it wobble. Components with no tokens drift into a hundred slightly different blues. Patterns with no components are just screenshots. Components and patterns with no governance rot the moment two teams touch them.

Why it matters

The order is the lesson. Most teams skip straight to components — they build a <Button> before they have a --color-action token — and then spend the next year retrofitting consistency they could have decided once. The same mistake repeats one layer up: teams ship dozens of components but never document the patterns for using them, so every new screen re-litigates the same form layout.

Naming the layers gives you a vocabulary for where a problem actually lives. "Our buttons are inconsistent" is usually a tokens problem. "Every team builds forms differently" is a patterns problem. "Nobody knows which component is current" is a governance problem. Fix the right layer and the ones above it settle.

See it

Live demo
Tweak it3
Step through the layers of a design system: tokens, components, patterns, governance.

Click through the four layers, bottom to top — tokens, components, patterns, governance. The detail panel names what each layer is and shows a few concrete examples, and each layer reminds you which one it builds on.

How it works

The four layers form a dependency chain, and the dependencies only point downward:

  1. Tokens are values with names. --color-action, space-4, radius-md. Nothing references anything else — they are the bedrock.
  2. Components consume tokens. A button reads --color-action for its background and radius-md for its corners. It never hardcodes #3b82f6.
  3. Patterns compose components. A form layout arranges Inputs, a Button, and validation messaging — but invents no new primitives of its own.
  4. Governance wraps all three. It decides when a token is added, how a component is versioned, when a pattern is blessed, and where it is all documented.

Build it

The smallest honest example of the stack is a single token feeding a single component. Two custom properties (the token layer) consumed by a .btn rule (the component layer) — the button never names a raw color or pixel value of its own.

CSS
CSS — a token feeding a component
/* Token layer: named decisions, no component knowledge */
:root {
  --color-action: #3b82f6;
  --radius-md: 8px;
}
 
/* Component layer: reads tokens, never raw values */
.btn {
  background: var(--color-action);
  border-radius: var(--radius-md);
  color: #fff;
  border: none;
  padding: 0.5rem 1rem;
  cursor: pointer;
}
 
.btn:focus-visible {
  outline: 2px solid var(--color-action);
  outline-offset: 2px;
}

Change --color-action once and every .btn follows. That ripple — one decision, propagated everywhere — is the whole reason the stack exists.

Make it yours

Use the controls beside the demo above to change layer, stack order, and highlight dependency — each change updates the example live.

Experiment in the playground
  • Name the layer before you fix the bug. "Inconsistent buttons" is almost always a missing token, not a broken component.
  • Build bottom-up. A token layer first means the component layer never hardcodes a value you have to hunt down later.
  • Governance is a layer, not an afterthought. A version policy and a deprecation log are as load-bearing as any component.

Reproduce it with an LLM

Reproduce it with an LLM

You are a design-systems lead. Take a small product — 'a personal-finance web app for a fictional brand called Lumen' — and sketch its design system as four layers: (1) tokens — the raw decisions (name 6-8 across color, spacing, type, radius, motion); (2) components — the reusable UI built from those tokens (list 6); (3) patterns — repeatable solutions composed from components (list 4, e.g. form layout, empty state); (4) governance — the rules and rituals that keep it coherent (contribution model, versioning, deprecation, docs). For each layer, give one sentence on what it owns and one concrete example, and show how each layer builds on the one below it. Return four labelled sections.

Run with your key

Pitfalls & accessibility

  • Don't confuse a component library with a design system — a pile of components without tokens, patterns, and governance is the first layer of four, not the whole thing.
  • Resist the urge to start at the top. A governance doc for a system that has no token layer yet is process theater.

Further reading