Design Systems
Design Systems are coordinated collections of reusable components, design tokens, patterns, and documentation that let a team build consistent products across multiple surfaces without rebuilding the basics each time. Bigger than a UI library, broader than a style guide - a system that includes both, plus the rules for how the pieces fit together.
The investment makes sense at scale. A 3-person product team probably doesn’t need one. A 30-person product team almost certainly does, and the absence of one is what makes their product feel different on every screen.
What a real design system contains
Design tokens. Named values for colours, spacing, typography, shadows, motion. The atomic vocabulary every component is built from.
Components. Buttons, inputs, modals, cards, navigation patterns. Designed and coded versions that match each other 1:1.
Patterns. Higher-level compositions - a search bar, a date picker, a settings layout. How components combine to solve recurring user-facing problems.
Guidelines. Voice and tone, accessibility standards, when to use each component, what each pattern is for. The reference docs that prevent the system from being misused.
Governance. Who owns the system, who can contribute, how changes get reviewed. The unsexy part that determines whether the system stays consistent over years.
Where design systems fail
Three patterns:
Building it as a side project. A designer or developer maintains the system “in their spare time.” Updates lag the actual product by months. Teams stop trusting the system and build their own components. The system dies.
Treating it as a Figma library. The design files are pristine. The codebase is a mess of inconsistent implementations because nobody connected the design tokens to the actual CSS. Designers and developers reference different sources of truth.
Over-systematising too early. A 5-person team building a design system before they have product-market fit. Shipped a great system, never shipped the product. Premature systematisation is its own failure mode.
An example
A 25-person product team had three designers each maintaining their own component library in Figma. Engineers had built corresponding components in code that mostly matched the designs but diverged in subtle ways. Every new feature triggered a 4-hour design QA pass to catch and fix component drift.
They invested two months in a real design system: shared Figma library tied to coded components in Storybook, Style Dictionary for token sync, governance via a weekly design ops meeting. Component count consolidated from 47 (across the three libraries combined) to 22.
The design QA pass dropped from 4 hours per feature to about 30 minutes. New feature shipping velocity went up about 25% within a quarter. The system paid for itself within 6 months and continues to compound - each new feature is faster than the last because more of the work is “compose existing components” rather than “design new ones.”
Related terms
- Design Patterns - the underlying concept design systems operationalise at scale
- CSS - the implementation layer most design systems compile to
- Brand - the upstream identity a design system expresses visually
- Content Style Guide - the writing-side analogue to a design system
- Accessibility Terms - the constraint set every design system must respect