Five stages every
system passes through.
Every design system passes through the same five stages — ad hoc, managed, defined, optimized, adaptive. Knowing which one you're in tells you what to build next. Skip a stage and the tooling has nothing to support.
01 — Five stages
From copy-paste to platform.
The five-stage progression compounds. Each rung earns the next: tokens enable components, components enable measurement, measurement enables tooling, tooling enables multi-brand. Skip and the next rung has nothing to stand on.
Ad hoc
30% capability
Designers copy-paste from old files.
No system, no tokens, no shared library. Each feature ships its own buttons, its own spacing, its own color values. Pixel-pushing in Figma replaces architecture.
Signals
- Components live as detached frames in Figma
- Engineers re-implement the same modal three times
- Colors come from screenshots, not from tokens
- The word "library" hasn't been used in a meeting yet
Managed
47% capability
A few primitives exist — and people use them sometimes.
A starter palette, basic type scale, maybe a Button component. Adoption is informal — usage depends on whether the designer remembers the library exists.
Signals
- Figma library with 5–15 components
- Color and type tokens exist in code
- Buttons and inputs are consistent · cards aren't
- No documentation beyond the Figma file
Defined
64% capability
Tokens are the source of truth — and adoption is tracked.
A full token system in W3C format. 20–40 components. Documentation site. Released as a versioned package. Adoption is measured monthly, not vibes.
Signals
- Tokens shipped to Figma + code from one source
- Component library at semver 1.0+
- Storybook or docs site with every component
- Adoption metric on a quarterly report
Optimized
81% capability
The system runs itself — and the team measures the loop.
Automated visual regression. Token transforms (Style Dictionary). Contribution model. A11y audited in CI. Migrations are tooled. The team operates the system instead of building it.
Signals
- Visual regression in CI on every PR
- Token round-trip Figma ↔ code automated
- External contributions accepted via RFC
- Per-component a11y test gates merges
Adaptive
98% capability
The system shapes the product, not the other way around.
Multi-brand or multi-product. Token themes are runtime-swappable. The system has its own roadmap, its own users, its own release notes. Product teams build composed experiences from a stable platform.
Signals
- Multiple brands themed from one token graph
- Per-product extensions composed from primitives
- MCP / agents can read the system as data
- System has its own users, surveys, and metrics
02 — Diagnose
Nine yes/no questions land your stage.
Walk the list top-down. The first "no" is your current stage — keep answering to find where the system is strongest and weakest. Most real systems live at different stages per dimension (tokens at Defined, components at Managed); treat this as a heatmap, not a single number.
Heuristic
The lowest dimension caps the system. A team at Optimized on tokens but Managed on components is a Managed system overall — the optimized tokens are wasted on inconsistent consumers.
03 — Move up one stage
Concrete moves per transition.
Each transition has a small number of concrete moves that earn the next stage. Pick the next stage above you, do all four moves, then re-diagnose. Trying to skip to Adaptive without the foundation underneath is the most common reason systems stall.
01
Ad hoc → Managed
- Centralize the palette · pick five hues × eleven steps
- Build a Figma library with the five most-used components
- Lock the type scale to eight steps
- One designer owns the file — and is allowed to say no
02
Managed → Defined
- Ship tokens in W3C JSON · pipe to Figma and code
- Cover the top 20 components in a versioned package
- Stand up a documentation site (Storybook or custom)
- Add an adoption metric to the quarterly review
03
Defined → Optimized
- Visual regression on every component PR
- Style Dictionary or equivalent for token transforms
- RFC process for new patterns · published in repo
- axe-core + Lighthouse a11y in CI · merge gates
04
Optimized → Adaptive
- Theme tokens runtime-swappable · multi-brand pilot
- MCP server exposes the system to agents
- Per-product extension points · plugin model
- System gets its own user research + roadmap
04 — Anti-patterns
Four ways the maturity model gets misread.
The model is most useful as a diagnostic — and most damaging when used as a score. These four anti-patterns are how a useful tool becomes a status game.
Skipping stages
Avoid
Building MCP at Managed stagePrefer
MCP at Optimized · once tokens are stableEach stage builds the foundations for the next. Skip Defined and the Optimized tooling has nothing to optimize. The stages aren't a ladder you sprint up — each one earns the next.
Stage as identity
Avoid
"We're a level-4 design system"Prefer
"We're at Defined on tokens · Managed on components"Different parts of the system live at different stages. The headline number hides where the actual work is. Diagnose by capability, not by aggregate.
Tooling without practice
Avoid
Style Dictionary installed but unusedPrefer
Style Dictionary running in CI with token round-tripAdoption matters more than installation. A repo full of tooling that nobody runs is still ad hoc. The stage is the behavior, not the dependencies.
Static maturity
Avoid
Audited once · filed awayPrefer
Re-assessed each quarter · plotted over timeSystems regress. A team change, a rebrand, a refactor — any of these can drop a capability back two stages. Run the diagnostic regularly; treat the model as a dashboard, not a certificate.
Continue
You've mapped the destination. The playbook is the road.
The 90-day Build playbook walks the path from Ad hoc through Defined. Eight chapters, three time-budget entry points, every decision sequenced by day.