How to create a design system from scratch

A practical process for building a system your team will actually adopt and maintain

10 min

Creating a design system is not about designing a pretty component library and hoping everyone uses it. It is a strategic process that requires auditing what already exists, defining solid foundations, building components with intent, and — most importantly — establishing a governance model that ensures the system evolves.

This guide walks through each phase with a practical mindset, aimed at teams that need real results without getting lost in theory. Whether you are starting from scratch or need to formalise what you already have, you will find a clear path forward.

Phase 1: Visual audit and inventory

Before designing anything new, you need to understand what you have. A visual audit involves collecting screenshots of every component, style and pattern that exists across your current products. Tools like the Figma plugin "Design Lint" or simply walking through each screen with organised screenshots are a good starting point.

The goal is not to judge but to quantify: how many button variants exist? How many shades of grey are in use? Are there three different modals doing the same thing? This assessment reveals accumulated design debt and sets the priorities for your system.

  • Capture all screens and states of your current products
  • Group similar elements: buttons, inputs, typography, colours, icons
  • Identify inconsistencies and duplications
  • Prioritise which components have the greatest impact when standardised

Phase 2: Define design tokens

Design tokens are the atomic decisions of your system: colours, typography, spacing, border radii, shadows, animation durations. They are the foundation everything else is built on. Getting them right from the start prevents costly refactors later.

Organise tokens into two tiers: primitive (raw values like #1A73E8 or 16px) and semantic (contextual meaning like color-primary or spacing-md). Semantic tokens are what designers and developers use day-to-day, and they are what enable theming (dark mode, multiple brands) without changing components.

  • Colour: primary, secondary, neutrals, states (success, error, warning)
  • Typography: families, sizes, weights, line heights
  • Spacing: consistent scale (4px, 8px, 12px, 16px, 24px, 32px, 48px…)
  • Other: border radii, shadows, breakpoints, z-index

Phase 3: Build the component library

With tokens defined, it is time to build components. Start with the most used and cross-cutting ones: buttons, form fields, typography, icons, cards and layout containers. Do not try to cover the entire catalogue at once.

Each component should be designed in Figma (or your design tool) and coded in parallel. Parity between design and code is critical: if the Figma component has four variants, the coded component must have the same four. Use clear props, well-defined states (default, hover, active, disabled, error) and document every decision.

Phase 4: Documentation people actually use

Documentation is what turns a component library into a design system. Without it, teams do not know when to use a component, how to combine it with others, or what alternatives exist. Documentation should live alongside the code, not in a forgotten PDF on Confluence.

For each component, document: purpose, available variants, props/API, correct and incorrect usage examples, accessibility considerations, and relationships with other components. Tools like Storybook, Supernova or ZeroHeight let you generate living documentation directly from code.

  • Document the "why", not just the "what"
  • Include correct and incorrect usage examples (do/don't)
  • Keep documentation alongside the component source code
  • Update documentation every time a component changes

Phase 5: Governance model

A design system without governance is a library that goes stale. The governance model defines who can propose changes, how they are reviewed, who approves them, and how they are versioned and communicated. Without this process, the system fragments quickly.

The most common models are: centralised (a dedicated team manages everything), federated (every team contributes following a set of rules) and hybrid (a core team maintains the foundations and product teams contribute specific components). The federated or hybrid model tends to work better in large organisations because it distributes responsibility.

  • Define a clear process for proposing new components or changes
  • Use semantic versioning (semver) to communicate breaking changes
  • Establish a communication channel (changelog, Slack, regular sessions)
  • Assign ownership: someone must be accountable for the system

How to drive adoption

The biggest risk to a design system is not technical but organisational: that nobody uses it. To avoid this, involve the consuming teams from the outset. Gather their feedback, prioritise the components they need most, and make using the system easier than not using it.

Measure adoption objectively: percentage of system components vs custom components in each product, average development time for new screens, and number of reported inconsistencies. These metrics justify the investment and guide the system’s evolution.

Key Takeaways

  • Always start with a visual audit to understand existing design debt
  • Define solid design tokens before building components
  • Build the most used and cross-cutting components first
  • Documentation is what turns a library into an adoptable system
  • Without governance, the system goes stale quickly
  • Measure adoption with objective metrics to justify the investment

Want to build a design system for your team?

We support you through every phase: audit, token definition, component build and a governance model tailored to your organisation.