Part 0 · 2 chapters · ~15 min

What a Design System Is For

The economics of a design system (a fixed team cost against a per-screen saving, the crossover in screens per quarter, the compounding of consistency), the failure modes, who it serves and who pays, and the six-layer anatomy: tokens, primitives, components, patterns, guidelines, governance.

1

When a design system pays

the economics
  1. The cost: a team of two to six, a quarter to build tokens, primitives and a dozen components, maintenance forever (every component change, accessibility fix and migration), documentation, and the work of migrating existing screens. Fixed and ongoing, independent of usage.
  2. The saving per screen: 20 to 40% of a screen's design and build and more of its QA: no form designed, no inputs built, no focus or error states written, no contrast tested; the design review is about the flow, not the parts. The share rises with coverage.
  3. The crossover is screens per quarter across teams: ten never covers the team; fifty across five teams does within a year, and consistency compounds (a user who learned one form learned them all; support tickets fall; a rebrand is a token change). The Platformization course part 0's curve, for screens.
  4. Failure modes: a library built without consumers and never adopted; tokens that are variables without the semantic tier (dark mode becomes a rewrite); governance as a queue through the system team (teams fork to ship); 60% coverage with escape hatches worse than no system; a system ownerless after its founders leave.
  5. Who it serves: feature engineers first (speed and confidence), then designers (a Figma library matching the code), product, QA, accessibility, users. The budget is argued from the feature engineers' time, never from aesthetics.
  6. The decision: small numbers get a shared stylesheet and a folder of components with no team; large numbers get a charter, a scope (what it covers and what it does not), adoption as a measured goal and a governance model (part 3). The mistake is the enthusiast's library in between, abandoned when they move teams.
WHEN A DESIGN SYSTEM PAYS
screens per quarter against the cost of building and maintaining the system, and the point the lines cross
swipe the figure sideways, or tap expand for full screen
1/6
the cost
The cost: a system team (two to six people: engineers and a designer), the initial build (a quarter for tokens, primitives and a dozen components), maintenance (every component change, every accessibility fix, every migration), documentation, and the adoption work (migrating existing screens). Fixed and ongoing; largely independent of how many screens use it.
2

The anatomy of a design system

six layers, each depending on the ones below
  1. Tokens (part 1): named decisions in three tiers (primitive palette, semantic role, component use); a theme is a semantic remap over the same primitives; dark mode is a theme; nothing above the token layer names a primitive.
  2. Primitives (part 2): behaviour without appearance. A Button primitive owns disabled, pressed, focus-visible, keyboard activation and the role; a Dialog owns the focus trap, Escape, the backdrop, aria-modal and focus return; a Listbox owns arrow keys, typeahead and aria-activedescendant. Headless libraries are this layer; nothing above re-implements the behaviour.
  3. Components (part 2): a primitive plus tokens plus variants plus the system's opinions (Button with intent and size; Input with label, hint, error; Select over the Listbox; Dialog with slots; Table with sorting, selection and virtualisation from the FSD course M6). Each with a documented API, every state designed (part 4), and tests for behaviour, visuals and accessibility.
  4. Patterns: documented compositions for recurring jobs: a form layout, an empty state, a confirmation flow (the Trust course part 0's review step), a filter bar, a page header; sometimes shipped as components, often guidelines with a reference implementation.
  5. Guidelines (parts 4 and 5): the rules code cannot enforce: modal versus page versus inline, how to write an error (the Trust course part 7), density, what motion is for, naming, tone; written with right and wrong examples; the design review's checklist (part 6).
  6. Governance (part 3): who changes what, how a change is proposed, reviewed, versioned and migrated, how feature teams contribute, how adoption and deviation are measured. The only layer that is a process, the one most often missing, and the one that keeps the others true over time.
the exercise
Count your product's screens per quarter and the teams shipping them, then list which of the six layers exist. A missing layer is a failure mode waiting; a layer that exists without governance is decaying.
THE ANATOMY OF A DESIGN SYSTEM
tokens, primitives, components, patterns, guidelines, governance: the layers and what each owns
swipe the figure sideways, or tap expand for full screen
1/6
tokens
Tokens (part 1): --color-text-primary, --space-4, --font-size-body, --motion-duration-fast, --radius-md, --elevation-2. Three tiers: primitive (the palette: blue-600), semantic (the role: color-action-primary), component (the use: button-background). A theme is a semantic tier remapped over the same primitives; dark mode is a theme. Every layer above consumes semantic or component tokens; nothing above names a primitive.