Every design system starts with the same origin story. A product grows faster than its visual language. Components multiply without coordination. Engineers and designers talk past each other using different names for the same thing. Someone proposes a system. A small team builds it. The organisation adopts it — or doesn't.
The failure mode is almost always the same: the system is treated as a deliverable rather than a discipline. A Figma library gets published. A Storybook gets deployed. A Confluence page gets written. And then, slowly, the system and the product diverge.
What a system actually is
A design system is a set of decisions made once so they don't have to be made again. That sounds simple. It isn't. The hard part is not the decisions themselves — it's the governance structure that keeps them alive.
When we say a design system is a promise, we mean it literally. The system promises that a button will behave consistently across every surface. It promises that colour usage will be semantically coherent. It promises that spacing will feel intentional rather than arbitrary. These are not aesthetic promises. They are functional ones.
The system and the product must evolve together, or the system becomes a museum.
The three layers most teams miss
Most design systems are built at the component layer. Buttons, inputs, cards, modals. This is necessary but insufficient. The layers that actually determine system health are below and above the component layer.
Below: the token layer. Colour, typography, spacing, motion, elevation — expressed as named values that components consume. Without a robust token architecture, every component is a bespoke decision. The system has no memory.
Above: the pattern layer. How components combine to solve recurring product problems. A form pattern. An empty state pattern. An onboarding sequence. These are where design systems earn their keep in product velocity — and where most systems stop short.
/* Literal tokens — never use directly in components */
--color-amber-500: #F5A623;
--color-neutral-900: #0A0A0A;
/* Semantic tokens — what components consume */
--color-action-primary: var(--color-amber-500);
--color-surface-base: var(--color-neutral-900);
--color-text-default: var(--color-neutral-50);
/* Component tokens — scoped to a component */
--button-background: var(--color-action-primary);
--button-text: var(--color-neutral-900);Governance is the product
The most mature design systems we've worked with share one characteristic: they have a clear model for how the system evolves. Who can propose changes? Who reviews them? How are breaking changes communicated? How are deprecated patterns retired?
Without this, the system calcifies. Teams stop contributing because the process is unclear. The system falls behind the product. Engineers start writing one-off styles. Designers start maintaining personal component libraries. The promise is broken.
The governance model doesn't need to be elaborate. A weekly office hours session. A clear RFC process. A changelog that's actually maintained. The specifics matter less than the consistency.
What we do differently
When we build design systems at ZELQOR, we treat the governance model as a first-class deliverable — not an afterthought. We document not just what the system contains, but how it should grow. We run contribution workshops with the teams who will use the system. We build the feedback loops before we hand over the keys.
We also build systems that are honest about their scope. A system for a 12-person startup is not the same as a system for a 400-person product organisation. The former needs velocity and flexibility. The latter needs rigour and stability. Applying the wrong model to the wrong context is one of the most common and expensive mistakes in design systems work.
The promise of a design system is only as good as the organisation's commitment to keeping it. That commitment is not technical. It is cultural. And culture, in our experience, is the hardest thing to design.