Every company past a certain size has heard the words "we need a design system." Most of them don't have one, and most of the ones that do aren't getting the value they think they are. Here's what a design system actually is, what it contains, and how to know if yours is worth the investment.
What a design system is (and isn't)
A design system is the set of shared decisions a company makes about how its products look, feel, and behave — encoded in tokens, components, and documentation, so every team can build without re-deciding everything.
It is not: a Figma library. A component library. A style guide. A set of brand guidelines. It contains all of these things, but it's more: it's the contract between your brand and your product, written in code.
What's actually in a design system
1. Design tokens
The atomic values your system is built on: colors (with names like "color/text/primary" not "#080810"), spacing scale (4, 8, 12, 16, 24, 32, 48), typography (font families, sizes, weights, line heights), radii, shadows, animation durations. Tokens are the layer that makes theming (light/dark, multiple brands, white-label products) possible.
2. Components
Buttons, inputs, cards, modals, navigation, tables, charts — the actual building blocks. Each component should have documented variants (primary, secondary, ghost), states (default, hover, active, disabled, error), and behavior (keyboard interaction, screen reader behavior, animation timing).
3. Patterns
Recipes for common flows: empty states, error states, loading states, confirmation flows, onboarding sequences. Patterns are where most design systems stop being useful — because they're the hardest to document well, and the most expensive to get wrong.
4. Documentation
Why decisions were made, not just what the decisions are. The reason a button is 44px tall, not just that it is. The reason error states use red 600, not just that they're red. Without this, the system becomes a black box that nobody can extend without breaking something.
Who actually needs one
- One product, one designer: skip the formal system. Use a component file in your project.
- One product, two to four designers: build a system. It's the only way to stay consistent.
- Multiple products, multiple designers: a system is the difference between a coherent brand and 6 different versions of your button.
- White-label / multi-tenant products: a tokenized system is the only way to ship.
How to know if your system is working
You can measure design system ROI with five questions:
- How long does it take a new designer to ship their first feature? (Should be <2 weeks)
- How many "which button should I use" questions land in Slack each week? (Should trend to zero)
- How much custom CSS is being written outside the system? (Should be <10%)
- How consistent is your product on a visual audit? (Should be 95%+ on a random page check)
- How often do teams propose new components? (Healthy: 1-2 per quarter. Toxic: every sprint)
The biggest mistake teams make
Building a design system as a side project. A design system without a team responsible for maintaining it becomes a museum: full of beautiful components nobody uses, because they don't fit the next feature. The teams that succeed with design systems treat them as a product — with a roadmap, an owner, and quarterly releases. Everything else is just a Figma file that gets stale.