Every design team eventually reaches the same moment: the product has grown large enough that decisions made six months ago are contradicting decisions made last month. The button in the onboarding flow is 4px taller than the button in the dashboard. Three different shades of blue are being called “primary.” The mobile app and the web app feel like they were designed by different companies — because functionally, they were.
This is the moment a design system stops being a nice-to-have and becomes a structural necessity.
But before building one, you need to understand precisely what a design system is. Most teams get this wrong, and the confusion is expensive.
What a Design System Is Not
It is not a component library. A component library is a collection of reusable UI components — buttons, inputs, cards, modals. It is part of a design system, but it is not the system itself. A component library without a governing philosophy is just a pile of parts.
It is not a style guide. A style guide documents decisions — here are our colours, here is our type scale, here is how we use icons. It is also part of a design system, but documentation alone does not constitute a system.
It is not Storybook. Storybook is a tool. A design system can use Storybook, but the tool is not the system any more than a hammer is a house.
The confusion between these things — component library, style guide, Figma file, Storybook — leads teams to build something and call it a design system when it is actually just organised assets. The system is the logic that governs the assets.
What a Design System Actually Is
A design system is a shared language between design and engineering, expressed through documented decisions and reusable components, governed by explicit principles.
Three parts of that definition matter:
Shared language. A design system exists at the boundary between design and code. Its purpose is to make sure that when a designer says “primary button” and a developer says “primary button,” they mean the same thing — visually, behaviourally, and semantically. Without shared language, handoff is a translation exercise with losses at every step.
Documented decisions. Not just “here is a button,” but “here is why this button is 40px tall, why it uses this border radius, why the label is 14px medium, and under what conditions you should use it versus the secondary variant.” The decision, not just the artefact, is the substance of the system.
Governed by explicit principles. A design system without principles is ungovernable. When a new component is proposed, what makes it acceptable or not? When two components conflict, which wins? Without principles, every decision is a negotiation. With principles, most decisions make themselves.
The Four Layers of a Design System
A mature design system is built in layers, each depending on the one below it.
Layer 1: Design Tokens
Tokens are the atomic values of a design system: a specific colour (#1A4080), a specific spacing unit (8px), a specific font weight (500), a specific border radius (4px). They are named, documented, and referenced everywhere else in the system.
Tokens are important because they decouple the value from its usage. Instead of hardcoding #1A4080 into every component, you name it color.brand.primary and reference the token. When the brand colour changes, you change it in one place and it propagates everywhere.
Good token architecture distinguishes between three levels:
- Primitive tokens: raw values (
blue-600: #1A4080) - Semantic tokens: purpose-named (
color.action.default: {blue-600}) - Component tokens: component-specific (
button.primary.background: {color.action.default})
This layering is what makes a token system maintainable at scale.
Layer 2: Foundations
Foundations are the design decisions that apply globally across the product: the type scale, the colour palette, the spacing system, the grid, the elevation model, the motion timing.
These are not components — they are the constraints within which components are built. A type scale says: these are the only font sizes in the product. A spacing system says: these are the only spacing values. Without foundations, components are designed in isolation and the product becomes visually incoherent.
Layer 3: Components
Components are the reusable UI building blocks — but built on top of tokens and foundations, not designed from scratch each time. A button component inherits its colour from color.action.default, its padding from the spacing system, its typography from the type scale.
This is what makes a component library a design system component as opposed to a standalone component: it is derived from the system’s lower layers, not invented independently.
Layer 4: Patterns
Patterns are combinations of components that solve recurring UX problems: a form pattern, an empty state pattern, a data table with pagination, a modal confirmation flow. Patterns live above components and encode design decisions about how components should work together.
This layer is the most underbuilt in most design systems — teams invest in tokens and components but never systematise the combinations that their product uses repeatedly.
The Governance Problem
Building the system is the easier half of the challenge. The harder half is governance: who owns the system, how decisions get made, how components get added or changed, and how teams use it without bypassing it.
The most common failure mode is what practitioners call “the shadow system.” A product team needs a component the system doesn’t have. Rather than going through the contribution process, they build it locally. Then another team needs something similar and builds their own version. Six months later, the product has two design systems: the official one and the shadow one living in product team repositories.
Preventing this requires clear answers to four questions:
- Who can add components to the system? (Open contribution, core team only, or RFC process?)
- How are requests triaged? (Single use vs. three or more use cases before systemising?)
- How does the system communicate changes? (Changelog, Slack, automated version bumps?)
- What is the migration path when a component changes? (Versioned releases, deprecation windows, codemods?)
These are organisational questions, not design questions. Most design system failures are governance failures, not craft failures.
When You Need a Design System
Not every product needs a formal design system. The investment is significant and the returns are proportional to scale.
You need a design system when:
- Multiple designers are making decisions independently that need to be consistent
- Engineering is implementing the same UI components repeatedly from specs
- The product spans multiple surfaces (web, mobile, desktop, email)
- Onboarding new designers requires significant time learning “how we do things”
- Refactoring the visual language would require touching hundreds of components
You do not need a design system when you have one designer, one product surface, and a product that is still finding product-market fit. In this context, a design system is premature infrastructure — it constrains the rapid experimentation the product needs.
The Single Most Important Rule
Build the system from the product, not for the product.
The most common design system mistake is building an ideal, theoretical system that the actual product doesn’t reflect. The system becomes aspirational rather than operational — designers stop using it because it doesn’t match the real product, and it decays.
Extract tokens from existing screens. Document the components that already exist. Systematise the patterns your product actually uses. Build the governance process your team will actually follow.
A design system that reflects reality and gets used is worth infinitely more than a comprehensive, perfectly architected system that sits on a shared drive while teams work around it.
This post is drawn from Design Systems Fundamentals (HD·P2·01), part of the Professional track on Hacking Design. Explore the full course at hackingdesign.in/professional/design-systems/.