A design system is not a component library. It is a shared language between design and engineering — and the difference matters when you are building something that needs to grow.
The term 'design system' is used to describe everything from a Figma file with some reusable components to a fully documented, versioned, and governed system used by dozens of teams. The gap between those two things is enormous — and most organisations discover it only when the system starts to break down.
What a design system actually is
A design system is a shared language. It defines how a product looks, feels, and behaves — and it encodes those decisions in a form that both designers and engineers can use. The component library is the most visible part, but the system also includes tokens (the raw values: colours, spacing, typography), patterns (how components combine to solve common problems), and documentation (why decisions were made, not just what they are).
The documentation is the part most teams skip. This is a mistake. A component without documented intent becomes a component that gets misused. Six months later, you have fifteen variations of a button, none of which are the canonical one.
Tokens first, components second
The most common design system failure is building components before establishing tokens. Tokens are the atomic values — colour, spacing, radius, shadow, typography — that every component is built from. Without them, you end up with components that are internally consistent but cannot be themed, cannot respond to dark mode, and cannot be updated globally without touching every component individually.
A token-first approach means that a brand colour change is a one-line update, not a find-and-replace across fifty files. It means dark mode is a token swap, not a parallel component tree. It means the system can evolve without being rebuilt.
The governance problem
A design system without governance is a suggestion. Teams will deviate when the system does not cover their use case, when the process for adding to the system is too slow, or when there is no clear owner. The result is a system that diverges from the product it was meant to govern.
Governance does not have to be heavy. It requires three things: a clear owner (a person or team responsible for the system's health), a contribution process (how new patterns get added or changed), and a deprecation process (how old patterns get retired). Without these, the system accumulates debt faster than it can be paid down.
When to build a design system
Not every product needs a full design system. A marketing site with five pages does not need a token architecture and a contribution process. A product with multiple surfaces, multiple teams, and a roadmap that extends beyond the next quarter probably does.
The right time to invest in a design system is before the inconsistency becomes expensive to fix — not after. The cost of retrofitting a system onto an existing product is always higher than building it in from the start.