A design system is one of those things that sounds like overhead until you've worked without one. Then it becomes the thing you wish you'd started on day one. But most design systems don't survive contact with the engineering team. Here's why, and how to build one that does.
What a design system actually is
A design system is a shared set of components, tokens, and guidelines that defines how your product looks and works. It includes:
- Design tokens: the raw values (colors, font sizes, spacing, border radii, shadows)
- Component library: reusable UI pieces (buttons, inputs, cards, modals) built from those tokens
- Documentation: guidance on when and how to use each component, written for engineers, not just designers
The goal isn't consistency for consistency's sake. It's to make the right design decision the easy one, so designers and engineers stop relitigating the same choices every sprint.
Why most design systems fail
We've audited a lot of products that technically have a design system but aren't using it. The failure patterns are almost always the same:
- Designers built components in Figma, engineers built different ones in code, and nobody reconciled them
- The system was documented once at launch, then never updated as the product evolved
- There's no designated owner, so nobody feels responsible when components drift out of sync
- The component library was built from screenshots of the Figma file, not from shared token values
- Engineers found it faster to write new CSS than look up the correct component
The result is a design system that exists in theory but doesn't get used in practice.
Start with tokens, not components
The biggest mistake we see teams make is jumping straight to components before defining tokens. Tokens are the foundation everything else builds from.
- Color tokens: define your full palette, then create semantic aliases (primary, surface, text-primary, border) that map to palette values. Change the alias, not the raw value.
- Typography tokens: type scale, font families, line heights, letter spacing
- Spacing tokens: a consistent scale (4px, 8px, 16px, 24px, 32px...) that components use for all padding and margins
- Radius and shadow tokens: so buttons, cards, and inputs all share the same visual language
When tokens change, everything using them updates automatically. Without tokens, changing your primary color means hunting through hundreds of hardcoded hex values.
Build components from the same tokens
Your Figma component library and your production code should reference the same token values, not copies of them. In practice:
- Export tokens from Figma using a plugin like Tokens Studio and import them into your codebase
- Or define tokens in code first and sync them back to Figma
- Either way, there's one source of truth, not two
Every component in production should map to a Figma component. If it doesn't, you've either got an undocumented pattern or a component that needs to be added to the system.
Document as you build, not after
Documentation written after the fact is documentation nobody trusts. The person who built the component needs to document it while the context is still fresh.
What every component's documentation should cover:
- When to use it and when not to
- Which variants exist and when to use each one
- Accessibility requirements: keyboard navigation, ARIA roles, color contrast
- Known edge cases or limitations
- A live code example, not just a screenshot
Assign an owner and treat it like a product
The systems that survive are systems with an owner. Not 'the design team' as a collective, but a specific person whose job it is to:
- Review and merge contributions from the rest of the team
- Keep documentation current when components change
- Audit for drift quarterly and flag when something in production doesn't match the system
- Run a short sync with design and engineering every few weeks
Without an owner, even a well-built system drifts back to inconsistency within six months. It's not a discipline problem, it's a structure problem.
If you're starting a new product and want to build the design system right from day one, get in touch and we'll scope it properly.
