The Conflation Problem
The design systems conversation in most organizations collapses into a conversation about component libraries. Teams spend months producing a comprehensive Figma file with documented buttons, inputs, and a color palette — and then declare the system done.
What they have built is a useful artifact. It is not a design system. A component library answers: what do things look like? A design system answers something harder: why do they look this way, how do they evolve, who decides when something changes, and how does the system adapt when the product grows in ways the original designers didn't anticipate?
The Layers of a Mature System
A real design system is structured in layers, each building on the one below it, each serving a distinct purpose.
Design Tokens
Tokens are the atomic values that define the visual language at its most primitive level — color primitives, spacing scales, typography steps, border radii, animation durations. They sit below components and give them meaning. When a token changes, every component that references it updates automatically. This is what makes a token-based system fundamentally different from a library where values are hardcoded into individual components.
Components
Components are built from tokens and include documentation of every variant and state, guidance on when each is appropriate, and explicit rules about when the component should not be used. A button that exists in Figma but doesn't match the production implementation is not a system asset — it is a source of inconsistency wearing the costume of consistency.
Patterns
Patterns exist at a higher abstraction level than components. They document recurring solutions to recurring problems — not what a specific element looks like, but how elements should be combined to address a class of user needs. Form patterns, empty states, error handling, onboarding flows. This is where the system's design philosophy becomes explicit.
Governance
Governance defines how the system evolves: how new components are proposed and approved, who has authority over changes, how breaking changes are communicated, and how the system deprecates old patterns without breaking existing implementations. A system without governance is a snapshot that ages into irrelevance.
Documentation
Real documentation captures the reasoning behind decisions — why this spacing scale, why not the alternative that was proposed. Teams that understand the why make better decisions in the edge cases the documentation didn't anticipate. API docs and Storybook alone are not sufficient.
The Scalability Test
There is a straightforward way to assess whether what an organization calls a design system is actually functioning as one: can a new team member use it independently to build a new feature that is consistent with everything that already exists — without asking questions the system doesn't answer?
If the answer is no, the system has significant gaps regardless of how complete the component library appears. Most libraries fail this test immediately, because the people who built them carry the missing context in their heads. It fails from the outside because that context isn't accessible to anyone who wasn't present for the original decisions.
Common Failure Modes
The Hero-Driven System
Built and maintained by one or two individuals who become the de facto authorities on every decision. When they leave, institutional knowledge walks out with them. New decisions get made without the context that informed the original ones. Within two years, the system is a historical artifact.
The Snapshot System
Accurate at launch, never updated as the product evolves. Components get added to production that never appear in the system. Over time the gap grows until teams stop consulting the documentation — it's faster to look at the existing product than to reference guidelines that no longer reflect it.
The Theoretical System
Beautifully documented, almost never used in practice. The failure is typically adoption rather than quality. Components don't match engineering reality closely enough to use without modification. The system was designed to demonstrate sophistication, not to solve practical problems.
