A design system is a single source of truth that combines design tokens, reusable components, documentation, and governance to keep a product visually and behaviorally consistent across teams. The strongest examples — Material Design, IBM Carbon, Shopify Polaris, Atlassian Design System — all share four pillars: tokens, components, docs, and a contribution model.
Why Design Systems Exist
The first product team is small. Three designers, six engineers, one shared Figma file. Consistency happens by osmosis. The button looks the same on every page because the same person designed it twice.
The tenth product team is not small. Forty designers, two hundred engineers, six product surfaces, three platforms. Consistency now requires deliberate infrastructure. Without a design system, every team reinvents the button slightly differently. The differences pile up. Customers feel the inconsistency before they can name it.
A design system is the infrastructure that makes consistency possible at scale. It absorbs the cost of “should this button have 16-pixel or 20-pixel padding?” into one place so every team does not have to answer it independently. It is not glamorous work, but it compounds. A company that invested early in a design system ships visual changes across the product in a sprint. A company that did not is still arguing about which shade of blue to use three years later.
Before a team needs a design system, the web design best practices guide covers the foundational decisions every product needs to make. A design system is a way of encoding those decisions and shipping them at scale.
Pillar 1: Design Tokens
Tokens are the smallest indivisible unit of a design system. They encode design decisions as data — color, spacing, typography, radii, shadows, motion durations — and feed them into both design tools (Figma) and code (CSS variables, Tailwind config, native iOS/Android theme files).
The breakthrough idea behind tokens is that a value like “primary brand blue” lives in one place and propagates everywhere. Change the token, and every button, link, focus ring, and active state updates simultaneously. No global find-and-replace. No CSS variable refactor. The token is the contract.
Token Categories
Color tokens cover background, foreground, border, accent, and semantic states (success, warning, error, info). Modern systems use a two-tier structure: primitive tokens (color-blue-600) and semantic tokens (color-action-primary). Primitives describe what the color is; semantics describe what the color is for.
Spacing tokens encode a vertical rhythm — usually a 4-pixel or 8-pixel scale. Tokens like spacing-xs, spacing-sm, spacing-md prevent designers and engineers from picking arbitrary values like 13px or 27px and breaking the visual rhythm.
Typography tokens cover font family, size, weight, line height, letter spacing, and text decoration. The discipline here is restraint. Most products need five or six type styles, not twenty. The website typography guide covers how to design a type scale that holds up at scale.
Other token categories — border radius, shadow elevation, motion duration, motion easing, opacity — fill in the smaller decisions. Done well, the token system makes inconsistency feel impossible.
Pillar 2: Components
Components are the visible layer of a design system. Buttons, inputs, dropdowns, cards, modals, navigation, alerts. Each component is a reusable, accessible, themed piece of UI that ships with documented variants and states.
The trap most teams fall into is treating components as visual artifacts only. A button is not a rectangle with text. A button is hover state, focus state, disabled state, loading state, primary variant, secondary variant, danger variant, sizes (small, medium, large), with-icon, icon-only, full-width, and responsive behavior. A component is the entire surface area, not just the resting state.
Pair every Figma component with its code counterpart. If the design library and the code library drift, the design system fails. The most successful systems treat the design and the code as a single deliverable shipped together. Storybook is the standard tool for documenting code components alongside their visual variants.
Composition matters. A great component library is small at the bottom (atoms) and powerful at the top (compositions). A modal is built from a card, a header, a body, a footer, and a button group. Designers and engineers should never have to rebuild the modal from primitive HTML — they should compose it from the existing pieces.
Pillar 3: Documentation
An undocumented design system is a partially-built design system. Documentation covers what each token means, when to use each component, what props are available, what accessibility considerations apply, and what edge cases to watch for.
The audience for design system docs is broader than most teams expect. Designers need usage guidance and Figma library links. Engineers need API references, code samples, and accessibility notes. Product managers need to know what is available without reading source code. Quality assurance needs spec details to test against. Documentation has to serve all four.
Examples to study. Material Design’s docs cover principles, components, and patterns at depth. IBM Carbon’s docs are unusually thorough on accessibility. Shopify Polaris reads like a friendly internal wiki. Atlassian Design System is the gold standard for “do this, don’t do that” pattern guidance.
Treat the documentation site as a product. The DevTools website design guide covers many of the same patterns — search prominence, code blocks, version selectors. Most strong design system docs are effectively developer tool docs in disguise.
Pillar 4: Governance
Without governance, a design system decays. Teams add components without review, modify tokens locally, and gradually fragment the system back into the chaos it was meant to replace. Governance is the rules and rituals that keep the system coherent.
Contribution Model
Decide early whether the system is centralized (one team owns it, others request changes), federated (multiple teams contribute, with a central review board), or distributed (anyone can commit, with conventions enforced by tooling). Each model has trade-offs. Centralized is the cleanest but slowest. Federated is the most common at mid-size companies. Distributed only works with very strong conventions and an experienced team.
Review Process
Every new component or token change goes through a review. Designers review for visual coherence, engineers review for technical quality, accessibility experts review for compliance, and product managers review for use case alignment. The review is not bureaucracy — it is the moment the design system makes a decision that affects every team using it.
Deprecation
Components and tokens go out of style. Plan for it. Mark deprecated items, give consumers a migration path, and set a sunset date. A design system that adds and never removes will accumulate weight until teams stop using it.
Examples Worth Studying
Material Design (Google) is the most influential design system in the industry. The depth of documentation, the cross-platform consistency (web, Android, iOS), and the pattern guidance set the bar in 2014 and still hold up.
IBM Carbon shows what enterprise-grade looks like. Carbon’s accessibility documentation is exceptional, the component library is comprehensive, and the data visualization patterns are rare in design systems.
Shopify Polaris demonstrates what a product-aligned system looks like. Polaris reads like internal documentation that happens to be public. The tone is direct, the patterns are pragmatic, and the writing style is clearly the work of people who use the system every day.
Atlassian Design System is unusually opinionated about content patterns — when to use a banner versus a flag versus a modal — and that opinionation is what makes it valuable.
For smaller teams, Tailwind UI (commercial) and shadcn/ui (open source) are not full design systems but provide reusable component patterns that many teams use as a foundation. They are starting points, not endpoints.
Team Structure
A design system needs an owner. The exact structure depends on company size.
At a small company (under 50 employees), the design system is a side project of the most senior designer plus one or two engineers. It works for a while, then breaks under product growth.
At a mid-size company (50-500 employees), the design system needs a dedicated team — typically two to four people including a design lead, a frontend engineer, and an accessibility specialist. This is the most common configuration for SaaS companies that hit Series B and discover their UI is fragmenting.
At an enterprise (500+ employees), the design system team is its own product organization. Six to fifteen people across design, engineering, and program management. The design system is treated as an internal product with a roadmap, releases, and consumers.
If your team is shipping marketing content alongside the product, the Framer Websites SaaS industry page covers how the marketing site can adopt the same tokens and components without the full overhead of a federated system.
Common Mistakes
Three failure modes show up across teams of every size.
Building too much before consumers exist. A 200-component library nobody is using is a museum, not a system. Start with the components consumers will adopt this quarter and earn the right to expand.
Treating the design system as a design artifact only. The system has to ship as code, in a way engineers can install with one command, or it will not be adopted.
Forgetting accessibility. A design system that ships inaccessible components multiplies accessibility debt across every product that uses it. Build accessibility in at the token and component level, not as a post-hoc audit.
Frequently Asked Questions
When should a company build a design system?
The trigger is usually around 30 to 50 engineers and three or more product surfaces. Below that, a shared component library and a Figma file are enough. Above that, the cost of inconsistency starts to outweigh the cost of building and maintaining a real system.
Should we use an existing design system or build our own?
Most companies should start with an existing system (Material, Carbon, shadcn/ui, Radix UI) and customize the tokens to match the brand. Building a full design system from scratch costs years of engineering and design effort. Build only when no existing system fits the product surface or brand requirements.
How do we measure design system success?
Adoption rate (percentage of UI surface using system components), velocity gains (time to ship a new feature with system components vs without), and consistency metrics (number of unique button styles in the codebase, before and after). Successful design systems also reduce design debt — bug counts on UI inconsistencies should drop after adoption.
How often should design systems be updated?
Continuously, with versioned releases. Token changes ship as point releases. New components ship as minor releases. Breaking changes (renamed tokens, removed components) ship as major releases with migration guides. Treat the design system like any other production library — semantic versioning, changelogs, and clear upgrade paths.