Language EN DE

Design System Maturity Check

A 24-question self-assessment across documentation, versioning, governance and adoption. Derived from recurring criteria in the Sparkbox and Rangle design-system maturity models, Nathan Curtis' governance writing, the InVision Design Maturity Model and the CMMI level logic.

Step 1 of 4

Documentation

Can someone use the system correctly without talking to the team that built it?

Skip any question you cannot answer yet — it will not count against you.

How many of your released components have usage documentation (what it is for, when not to use it, props/API)?

Question 1

How many of your released components have usage documentation (what it is for, when not to use it, props/API)?

Coverage of usage docs is the single strongest predictor of whether teams adopt a component without asking the core team.

Almost none — knowledge lives in people's heads and in chat threadsSome components, written when someone had timeMost components follow a documentation templateAll components — docs are part of the definition of doneAll components, and CI fails a release when docs are missing

Do you document design guidance (do's and don'ts, content and layout rules) alongside the code API?

Question 2

Do you document design guidance (do's and don'ts, content and layout rules) alongside the code API?

Prop tables tell developers how to call a component. Guidance tells everyone when it is the right one.

No, code API onlyScattered across slide decks and Figma commentsIn the docs site for the most-used componentsConsistently, in a fixed structure per componentConsistently, plus examples of real product usage and anti-patterns

Is accessibility behaviour documented per component (keyboard interaction, roles, known limitations)?

Question 3

Is accessibility behaviour documented per component (keyboard interaction, roles, known limitations)?

Undocumented a11y behaviour is re-implemented — usually incorrectly — by every consuming team.

Not documentedMentioned occasionally when someone askedA dedicated accessibility section exists for most componentsComplete, including keyboard maps and known limitationsComplete and backed by automated a11y tests referenced in the docs

Can someone see and interact with a live example of a component without cloning your repository?

Question 4

Can someone see and interact with a live example of a component without cloning your repository?

A running example removes the largest single barrier to trying a component.

No, examples exist only in the codebaseStatic screenshots and code snippetsA component workshop (e.g. Storybook) that runs locallyA hosted docs site with live, editable examplesHosted, editable, and available per released version

Is there a written getting-started path for a new team that wants to use the design system?

Question 5

Is there a written getting-started path for a new team that wants to use the design system?

Install, theme, first component, where to ask — the four things every new consumer needs on day one.

No, onboarding happens in a call with the core teamA README with install instructionsA written guide covering install, theming and a first componentA guide that is walked through and corrected with each new teamA guide plus a runnable starter template or scaffolding command

How do you keep documentation from going stale as the code changes?

Question 6

How do you keep documentation from going stale as the code changes?

Stale documentation is worse than none: it is trusted and wrong.

Nothing specific — it drifts and we fix it when someone complainsOccasional cleanup sprintsDocs changes are part of code reviewAPI docs are generated from source, prose has a named ownerGenerated and enforced: broken links, missing sections and outdated examples fail CI

Step 2 of 4

Versioning

Can the system change without breaking its consumers by surprise?

Skip any question you cannot answer yet — it will not count against you.

How is the design system distributed to product teams?

Question 1

How is the design system distributed to product teams?

Distribution decides everything downstream: you cannot version, deprecate or measure what teams copy and paste.

Copy and paste, or a shared folderA git submodule or a branch teams pull fromA versioned package from a registryVersioned packages with a documented upgrade path per releaseVersioned packages, and you know which version each product runs

How disciplined is your use of semantic versioning?

Question 2

How disciplined is your use of semantic versioning?

SemVer is a promise about breakage. Its value comes from being kept every single time.

We do not version releases in a structured wayWe bump versions, but the increment is a judgement callSemVer is applied deliberately by the releasing personSemVer is declared in the pull request and checked in reviewVersion bumps are derived automatically from changesets or commit metadata

Do consumers get a changelog they can act on?

Question 3

Do consumers get a changelog they can act on?

"What changed and do I have to do anything?" — answered before anyone has to ask.

No changelogThe git history is the changelogA hand-written changelog per releaseGenerated per release and grouped by impactGenerated and actively pushed to consumers with upgrade notes

Is there a deprecation policy with a defined window before removal?

Question 4

Is there a deprecation policy with a defined window before removal?

A predictable removal window is what lets product teams plan instead of firefight.

No policy — things are removed when they are removedWe announce removals informally, without a fixed periodA written policy with a minimum deprecation windowWritten policy plus runtime or build-time deprecation warningsWarnings plus tracking of who still uses the deprecated API before removal

How well are the design source of truth (e.g. Figma library) and the code release kept in sync?

Question 5

How well are the design source of truth (e.g. Figma library) and the code release kept in sync?

Two sources of truth that drift apart create the most expensive kind of rework: silent disagreement.

They drift freely; nobody knows which one is currentDesigners update the library when they remember toDesign and code changes are released as a pair by conventionShared design tokens flow from one source into bothToken pipeline plus an automated check that flags divergence

What support do teams get when a major version requires them to change their code?

Question 6

What support do teams get when a major version requires them to change their code?

Migration effort that is not budgeted by the system team is silently paid by every product team, several times over.

None — each team figures it outA short note in the release descriptionA written migration guide per major versionMigration guide plus codemods for the mechanical partsCodemods plus the system team opening the upgrade pull requests

Step 3 of 4

Governance

Is it clear who decides what, how work enters the system, and what 'done' means?

Skip any question you cannot answer yet — it will not count against you.

Who owns the design system, and how is that ownership funded?

Question 1

Who owns the design system, and how is that ownership funded?

Funded ownership is the difference between a product and a side project that survives until the next reorg. In a small organisation the top options may simply not apply — answer for the arrangement you have, not the one an org chart would allow.

Nobody formally — enthusiasts maintain it next to their day jobA named group, but without protected timeA team with a formal part-time allocationA dedicated, funded team with a product ownerA funded core team plus formally recognised federated contributors

How can a product team get a change into the design system?

Question 2

How can a product team get a change into the design system?

Nathan Curtis' models — solitary, centralised, federated — differ mainly in how a contribution travels. Any of them works; not having one does not.

Unclear — they ask around or build their own versionThey file a request and wait for the core teamA documented contribution process exists and is used occasionallyContribution is routine, with review support from the core teamA federated model with trained reviewers in the product teams

How are incoming requests prioritised?

Question 3

How are incoming requests prioritised?

Without visible prioritisation, the loudest team sets the roadmap and everyone else stops asking.

Whoever asks most insistentlyA backlog exists, ordering is intuitiveWritten intake criteria (reuse potential, number of affected teams)Criteria plus a regular, visible triage cadenceTriage in public, with the decision and its reasoning fed back to the requester

Is there a definition of done that a component must meet before it is released?

Question 4

Is there a definition of done that a component must meet before it is released?

A component checklist (a11y, tests, docs, tokens, responsive behaviour) is the cheapest quality gate a system team can own.

No — it ships when it looks rightAn implicit standard the core team carries in their headsA written checklist used during reviewChecklist with the mechanical parts automated in CIAutomated gates block the release, with a documented exception path

Are significant decisions recorded somewhere others can read later?

Question 5

Are significant decisions recorded somewhere others can read later?

Undocumented decisions get relitigated every six months, usually by new people with the same good arguments.

No, decisions live in meetings and chatMeeting notes that are hard to searchDecision records for the bigger callsDecision records linked from the affected components and docsDecision records plus a publicly visible roadmap consumers can comment on

How is accessibility governed — who signs a component off as accessible?

Question 6

How is accessibility governed — who signs a component off as accessible?

A design system multiplies whatever it contains. An inaccessible component becomes an organisation-wide defect.

Nobody — it is handled per product, if at allIndividual goodwill inside the teamAutomated checks (linting, axe) run in CIAutomated checks plus manual keyboard and screen-reader review before releaseReviewed in-house and independently audited on a fixed cadence

Step 4 of 4

Adoption

Is the system actually used in production — and do you know how much?

Skip any question you cannot answer yet — it will not count against you.

Roughly what share of your product interfaces is built with design-system components?

Question 1

Roughly what share of your product interfaces is built with design-system components?

Adoption share is the outcome metric. Everything else in this check is an input to it.

Less than 25%Roughly 25–50%Roughly 50–75%Roughly 75–90%More than 90%, with documented exceptions

How do you know that number?

Question 2

How do you know that number?

An estimated adoption rate cannot be steered. A measured one turns the system from a cost centre into a reportable asset.

We are guessingSomeone counted manually, onceA periodic scan of the codebasesAutomated component usage analytics per productA live dashboard that leadership and product teams both look at

What enablement do teams get beyond documentation (training, office hours, pairing)?

Question 3

What enablement do teams get beyond documentation (training, office hours, pairing)?

Documentation answers known questions. Enablement surfaces the questions people did not know to ask.

NoneAd-hoc help when someone reaches outA structured onboarding session for new teamsOnboarding plus recurring office hours or pairing slotsA running enablement programme with champions embedded in the product teams

Where do consumers go when something is broken or missing, and how quickly do they get an answer?

Question 4

Where do consumers go when something is broken or missing, and how quickly do they get an answer?

Support latency is the most direct signal of whether the system feels like a product or a favour.

Direct messages to whoever they knowA shared channel, answers when someone is freeA tracked issue queue with a named triagerA published response expectation that is usually metResponse and resolution times are measured and reviewed

How do you handle teams overriding, forking or detaching components?

Question 5

How do you handle teams overriding, forking or detaching components?

Overrides are data, not misbehaviour: each one marks a gap the system has not covered yet.

We do not know it is happeningWe hear about it anecdotallyOverrides are visible in review and discussedOverride and detach rates are measured per productMeasured and routed back into the roadmap as feature requests

How is the design system positioned by leadership?

Question 6

How is the design system positioned by leadership?

Adoption stalls at the point where using the system costs a team more than ignoring it — that trade-off is set above the team.

Largely unknown outside the immediate teamsTolerated as a nice-to-haveActively encouraged, but optionalThe expected default, with deviations needing a reasonA tracked strategic asset with adoption goals in team objectives

Nothing here yet.

Answer at least one question and come back.