What is Design System?
A design system is the single source of truth for how a product looks, feels, and behaves — a versioned library of components, tokens, patterns, and guidelines that engineers and designers share to ship consistent UI fast.
A design system is not a Figma file. It is a working contract between design and engineering: every screen in the product is built from a finite, agreed vocabulary of components, with documented behaviour and accessibility guarantees baked in. The economic case is multiplicative — every new feature ships faster because the team is composing components, not inventing them. The cultural case is even stronger: design system maturity is the single best leading indicator of UI consistency and velocity at scale.
What it includes
- Design tokens (colour, spacing, type) defined once, consumed everywhere
- Component library with accessible, documented behaviour
- Pattern documentation — when to use what, with anti-patterns
- Versioning and changelog so consumers can adopt at their own pace
- Storybook or equivalent for live component playgrounds
- Accessibility baked in (keyboard, ARIA, contrast) — not a phase-two layer
How it works
Start with tokens
Audit existing UI. Pull every distinct colour, type ramp, spacing unit, radius into a token list. Reduce. This alone exposes the inconsistency tax.
Catalogue 20 most-used components
Button, input, card, modal, table, nav, badge, avatar — the workhorses. Build these properly. Worry about the long tail later.
Document behaviour, not just visuals
Loading, disabled, error, focus, hover. Component documentation that only shows the rest state is half-written.
Ship as a real package
NPM-installable, semver-tagged, changelog-disciplined. Treat consumers like external customers even when they are internal teams.
Govern with a steering group
A small cross-functional team owns the system. New patterns get reviewed. Drift gets corrected. The system is a product, not a side project.
Frequently asked
Design system or component library?
A design system includes the component library plus tokens, patterns, guidelines, and governance. A component library is the implementation layer of a design system — necessary but not sufficient.
When is it worth building?
When two or more product teams share UI surface, or when one team has more than ~20 screens with inconsistent UI. Below that, premature investment.
shadcn, MUI, or build our own?
shadcn for full ownership of generated code (most modern stacks). MUI when speed matters more than custom expression. Build-your-own only when the brand is a competitive moat and the team can sustain it.