A design system is a product, not a Figma file
If a component exists only in a design file, it is a suggestion. How we build design systems that survive contact with engineering.
Photo: ready made / Pexels
Many teams have a design system that exists only in a design tool. It looks complete, but engineers rebuild each component slightly differently, and within a year the product has five kinds of button.
Treat it like a product
A design system that works has users (designers and engineers), a roadmap, releases and someone accountable for it. Without those, it starts to decay the moment the launch is over.
Code is the source of truth
We design components in Figma and build them in code at the same time, with design tokens shared between both. The coded library, documented and versioned, is what ships to users, so that is what we treat as the system.
- Tokens for color, type, spacing and motion, shared by design and code
- Every state designed: hover, focus, disabled, loading, error
- Documentation with usage guidance, not just specs
- A release process, so teams adopt changes deliberately
Start smaller than you think
The best systems start with the twenty components the product actually uses and grow from real needs. A system built speculatively, before the product needs it, usually builds the wrong things.
If a component exists only in a design file, it is a suggestion. Once it exists in code, it is a decision.
Working on something like this? We would like to hear about it.
Start a Project
