Design system: the complete guide, 2026 edition

The expected benefits are well known. They only show up once the system is adopted:

• Consistency: the same experience on the website, the customer area and the app.
• Speed: teams assemble existing components instead of redrawing and recoding them.
• Maintenance: a colour or component change happens in one place.
• Onboarding: new designers and developers find the rules written down.
• Accessibility: criteria are handled once, in each component.

We do not put figures on these gains: they depend on your starting point, and the percentages that circulate never say what scope they were measured on. Measure your own (see Measuring success).

A full design system is not always the answer. For a single product and a small team, a component library and a few tokens are enough. The full system makes sense when several teams, products or brands share the same building blocks, or when accessibility and consistency become obligations.

A design token is a design decision stored as a named variable: a colour, a font size, a spacing value, a radius, a shadow, an animation duration. Tokens are the single source that both Figma and the code read.

Three tiers of tokens

• Primitive: the raw palette (color.red.600, spacing.4). Never used directly in components.
• Semantic: the role (color.action.primary, color.text.error). This is the tier designers and developers work with.
• Component: settings specific to one component (button.primary.background), when it needs to differ from the general role.

Naming, modes and multiple brands

Name by purpose, not by value: color.text.error survives a change of red, red-500 does not. Modes (light, dark, high contrast) and brands are handled by changing the values of semantic tokens, without touching components. That is how a group can roll out one system to several subsidiaries.

The Design Tokens Community Group format (2025.10)

The Design Tokens Community Group (DTCG), a community group hosted by the W3C, released the first stable version of its format, numbered 2025.10, on 28 October 2025. The text says so plainly: it is not a W3C Standard and it is not on the W3C Standards Track. It defines a neutral JSON format ($value, $type and $description properties), references between tokens, theming and several colour spaces. According to the group, more than ten tools and open-source projects support or implement it, including Style Dictionary, Tokens Studio, Figma and Penpot. The format text recommends the .tokens and .tokens.json file extensions.

Here is an extract in the 2025.10 format. It replaces the example from the first edition of this guide:

{
  "color": {
    "$type": "color",
    "red": {
      "600": { "$value": { "colorSpace": "srgb", "components": [0.827, 0.137, 0.165], "hex": "#d3232a" } },
      "800": { "$value": { "colorSpace": "srgb", "components": [0.561, 0.078, 0.094], "hex": "#8f1418" } }
    },
    "action": {
      "primary": { "$value": "{color.red.600}" },
      "primary-text": {
        "$value": "{color.red.800}",
        "$description": "Red text on light backgrounds: contrast of at least 7:1"
      }
    }
  },
  "spacing": {
    "$type": "dimension",
    "md": { "$value": { "value": 16, "unit": "px" } }
  }
}

primary and primary-text hold no value of their own: their $value is an alias that points to a primitive token, using the {color.red.600} syntax. The type is declared once on the group and inherited by its tokens.

The production pipeline

Figma variables (or Tokens Studio) export tokens as JSON. A transformation tool such as Style Dictionary turns them into CSS variables, a Tailwind theme, and iOS and Android resources. The JSON file is versioned with the code: a token change goes through review, just like a component change.

A structure that works in most cases:

• Foundations: principles, tokens, colour, typography, grid, spacing, iconography, motion.
• Components: one page per component.
• Patterns: forms, tables, navigation, authentication, empty and error states.
• Content: tone, microcopy, date and amount formats, rules per language.

Every component page follows the same outline: purpose, when not to use it, anatomy, variants and states, props, illustrated do and don't rules, accessibility criteria, code example and a link to the Figma component. A component without documentation goes unused, or gets misused.

Write for agents too. Coding assistants read the documentation: explicit rules ("use Button variant primary for a single main action per screen") work better than a page of screenshots.

Coding assistants now generate part of the screens. Without machine-readable rules, they produce plausible interfaces that sit outside the system: approximate colours, recreated components, invented spacing. The design system becomes the reference they check.

What the agent needs to read

• Tokens, in the DTCG format and with semantic names.
• The list of components, their props and their usage rules, written as sentences.
• A rules file at the root of the repository: which components to use, what is forbidden, how to test.

The connectors

The Figma MCP server passes the variables, components and layout of a design to the coding assistant. Code Connect adds the actual import and usage of the component in your code. The Storybook MCP server, in preview, gives access to component documentation and lets the agent run tests, including accessibility checks.

Components for AI interfaces

A product that embeds an assistant needs new components: generation states (in progress, partial, error), fallback answers, handover to a human, confidence cues, source citations. And the notice telling users they are talking to an AI: Article 50 of the EU AI Act has required it since 2 August 2026, unless it is obvious, according to the European Commission. We cover the design of these journeys in our Harnessed UX service.

AI in governance

AI can also watch over the system: spot detached components in Figma, hard-coded colours, gaps between design and code. Its proposals go through the same reviews and tests as human ones. That is the principle of harness engineering.

The core team

A team, even a small one, owns the system: it maintains it, reviews proposals, trains the teams that use it and measures adoption. There are two models. Centralised: the core team builds everything. Federated: product teams contribute, the core team arbitrates and keeps things consistent. Most organisations move from the first to the second as the system grows.

The contribution process

1. 01

   Proposal

   The need, the use case, a mock-up. Is there already a similar component?

2. 02

   Core team review

   Accepted, merged with an existing component, or declined with an explanation.

3. 03

   Design and documentation

   Figma component, variants, usage rules, accessibility criteria.

4. 04

   Build and tests

   Coded component, Storybook story, interaction, visual and accessibility tests.

5. 05

   Code review

   By the core team and a member of the team that made the proposal.

6. 06

   Release and announcement

   New version, release notes, message to the teams.

Versioning and deprecation

• Major (2.0.0): a breaking change.
• Minor (1.5.0): a new component or option, no breaking change.
• Patch (1.4.3): a bug fix or minor improvement.

A component never disappears overnight: it is first flagged as deprecated, with its replacement and a removal date. A regular ritual (proposal review, demo of what is new) keeps the link with the teams.

Three families of indicators, to track from the pilot product onwards:

• Adoption: share of products using the system, share of the interface built with its components, rate of detached components in Figma.
• Progress: documented components, contribution proposals processed, time between a request and its release.
• Performance: design and build time for a standard screen, interface and accessibility defects found in testing, satisfaction of the teams using it.

Measure before you start. Without a baseline, no gain can be demonstrated.

• Système de Design de l'État (DSFR): the French government's design system. Circular 6411/SG of 7 July 2023 (in French) makes it mandatory for every new website or mobile app of central government departments, prefectures, embassies and devolved State services; State operators may use it with the approval of the Government Information Service (SIG). It deliberately limits customisation in favour of a shared experience. A reference for anyone working with French public bodies.
• Material Design 3 (Google): a model for tokens and dynamic theming, documented for the web, Android and Flutter.
• Carbon (IBM): an open-source system built for enterprise software products, with React and web components.
• Polaris (Shopify): since 1 October 2025, its unified components ship as web components for the admin, point of sale and checkout. Proof that a design system can change technology while keeping its rules.
• Atlassian Design System: detailed documentation on tokens, content rules and accessibility.