Design system maturity model: where your team sits and what comes next

Insights · Design systems

Design system maturity is best read as a profile, not a single stage. Place adoption, tokens in code, governance, contribution, documentation and Figma and code alignment separately, each on evidence you can pull from your own tools rather than on opinion. What comes next is not automatically more components: it is the weakest area on the path between a shared decision and the product your customers use.

If that evidence disagrees with how your team feels about the system, the disagreement is the first thing to investigate. This page gives the models worth knowing, a six-area self-assessment built on observable evidence, and a way to turn the result into a next step.

Which design system maturity models exist, and what do they agree on?

Three public models recur in the current answers to this question. Each was checked at its source.

The newer models make three points that matter for your next step:

• One number hides the shape. The six-dimension and six-axis models both score areas separately, because a system can be strong on components and weak on ownership at the same time.
• Adoption is not a phase after the build. The six-dimension framework treats it as something teams have to keep earning at every point, not a stage you pass through.
• Maturity can go backwards, and smaller can be right. The six-dimension framework notes that reorganisations, budget cuts and mergers can set a system back, and that a lean system can be mature for a small organisation. A 2023 critique of linear maturity models from Supernova made the same point about context: a small team serving one product has little reason to aim for an enterprise-scale system.

What the models share is also their limit. Their self-assessments ask people what they believe about the system. That is a reasonable start, but belief and use can come apart. In zeroheight's Design Systems Report 2026, which surveyed 147 practitioners, 91% said their system was moderately or highly trusted within the wider product organisation, while 38% described it as widely or fully adopted. Those are self-reported answers, and the report does not say how respondents were recruited, so they are not measured rates, but they show why a placement needs evidence behind it.

Place your system on evidence: a six-area self-assessment

For each area, answer the question using the evidence named, then choose the description that matches what you found. Three levels are enough to decide a next step: not yet, partial and dependable. If you cannot find the evidence at all, mark the area unknown. An unknown is a finding in its own right: the team is making decisions about that area without being able to see it.

Run it with more than the system team. The six-dimension framework recommends four to eight evaluators drawn from the system team, the product teams that use it and its sponsors, each scoring independently before comparing. Bring the evidence into that session, so a wide spread of scores can be settled by looking rather than by debate.

Adoption: do teams ship with it, or just have it installed?

Evidence to pull:

• Imports of shared components per product and per version, from a static scan of the codebase. react-scanner, for example, extracts React component and prop usage from source code into a report.
• Insertions and detaches per component from Figma library analytics, available on Organization and Enterprise plans.
• A list of local forks and copies, with the reason each one exists.

Levels:

• Not yet: one team uses the system; others have built their own versions of the same components.
• Partial: shared components are imported widely, but overrides, copies and old versions are common and nobody can say why.
• Dependable: each product runs a supported version, every fork has a recorded owner and reason, and migrations are tracked to completion.

Productboard's engineering team described how it measured adoption in 2021: component instances over time, deprecated instances still in use, prop usage and migration progress, all from code. It kept screenshot-based coverage as a secondary measure because it was hard to quantify: almost no screen was built only from system components, so each screen needed its own coverage threshold.

Tokens in code: do shipped values come from tokens?

Evidence to pull:

• A search of product code for raw colour, spacing and type values written outside the token package.
• Lint warnings for raw values, if you have them. Productboard, in the same post, wrote ESLint and stylelint rules that warn when a font size, weight or line height is not a token.
• Whether Figma variables and code tokens are generated from one source or maintained by hand in two places.

Levels:

• Not yet: tokens exist in Figma only; code uses typed-in values.
• Partial: a token package exists, but raw values are still common and names differ between Figma and code with no agreed mapping.
• Dependable: one source produces tokens for design and code, semantic tokens carry meaning (such as "danger" or "surface") rather than only raw values, and new raw values are flagged before they merge.

If you are rebuilding a token pipeline, the Design Tokens Community Group published the first stable version of its vendor-neutral token format (2025.10) in October 2025. It is a community group specification, not a W3C Standard, but a shared format makes it easier for design tools and build tools to exchange the same tokens.

Governance: who can say yes or no to a shared change?

Evidence to pull:

• The named owner, or owners, of shared meaning and releases, and whether product teams know who they are.
• Where decisions are recorded, and the last five decisions that changed a shared component.
• Release notes and version history for the past two quarters.
• Whether anyone has protected time to run the system, or works on it when other work allows.

Levels:

• Not yet: nobody owns the system; changes happen when someone finds the time.
• Partial: an owner exists, but decisions are made in conversations that leave no record, and releases arrive without notes.
• Dependable: a named decision owner, recorded decisions, versioned releases with notes, and capacity that survives a busy quarter.

Contribution: what happens when a team needs something the system lacks?

Evidence to pull:

• Requests for new or changed components over the last six months, from issues, tickets or chat.
• For each: time to a decision, and the outcome (added, extended, kept local, rejected).
• Written criteria a requester can read before asking.

Levels:

• Not yet: there is no route; teams build locally and move on.
• Partial: a route exists, but responses are slow or unpredictable, so teams under deadline fork rather than wait.
• Dependable: written criteria, a response time teams can plan around, and every outcome recorded, including "keep it local".

Public systems show what written criteria can look like. The GOV.UK Design System publishes its contribution criteria: a proposal must be useful and unique to be considered, and usable, consistent and versatile before it is published. Contribution is also how a system learns from its products. In interviews with nine design system project leaders (Lamine and Cheng, Empirical Software Engineering, 2022), the leaders favoured a bottom-up approach in which components emerge in products and are then elevated into the shared system.

Documentation: can someone new find when to use a component, not only how?

Evidence to pull:

• The last five questions product teams asked the system team, and whether the documentation already answered them.
• For your three most used components: guidance on when to use and when not to, the states it supports, accessibility expectations and a code example.
• A changelog that says what changed and what consumers need to do.

Levels:

• Not yet: documentation is a component gallery, or a Figma page nobody outside design opens.
• Partial: usage guidance exists for some components, but questions still go to individuals, and it lags behind releases.
• Dependable: the recurring questions are answered in the docs, guidance covers when not to use a component, and docs change in the same release as the component.

Figma and code alignment: do both describe the same component?

Evidence to pull:

• One component family teams argue about, such as a select field or a status badge, compared across Figma, the coded component (or Storybook) and a screen where it ships: variants, properties, states and token mapping.
• Whether components are formally linked. Figma's Code Connect (on Figma's Organization and Enterprise plans, with a Dev or Full seat) shows production code snippets in Dev Mode instead of generated ones, and, by Figma's account, gives its MCP server direct references that help AI agents use the real components.
• Whether coded components are protected against unnoticed change. Storybook's visual tests compare each rendered story with an approved baseline.

Levels:

• Not yet: Figma and code were built separately and disagree on names, variants and states.
• Partial: they mostly agree, but nobody has decided which source governs which decision, and differences surface in QA or after release.
• Dependable: the governing source is agreed per decision, components are linked, and drift is caught by a check rather than by a customer.

Check interaction states and accessibility in the running product as well as in the isolated component; a component can pass on its own and fail inside a real form. If this area is your weakest, Tcules has written separately about keeping a React build true to the Figma design.

Read your profile and decide what comes next

The six-dimension framework's advice is to address the weakest dimension first. We would add one refinement, which is our judgement rather than a published finding: when several areas are weak, start with the one the others depend on. Teams cannot contribute without someone who can decide; they cannot trust a component that differs between Figma and code; and pushing adoption before those are in place asks teams to adopt whatever is currently wrong. Adoption is the outcome the other five areas produce.

Survey answers point the same way. Asked why their design system was not well adopted, respondents to the 2026 zeroheight report put a lack of company mandate (73%) and a weak governance process (55%) ahead of component completeness (45%). The report does not give the base for these figures, which add up to well over 100%, and the answers are self-reported, but for these respondents low adoption looked more like an ownership problem than a build problem.

A lean profile is not automatically a problem. A team with one product and a handful of designers may sensibly stay at partial in documentation or contribution, because the people who would read the docs sit together. Mature means fit for your organisation, not the most elaborate system possible.

Reassess on a rhythm. The six-dimension framework suggests roughly quarterly, or after a reorganisation, a large release or a budget change, compared against your previous result.

Where a maturity score misleads

Counts measure presence, not reliance. Figma library analytics do not track usage in other people's draft files and do not count nested components as insertions. A code scan counts imports, not whether a component's intended behaviour survived local overrides. Productboard found it hard even to define "fully adopted", because product teams legitimately build some components outside the system.

Local variation is not automatically failure. Lamine and Cheng's interviewees described the struggle of keeping a system stable enough to hold shared design knowledge while flexible enough for each product. A fork with a recorded reason and an owner can be the system working as intended. A fork nobody can explain is the warning.

An average hides the failure that matters. One missing state in a status or permission component can cost more support time and customer confusion than dozens of naming differences, yet both lower a score by a similar amount. When you read your profile, ask which single gap is costing product teams most, not only which area scores lowest.

A score from the system team alone can flatter the system. The people who built it see what it offers; the product teams see where it fails them. If product teams score an area well below the system team, that gap is the result worth discussing.

When the evidence points different ways

A self-assessment tells you where the system is weak. It does not always tell you why. A component that teams keep copying might be missing a state, sitting behind a slow contribution route, or serving a need that should stay local, and each cause leads to a different fix.

When you need to separate those causes, trace one component rather than scoring the whole system again. Tcules's Design System Drift Checker walks a team through one component family to see whether its design files, code and running product still agree. Our guide on how to audit a design system covers running a fuller audit yourself.

If the cause is still disputed, the Tcules Design System Audit traces a shared pattern, such as a table, form or status model, through foundations, design assets, code, documentation and the products that use it, and records each finding with its evidence, consequence and owner. It starts from the system, two product areas that consume it and one repeated cost, and it deliberately does not reduce the system's health to one score. It is the complement to a maturity profile: the profile shows where to look, the audit shows what is happening there. If you are deciding whether to bring in outside help at all, read when to hire a design system consultant first.