What Is a Design System? A Clear Explanation

A design system is not a component library. That's the most common misconception about what design systems are, and it leads teams to build a collection of components and wonder why they're not getting the consistency and collaboration benefits they expected.

A design system is a set of interconnected design and development decisions — foundations, components, patterns, and documentation — that together enable a team to build a consistent product faster.

The component library is one part of that. An important part, but not the whole thing.

The layers of a design system

Foundations / Tokens. The base layer. Design decisions stored as named variables: color scales, spacing values, typography scales, shadows, border radii, animation durations. These tokens are the raw material for everything above them. A change to a token propagates to every component that uses it.

Components. Reusable UI elements with defined properties, variants, and behaviors. Buttons, inputs, dropdowns, modals, cards, navigation items. Each component is built from foundations. A button uses color tokens, spacing tokens, and typography tokens. Change the spacing token, all buttons update.

Patterns. Combinations of components that solve recurring design problems. Form layouts, card grids, data tables, onboarding flows, settings pages. Patterns are higher-level than components — they document how components are combined and when.

Documentation. Written guidance, usage rules, dos and don'ts, accessibility notes, and code examples. Documentation is what separates a living, usable design system from a Figma file full of components that nobody knows how to use correctly.

All four layers depend on each other. Tokens without components are just a color palette. Components without documentation get used incorrectly. Documentation without tokens goes stale when values change.

Why design systems exist

Consistency. When twenty screens all use the same button component, they look and behave consistently. When twenty screens each have a bespoke button that was manually designed, you get twenty slightly different buttons with different padding, different text weights, and different hover behavior.

Speed. Once a component is built and documented, any designer can use it without designing it from scratch. A dashboard that would take a week to design from scratch takes a day when you're assembling from a library.

Collaboration. Design systems create a shared language between designers and developers. "Use the medium primary button" means the same thing in Figma and in code when both sides reference the same system.

Scale. At ten pages, consistency might be manageable without a system. At a hundred screens across a product with multiple platforms and three designers, it isn't. Systems scale in a way that manual consistency efforts don't.

Famous examples worth studying

Material Design (Google) — one of the most complete public design systems. Covers foundations, components, patterns, theming, and platform-specific guidelines. Available for Android, Flutter, and web. material.io

Atlassian Design System — the system behind Jira, Confluence, and Trello. Detailed documentation, clear usage guidelines, and interesting writing on the system's evolution. atlassian.design

IBM Carbon — IBM's open-source design system. Known for its rigorous accessibility documentation and well-structured tokens. carbondesignsystem.com

Primer (GitHub) — GitHub's public design system. Interesting for its approach to dark mode and their documented decision-making process. primer.style

Study these not to copy, but to understand how they make decisions, what they document, and how they handle the hard problems (theming, accessibility, cross-platform).

When you need a design system

You probably need a design system when:

• You have more than two product designers working on the same product
• Your product has more than twenty distinct screen types
• You're building across multiple platforms (web, iOS, Android)
• Engineers are regularly recreating UI from scratch instead of reusing existing patterns
• Your product has accumulated significant visual inconsistency

You probably don't need a design system when:

• You're a solo designer on an early-stage product
• Your product has fewer than ten screens
• You're building a one-off website or campaign

Building a design system before you need one is a real anti-pattern. Design systems are infrastructure — they pay off over time. Building one when you only have three screens means you're doing infrastructure work that will need to be redone when the product grows and you understand the actual patterns better.

How to start building one

Start with foundations. Before you touch a single component, define:

1. Your color system (primitives + semantic tokens)
2. Your typography scale
3. Your spacing scale

Then build components in order of how frequently they appear across your product. The first three components to build are almost always: Button, Input, and some kind of Layout container.

Document as you build. A component isn't done when it's in Figma — it's done when someone who hasn't seen it before can understand when and how to use it.

Start Your Design System in Figma

On the code side, Storybook is the standard for documenting and testing your components in isolation. Each component gets a story file that renders it in different states with adjustable props.

Try Storybook Free

For publishing documentation that's accessible to non-designers and non-developers, Zeroheight connects to your Figma files and Storybook stories and creates a team-accessible documentation site.

Try Zeroheight Free

The common failure mode

The most common reason design systems fail: they're built by one person in isolation, never adopted by the broader team, and eventually abandoned.

Adoption is the hard part of design systems, not the building. A system only creates value when people use it. That means:

• Building components for the team's actual needs, not an imagined future product
• Making it easy to find and use components (good naming, accessible documentation)
• Getting early buy-in from engineering so the design system has a code implementation
• Treating the design system as a product — with real users, real feedback loops, and continuous improvement

The teams with successful design systems are the ones where the system is genuinely useful to day-to-day work, not a side project that competes with product work for attention.