Design systems
What a design system is
A design system is the set of tokens, components, documentation and rules a product reuses: not a Figma file, not a catalogue of options.
Key points
- A design system is made of tokens, components, documentation and an owner.
- The token is the contract: with a semantic name the theme changes without touching components.
- Below three teams the cost of a design system exceeds the benefit.
A design system is the set of visual and interaction decisions of a product, expressed as reusable tokens and components. It is not a Figma file and it is not a component catalogue.
The four parts
A mature design system has tokens, components, documentation and an owner. Tokens are decisions with a name; components are the implementation; documentation says when to use them; the owner decides what gets in.
The token is the contract
A token is a decision with a name: --radius, --primary, --spacing-2. With a semantic name the theme changes without touching components; with a colour name every rebrand becomes a search and replace.
grep -rhoE '^\s*--[a-z0-9-]+:' src/styles/globals.css | sort -u | wc -lThe command prints how many tokens your stylesheet declares. A very low count means raw values written inside components; a very high count means the semantic layer is missing.
The component is the visible part
A button with variants, states and a visible focus ring is the piece the user meets. The EneUI catalogue shows the shadcn/ui sonner record with files and the upstream licence; the catalogue also holds 12,808 icons and 111,985 components.
A design system and a catalogue are not the same
A catalogue lists options: useful for choosing, useless as a rule. A design system chooses for you and records why. That is why two teams can share one catalogue and still ship different interfaces.
Licence and provenance
Every record states the upstream licence. shadcn/ui and Radix UI are MIT, so you can copy and modify; a GPL library or one with commercial clauses changes the calculation. Record the licence next to the component, not only in the repository.
The limitation
A design system costs more than it returns below three teams. Tokens, documentation and reviews need an owner with dedicated time; with one product and two developers, a commented stylesheet does the same job at a tenth of the cost.
Where to continue
Theming without a second design system is in dark mode without a second design system; measured contrast is in palette and measured contrast. The difference between a UI kit, a library and a design system is in UI kit, component library or design system.
Frequently asked questions
Is a design system a component library?
No. A library supplies components; a design system adds tokens, usage rules, documentation and an owner who decides what gets in.
Where do I start?
With tokens. Inventory the raw values, give each decision a semantic name, and only then build components on the tokens.
Do I need Figma?
No. Figma helps you design, but the design system lives in code: tokens and components are the source of truth. A Figma file that drifts from the code is dead documentation.
How many tokens do I need?
There is no right number. You need enough tokens to cover colour, type, spacing and radius, and few enough that you can remember them.
Who maintains a design system?
One person with dedicated time, not a group without a mandate. Without an owner the exceptions pile up and the system stops being a rule.