It is more than a collection of components
Buttons, fields and cards are the visible part. Behind them are decisions about colour, spacing, typography, accessibility, naming and behaviour. There are also examples, instructions and a process that determines whether a new need becomes a shared rule.
The three practical layers
- Foundations: colours, fonts, sizes, spacing, radii and motion.
- Components: reusable pieces with defined variants and states.
- Rules: guidance about selection, composition, content and contributions.
The three layers must remain connected across design and code. If the design file says one thing and the implemented product says another, the team has two sources of truth and the system loses its usefulness.
How it is used in an ordinary day
A designer composes a form from known patterns and focuses on the flow rather than redrawing fields. A developer imports a tested component instead of rebuilding error states. A product manager can discuss work using the same names. The work does not disappear; it moves from repeating decisions to solving the specific problem.
What a design system is not
- It is not just an organised Figma file.
- It is not just a page containing every component in code.
- It is not a project that finishes and remains unchanged.
- It is not an excuse to make every product identical.
- It does not replace research, strategy or design judgement.
Its value appears through use
The number of components does not tell you whether the system is good. Adoption, time saved, fewer differences and problems solved once for every team are more useful. Feedback from internal users matters as much as the documentation.