How to create a design system: a practical guide

Direct answer

To create a design system, audit the interfaces you already have, define semantic foundations and tokens, build accessible components around real product needs, document behavior and usage, release the system as versioned code, and give a named team authority to govern changes. Start with repeated decisions that slow the product team down; do not begin by drawing a complete component catalog in isolation.

Start with the system's job

A design system is a maintained set of shared decisions, reusable interface parts, documentation, and contribution rules. It helps a product team make related interfaces consistently without solving color, spacing, behavior, and accessibility from the beginning on every screen.

Write down the first release's users, products, platforms, and measurable job. A useful first target might be reducing repeated form implementation across two web applications. A promise to cover every interface for every team is too broad to guide the first release.

• Name the products and platforms in scope.
• Name the teams that will consume and maintain the system.
• Choose one repeated product problem the first release will solve.
• Define evidence such as adoption, fewer duplicate components, faster delivery, or fewer accessibility defects.

Run a design audit before creating components

A design audit turns the current product into evidence. Inventory live patterns and implementation source, not only screenshots or design-file symbols. Record what each pattern does, its states, where it appears, who owns it, and whether it meets current accessibility and product requirements.

Group repeated decisions before naming components. Five visually different account menus may be one navigation pattern with unresolved variants, while two similar cards may serve unrelated jobs and should remain separate.

Define foundations and semantic tokens

Foundations describe the visual rules that components consume. Store recurring values as tokens with names based on meaning and role. A token such as color.action.primary can change across brands or themes without forcing every button to know a palette value.

Keep a clear source of truth and an explicit transformation path into platform code. The Design Tokens Community Group format gives teams a shared model for token names, values, types, groups, aliases, and extensions, but a repository still needs ownership, validation, and release rules.

• Separate source values from semantic roles and component-specific decisions.
• Use aliases so themes change roles without duplicating raw values.
• Validate token names, types, references, and required modes in CI.
• Generate platform outputs from one reviewed source instead of editing several copies.

Set typography, color, spacing, and layout rules

A token list is not enough. Document how the foundations work together in real layouts, including the constraints that prevent local exceptions from becoming another system.

• Typography: define readable text roles, line height, weight, measure, fallback fonts, and responsive changes.
• Color: define semantic roles for surfaces, text, borders, actions, focus, and status in every supported theme.
• Spacing: choose a small scale, then state how components and page regions use it.
• Layout: define containers, grids, breakpoints, density, and content-order behavior instead of scaling desktop screens down mechanically.
• Motion: document duration, easing, interruption, reduced-motion behavior, and which changes need animation at all.

Design the component architecture around product jobs

A durable component architecture separates stable primitives from product-specific composition. Primitives own shared behavior and accessibility. Composites combine primitives for a recurring job. Product features keep business rules close to their data and workflow instead of pushing every conditional into the design system.

Build accessibility into every component contract

Accessibility belongs in the component's behavior, examples, and tests. Use WCAG as the outcome standard and the WAI-ARIA Authoring Practices Guide for established widget patterns. Native HTML should remain the first choice when it already provides the required semantics and interaction.

• Document keyboard order, focus movement, focus return, and escape behavior.
• Give every control an accessible name and every form error a programmatic relationship to its field.
• Test contrast, zoom, reflow, text spacing, reduced motion, and forced-colors behavior where the platform supports it.
• Cover loading, empty, error, disabled, read-only, selected, and destructive states in examples and tests.
• Verify with automated checks and keyboard or assistive-technology review; neither replaces the other.

Code implementation for the design system

Keep semantic tokens near the application root, give shared primitives a small and typed public API, and let consumers compose them. Avoid exposing internal class names as the primary customization contract because implementation details are hard to migrate safely.

The example below shows semantic CSS variables consumed by an owned button component. The exact names are less important than the reviewed meaning, accessible states, and one source of truth.

:root {
  --color-action: oklch(0.55 0.18 250);
  --color-on-action: oklch(0.98 0.01 250);
  --color-focus: oklch(0.72 0.16 75);
  --radius-control: 0.75rem;
  --space-control-inline: 1rem;
}

.button {
  background: var(--color-action);
  color: var(--color-on-action);
  border-radius: var(--radius-control);
  padding-inline: var(--space-control-inline);
}

.button:focus-visible {
  outline: 0.1875rem solid var(--color-focus);
  outline-offset: 0.125rem;
}

Document decisions where teams use them

Documentation should answer when to use a component, when not to use it, what content it accepts, how it behaves, how it adapts, and how a team contributes a change. Storybook can render components and their states in isolation, but a documentation site still needs product guidance, ownership, release notes, and migration paths.

• Show real content and complete states, not one ideal demo.
• Keep design guidance, component examples, API details, and accessibility notes connected.
• Link each documented component to its source, tests, owner, and current release.
• Mark deprecated APIs and provide a tested migration before removal.

Create governance that can make decisions

Governance is the operating model for the system. Name the maintainers, contribution path, review criteria, response expectations, and final decision owner. A committee with no authority creates meetings; a small team with a published process can keep the system coherent and responsive.

• Accept proposals with a product problem, evidence of reuse, accessibility needs, and migration impact.
• Review design and code together when a change affects both contracts.
• Publish a contribution template and a service-level expectation for decisions.
• Measure adoption and exceptions so governance responds to actual friction.

Versioning releases and migrations

Release tokens, components, documentation, and migration notes as one traceable change. Use semantic versioning when the package contract supports it, but describe the user impact in plain language as well. A visual change can be breaking even when TypeScript still compiles.

• Patch: correct a defect without changing the documented contract.
• Minor: add a backward-compatible token, component, state, or API.
• Major: remove or change behavior, markup, tokens, or visual output that consumers rely on.
• Give consumers a migration guide, codemod where practical, adoption window, and named support path.

Worked example: standardize account settings forms

Suppose three products ship different profile forms. The audit finds six input wrappers, four error treatments, inconsistent focus styles, and no shared destructive confirmation. The first design-system release can solve that bounded job before it attempts every component in the company.

• Release field, input, error summary, and confirmation dialog components with tests.
• Document labels, help text, validation timing, keyboard behavior, and error recovery.
• Migrate one representative settings flow before promising a stable public API.
• Measure duplicate-code removal, accessibility defects, migration time, and consumer feedback.

1. Audit: Record the live form states, owners, defects, and duplicate code.
2. Foundations: Agree on field spacing, text roles, status colors, and focus treatment.
3. Components: Build input, field, error summary, and confirmation dialog contracts.
4. Documentation: Show complete settings flows, accessibility behavior, and content rules.
5. Adoption: Migrate one product, correct the contract, then migrate the others.
6. Governance: Measure exceptions and release later changes through the same owner.

Design system launch checklist

• The scope, users, owner, and success evidence are written down.
• A live-product design audit identifies repeated jobs, states, and defects.
• Semantic tokens have one source, validation, themes, and platform outputs.
• Typography, color, spacing, layout, motion, and content rules are documented.
• Components include accessibility behavior, responsive states, examples, and tests.
• Documentation links usage guidance to source, ownership, and releases.
• Contribution, decision, deprecation, and migration paths have named owners.
• A representative product flow has adopted the system and produced feedback.
• Release notes state visual, behavioral, code, and migration impact.
• Adoption, exceptions, accessibility, and delivery outcomes are reviewed regularly.

Choose the next step for your team

Use this guide when your team needs a method for creating or developing a design system. Explore Better Design when you want to compare ready systems, install editable source, or bring design guidance and review tools into an agent workflow.

Steal this workflow

Run this guide in your own assistant. The prompt carries the guide link and the workflow summary, so the assistant can adapt it to your project.

Read the guide "How to create a design system: a practical guide" at https://better-design.com/guides/how-to-create-a-design-system and help me apply it to my project.

To create a design system, audit the interfaces you already have, define semantic foundations and tokens, build accessible components around real product needs, document behavior and usage, release the system as versioned code, and give a named team authority to govern changes. Start with repeated decisions that slow the product team down; do not begin by drawing a complete component catalog in isolation.

Start by asking what I am building and which tools I use. Then walk me through the workflow step by step, adapted to my answers.

Questions

Primary design-system references

These specifications and maintained documentation support the token, accessibility, component-documentation, and public-service examples in this guide.

• Design Tokens Format Module
• Web Content Accessibility Guidelines 2.2
• WAI-ARIA Authoring Practices Guide
• Why Storybook
• GOV.UK Design System

Related

• Explore Better Design systems
• Design systems for AI coding agents
• AI-generated UI quality checklist