What Is a Design System?
A design system is a shared, versioned set of design tokens, reusable UI components, and documented usage rules that lets multiple people build a product’s interface and have it stay consistent. It is not a style guide and not a component library on its own — it is the combination of the visual decisions (encoded as tokens), the code that implements them (components), and the rules that say when and how to use each one (governance and docs).
Put differently: a style guide tells you the brand blue is #1A56DB. A design system stores that value as a token named color-primary-600, ships a <Button> component that reads from it, and documents that primary buttons are for the single main action on a screen. Change the token once and every button across every app updates.
The three layers
A design system has three layers, and skipping any one of them is the usual reason a “design system” decays into an unused Figma file.
| Layer | What it holds | Owned by |
|---|---|---|
| Tokens | Named values: colors, spacing, type scale, radii, shadows, motion durations | Design + engineering jointly |
| Components | Coded, reusable UI built from tokens: buttons, inputs, modals, tables | Engineering |
| Governance | Usage rules, contribution process, versioning, docs site | A maintaining team or guild |
Design tokens
Tokens are the atomic unit. They are name-value pairs — space-4 = 16px, font-size-body = 1rem, color-danger-500 = #E02424 — stored in a format both design tools and code can read (commonly JSON following the W3C Design Tokens spec, then compiled to CSS variables, iOS, and Android with a tool like Style Dictionary).
The point of tokens is indirection. Components never hardcode 16px; they reference space-4. When the spacing scale changes, or you add a dark theme, you change token values, not every component. Tokens also tier: primitive tokens (blue-600 = #1A56DB) feed semantic tokens (color-action-primary = blue-600), and components only ever consume the semantic ones. That lets you re-theme without touching component code.
Components
Components are the coded, reusable pieces of UI — Button, TextField, Modal, DataTable. Each one is built from tokens, carries its own accessibility behavior (focus management, ARIA roles, keyboard handling), and exposes a small, stable prop API. A component in a real design system is not a single Figma symbol; it is the Figma definition, the React (or Vue, or Web Component) implementation, the tests, and the docs entry, all kept in sync.
Components compose. Primitives (Button, Input) combine into patterns (a SearchBar, a FormRow), and patterns combine into templates. The system owns the primitives and patterns; product teams assemble templates. The split matters: when the system owns too much, teams wait on it; when it owns too little, consistency leaks.
Governance
Governance is the layer teams skip and then wonder why the system rotted. It answers the operational questions: Who can add a component? How is a breaking change versioned and communicated? Where do consumers read the docs? How are deprecations handled?
Concretely it usually includes semantic versioning of the component package, a documented contribution path (propose, review, merge), a published docs site (Storybook, or a custom site) that is the single source of truth, and a deprecation policy that gives consumers a migration window. Without governance, two teams build two date pickers, the docs drift from the code, and people stop trusting the system enough to use it.
What a design system is not
- Not a brand style guide. A style guide is static documentation of visual rules. A design system is executable — the rules are encoded in tokens and components that ship in the product.
- Not just a component library. A library is the code. A design system is the library plus the tokens that feed it and the governance that maintains it.
- Not a one-time deliverable. It is a product with its own roadmap, versioning, and maintainers. Treating it as a project that ends is the most common failure mode.
When you need one
A design system pays off when you have more than one product surface, more than a couple of teams touching the UI, or a long-lived product where consistency and re-theming matter over years. For a single small app built by one or two people, a component library plus a token file is usually enough — the full governance layer is overhead you do not yet need.
How to start
Start with tokens extracted from the UI you already have — audit your real colors, spacing, and type, then collapse them to a deliberate scale. Build the five or six components you use most, wire them to the tokens, and publish them with docs. Add governance as soon as a second team starts consuming the package. Grow the component set on demand, not speculatively.
If you want this built or audited against your existing product, tell us your stack and surfaces and we will scope the token model, component set, and the governance to keep it alive.
