Design systems are infrastructure, not a side project
A design system is the set of components, tokens, patterns, and documentation that lets a team build consistent product faster. Done well, it accelerates velocity and elevates quality. Done badly, it's a parallel codebase that nobody uses.The maturity ladder
- Style guide — colours, typography, spacing documented in a doc / Figma. No code reuse.
- Component library — reusable components in code. Inconsistent adoption.
- Design system — components + tokens + patterns + documentation, with adoption metrics.
- Multi-product platform — design system spanning multiple products.
Most teams should aim at level 3 and stop. Level 4 is enterprise infrastructure with its own engineering team.
Tokens, not hex codes
- Defined once, used everywhere
- Available in code (CSS custom properties, JS constants)
- Available in design tools (Figma variables / styles)
- Synced — Figma → code via Style Dictionary, Tokens Studio
The mistake: hard-coded hex values in components. The brand-update breaks the system.
Component design that scales
- Variants for the predictable variations (size, intent, state)
- Slots / children for content variation
- Sensible defaults
- Composition over configuration
- Accessible by default — keyboard, screen reader, focus management
Documentation that gets read
- Code examples (working, copy-pasteable)
- Visual examples
- Usage guidelines
- Accessibility notes
- Anti-patterns explicitly called out
Storybook + MDX + a styleguide site is the common stack in 2026.
The adoption challenge
A design system that no team uses is a side project.- Make the system easier than rolling your own
- Code review enforcement — non-system components require justification
- Design pair-with — design system designer in product reviews
- Adoption metrics — % of UI built from system components
- Migration scripts — when components evolve, ship the codemod
Governance
- Federated — anyone can propose, core team reviews
- Centralised — only the core team accepts changes
- Hybrid — accepted patterns from federated; core team consolidates
Versioning
- Semantic versioning of the package
- Major versions for breaking changes, with codemods
- Deprecation cycle (warn → support → remove)
- Multiple versions in production simultaneously is normal
The Figma-code sync problem
- Tokens via Tokens Studio + Style Dictionary
- Component documentation links from Figma to Storybook
- Design QA — designers review built components against intent
- "Source of truth" decision — code or Figma? Pick one for each artefact.
One pattern we'd warn about
Premature design system. A team building a system before they have 2-3 products to consolidate is doing infrastructure speculation.One pattern that always pays off
A "system contributor" role — someone whose explicit job is to support adoption, write codemods, run office hours.What's your design system stack?
