What is in a design system?
Four layers, from abstract to concrete:
- Foundations: a color palette with roles, a type scale, a spacing system, radii, and shadows.
- Components: buttons, fields, cards, tables, notices — each with its variants and states (default, hover, focus, disabled, error).
- Patterns: solved combinations, like a contact form or a data table with filters.
- Usage rules: when to use each thing and, above all, when not to.
The fourth layer is what separates a design system from a library of pretty components. Without usage rules, everyone chooses differently and the consistency lasts until the next project.
How does it differ from a brand manual?
| Brand manual | Design system | |
|---|---|---|
| Answers | How the brand looks | How the product gets built |
| Audience | Design, marketing, vendors | Design and development |
| Typical content | Logo, correct usage, palette, typefaces | Components, states, spacing, rules |
| Format | A document | A living library in Figma and in code |
| Changes | Rarely | Continuously |
The practical difference: a brand manual gets approved and filed; a design system that gets filed stops being useful in six months.
When is building one justified?
When at least one of these three is true:
- Several people are building. Two designers or two developers already produce divergence; the system is the agreement in writing.
- More than one surface. Public site, internal app, campaign landing pages: without a system, each drifts on its own.
- Decided things get re-decided. If every project reopens the argument about button sizes, you are paying for that argument over and over.
When is it premature spending?
When one person is building one surface that is not about to grow. In that scenario the system takes longer to build than it saves, and it ages before it pays off.
The reasonable alternative is a set of well-named style variables — color, typography, spacing — and a handful of reusable components, with no formal documentation and no Figma library. It is 20% of the effort for much of the benefit, and it can be formalized later if the team grows.
What makes it fail?
Three things, in order of frequency. That nobody maintains it: a system with no owner goes stale and the team goes back to improvising, now with the extra weight of a library that lies. That design and code diverge: if the component in Figma and the one on the site do not match, the system stops being a source of truth. And that it gets built from theory instead of from what already exists: exhaustive systems with forty components of which six get used.
What works is starting by inventorying what the product already uses, consolidating the accidental variants, and documenting that. We deliver the system in Figma alongside the minimum documentation for development, precisely so both halves are born in sync.