Design System Maturity Model: How to Assess, Measure & Scale Your Design System in 2025
Here is a question worth sitting with before you read further: does your team have a design system, or does it have a component library?
Most design leaders answer confidently — "we have a design system" — and then describe a shared Figma library with 40 components that may or may not match what is in production. That is not a design system. That is an artifact. A design system is living infrastructure: it includes the components, yes, but also the governance model, the token architecture, the contribution process, the documentation standards, the versioning strategy, and the measurement framework that makes the whole thing useful at scale.
The distinction matters enormously because two teams can both claim "we have a design system" and be four evolutionary levels apart. The team that is genuinely at Level 4 ships new features 30-40% faster, files fewer inconsistency bugs, onboards new designers in days instead of weeks, and has leadership buy-in for continued investment. The team at Level 1 that calls its Figma library a design system is heading for a painful reckoning when the product scales.
This guide gives you a concrete framework to figure out which team you are — and a step-by-step roadmap to advance. You will walk away with a self-assessment scorecard, a clear picture of all five maturity levels, the most common anti-patterns that trap teams at each stage, and the metrics that prove design system ROI to the people holding the budget.
Why Maturity Models Matter for Design Systems
Design systems do not fail because of bad components. They fail because of bad governance.
In the 2021 InVision Design Systems report, 56% of teams surveyed said they had a design system in place. Fewer than 20% described it as mature. That gap — 56% claiming ownership, fewer than 20% claiming maturity — represents an enormous amount of misaligned investment. Teams are spending time building component libraries and calling the work done, without ever building the operational infrastructure that makes those components actually valuable.
The compounding ROI argument is the most compelling reason to think in terms of maturity rather than just capability. Each level of maturity does not add linear value — it multiplies it. A team at Level 2 (Emerging) saves some designers some time on some projects. A team at Level 4 (Managed) eliminates entire categories of duplicate work, compresses design-to-production cycles, and creates a feedback loop where every improvement compounds the next one. Research from Figma's State of Design Systems studies consistently shows that teams operating mature, governed design systems report 40-60% reductions in duplicated UI work. That is not a small efficiency gain. At scale, that is the difference between shipping a feature in two weeks and shipping it in four.
The other reason maturity models matter is navigation. Without a clear framework, teams do not know what they are optimizing for. They add components when they should be adding governance. They invest in documentation tooling when the real gap is adoption. A maturity model gives every design system practitioner a shared vocabulary and a clear picture of what "better" actually looks like.
The Five-Level Design System Maturity Model
Level 1: Ad-Hoc
At Level 1, there is no shared system — only shared assumptions. Every designer builds their own components from scratch, often starting from the same general visual direction but diverging significantly in the details. The "design system" at this level is typically described as "we all use the same brand colors" or "we have a loose style guide in a Confluence doc that nobody has updated since 2022."
What it looks like in practice:
- Five designers produce five slightly different button styles across five product areas
- Developers re-implement the same UI patterns repeatedly because there is no trusted source of truth
- Every brand refresh requires a manual audit of hundreds of screens to find every affected element
- New designers spend weeks reverse-engineering existing patterns to understand "the way we do things"
Typical team size and structure: Early-stage startups, teams of one to three designers, organizations where design is still proving its value to the business.
Common pain points: Massive inconsistency between product areas, crushing rework during brand refreshes, onboarding friction for every new team member, no leverage — effort does not compound.
What it takes to advance: Resist the urge to build a comprehensive system from day one. Start by documenting the implicit patterns that already exist. Use Figma's component audit plugin to catalog every unique button, input, and card variant currently in production. Then build a shared Figma library with the top 20 most-used components — the ones that appear on nearly every screen. Establish basic color and typography tokens. Get the library pinned to all team projects and hold a single kickoff session to explain what it is and why it exists.
Level 2: Emerging
At Level 2, a shared library exists — but it is fragile. One designer owns it as a side project, usually wedged between feature work. Figma components are defined, some are documented, and there is broad awareness that the library is the right place to start. But the codebase has not caught up. Developers either do not trust the library or do not know it exists, and there is no versioning strategy, so breaking changes are invisible.
What it looks like in practice:
- The shared Figma library is used by design but largely ignored by engineering
- Components drift between design and code — the button in Figma has eight variants, the button in code has three
- No token layer, so the library is full of hardcoded hex values that have to be manually updated everywhere
- Contribution is ad-hoc: a designer adds a component when they need it, without review or documentation
- When the library owner goes on leave, the system quietly stalls
Typical team size and structure: Post-Series A startups, four to ten designer teams, organizations where design has recently gained credibility but has not yet secured dedicated tooling investment.
Common pain points: Library drifts from code; low adoption because engineers do not trust the components; no versioning means consumers cannot safely upgrade; the system depends entirely on one person's willingness to maintain it in their spare time.
What it takes to advance: Assign dedicated ownership — even 20% of someone's time is a step change from the current model. Establish a token layer using the Figma Variables plugin or Style Dictionary so that design decisions are represented as named values, not hex codes. Build a basic Storybook with code equivalents of your most-used components. This is also the stage to begin connecting with adjacent topics like design tokens in Angular with Figma and Style Dictionary, which unlock the code-design parity that Level 2 systems chronically lack.
Level 3: Defined
Level 3 is where a design system starts to feel real. There is a documented component library with usage guidelines, a token system that spans at least color and typography, code components in Storybook that engineers actually reference, and meaningful adoption across most product teams. This is also the level where the most common organizational failure modes appear — because the system is now complex enough to be a bottleneck.
What it looks like in practice:
- Engineers use Storybook to find components before building custom ones
- Design tokens are defined and partially applied in the codebase
- Component requests from product teams pile up in a Slack channel, where the core team triages them manually
- Documentation exists but goes stale — the Storybook example shows the old API, the Figma component has been updated, and nobody knows which one is current
- Components accumulate edge-case variations ("galaxy-brained" components that try to handle every possible use case and end up too complex for anyone to use confidently)
Typical team size and structure: Ten to twenty-five designer teams, mid-size tech companies, organizations with dedicated design tooling investment but no formal design system team.
Common pain points: The core team becomes the bottleneck for every component request. Documentation drifts. No metrics make it impossible to argue for more investment. Components become increasingly complex as one-off requests accumulate without a structured contribution and deprecation model.
What it takes to advance: Build a contribution model with an RFC (Request for Comments) process — a structured template for proposing new components or significant changes, with a defined review process and SLA. Add adoption metrics, even basic ones (more on this in the scorecard section). Automate documentation generation using tools like Supernova or Zeroheight so that component documentation stays in sync with the system of record rather than requiring manual updates. If you are building on Angular, the Storybook for Angular design system documentation guide covers the full setup in detail.
Level 4: Managed
Level 4 systems are metrics-driven, contribution-ready, and organizationally supported. There is a dedicated design system team — even if small — with a clear charter, ownership over the token architecture, a semantic versioning strategy with migration guides for breaking changes, and a contribution model that actually gets used. Leadership sees the design system as infrastructure, not overhead.
What it looks like in practice:
- Component adoption rate is tracked — the team knows that 78% of UI surfaces use DS components
- Contributions from outside the core team represent 30-40% of the component library's evolution
- Breaking changes include migration guides and, where possible, automated codemods
- The quarterly design system review includes product and engineering leadership, not just the DS team
- A federated design system model is beginning to emerge: a core team maintains foundations (tokens, primitives, global components) while product teams own domain-specific components and contribute back through the RFC process
Typical team size and structure: Twenty-five-plus designer teams, enterprise organizations, mature product companies. Shopify Polaris, Atlassian Design System, and Material Design are all operated at this level.
Common pain points: Keeping pace with the rate of product team requests without becoming a bottleneck again. Managing token complexity as the system expands to cover semantic tokens, component tokens, and mode tokens (light/dark/high-contrast). Cross-platform parity — maintaining consistent behavior across web, iOS, and Android often requires three different implementations of the same conceptual component.
What it takes to advance: Move from tracking adoption as a proxy metric to tracking downstream impact — how DS adoption correlates with fewer inconsistency bugs, faster design-to-production cycles, and reduced engineering rework. Build a multi-platform token pipeline with a single source of truth. This is also the stage where investing in DesignOps infrastructure pays compounding dividends — if you have not already, the DesignOps scaling guide covers the governance models and tooling stacks that Managed-level teams run on.
Level 5: Optimized
Level 5 is not a destination — it is a state. Optimized design systems are self-sustaining flywheels where adoption drives contribution, contribution drives improvement, and improvement drives more adoption. At this level, the design system is a strategic infrastructure asset that influences product strategy rather than merely executing it.
What it looks like in practice:
- Automated visual regression testing with Chromatic catches UI inconsistencies before they reach production
- Self-service contribution is genuinely operational — engineers outside the core team can propose, build, review, and ship components without white-glove support
- DS ROI is tracked and reported to leadership in business terms: engineering hours saved, inconsistency bugs reduced, onboarding time compressed
- The design system influences product decisions: when a new product area is being defined, the DS team is in the room to assess component reuse and identify gaps
- Continuous improvement loops run on real analytics — Figma component usage data, Storybook story access patterns, and token coverage reports feed directly into the roadmap
Typical organizations: IBM Carbon Design System, Google Material, Shopify Polaris, Atlassian Design System.
Common pain points: Staying relevant as the product evolves — a system optimized for one product era can become a constraint in the next. Managing third-party integrations and accessibility compliance at scale. Navigating organizational politics around ownership when the DS touches every team in the company.
This is a state that requires continuous effort to maintain. Most teams at Level 5 acknowledge that they periodically slip back to Level 4 behaviors in specific domains — a new platform, a new product line — and cycle back up. The maturity model is not a linear progression with a finish line. It is a navigation tool for ongoing organizational work.
The Design System Maturity Self-Assessment Scorecard
Rate your system on each dimension below using a 1-5 scale. Total your score and map it to the level ranges at the end. Be honest — the value of this exercise is in the diagnosis, not the grade.
Foundation (maximum 20 points)
1. Token Layer
- 1 = No tokens; all values are hardcoded in design and code
- 2 = Some color variables defined in code but not connected to design
- 3 = Color and typography tokens defined and used in both Figma and code
- 4 = Full primitive token layer (color, type, spacing, radius, elevation) with semantic aliases
- 5 = Full multi-tier token system (primitive → semantic → component tokens) including mode tokens for light/dark/brand themes
2. Component Coverage
- 1 = Fewer than 10 shared components; most UI is built custom
- 2 = Core atoms defined (button, input, badge) but limited composite components
- 3 = Core UI covered — button, input, modal, navigation, card, table, form — with consistent API
- 4 = Comprehensive library covering atoms, molecules, and patterns with documented variants
- 5 = Library covers all product domains, including domain-specific patterns contributed by product teams
3. Code-Design Parity
- 1 = No code components; design and code are entirely disconnected
- 2 = Some components have code equivalents but they diverge frequently
- 3 = Most Figma components have code equivalents that ship together; API is documented
- 4 = Code and design are synchronized through a documented release process; parity is tracked
- 5 = Automated Figma-to-code sync or token pipeline (Style Dictionary, Tokens Studio) ensures parity at the token level
Governance (maximum 20 points)
4. Ownership Model
- 1 = Nobody owns the design system; updates happen ad-hoc
- 2 = One designer maintains it informally without dedicated time
- 3 = One person owns it with 20-30% dedicated time and some engineering partnership
- 4 = Dedicated DS team (designer + engineer, minimum) with a formal charter
- 5 = Federated model with a dedicated core team maintaining foundations and product teams owning domain components
5. Versioning
- 1 = No versioning; breaking changes are made silently
- 2 = Informal versioning; major changes are announced in Slack
- 3 = Semantic versioning (semver) with a maintained CHANGELOG
- 4 = Semver with migration guides for breaking changes and a deprecation timeline
- 5 = Semver with migration guides, deprecation notices, and automated codemods for major breaking changes
6. Contribution Process
- 1 = No contribution process; only the owner can make changes
- 2 = Ad-hoc contribution; anyone can submit a PR with no review standards
- 3 = Documented contribution process with a review step
- 4 = RFC template with a defined review SLA (e.g., initial response within one week)
- 5 = Full RFC process with template, review SLA, auto-generated documentation from structured component specs
Adoption (maximum 20 points)
7. Adoption Rate
- 1 = Fewer than 20% of UI surfaces use design system components
- 2 = 20-40% adoption; mostly used by teams adjacent to the DS team
- 3 = 50-70% adoption across product teams; some outlier teams building custom
- 4 = 70-85% adoption; outliers are tracked and actively supported toward migration
- 5 = More than 85% adoption; exceptions are documented and time-bound
8. Documentation Quality
- 1 = No documentation beyond the component names in Figma
- 2 = Basic usage descriptions for some components
- 3 = Usage guidelines per component: when to use, when not to use, props
- 4 = Usage guidelines plus code examples, accessibility notes, and do/don't visuals for all components
- 5 = Full documentation including pattern guidance, decision trees, migration notes, and changelog history per component
9. Developer Experience
- 1 = No Storybook or equivalent; developers must read Figma specs directly
- 2 = Storybook exists but is incomplete and often out of date
- 3 = Storybook with basic stories covering primary use cases for most components
- 4 = Storybook with interactive controls, accessibility audit results per story, and usage guidelines embedded
- 5 = Storybook with interactive playground, full prop controls, a11y audit per story, and visual regression testing integrated via Chromatic
Measurement (maximum 20 points)
10. Metrics Tracking
- 1 = No metrics tracked; system health is assessed by gut feel
- 2 = Basic metrics tracked informally (e.g., component count, open issues)
- 3 = Adoption rate tracked on a quarterly basis; contribution volume noted
- 4 = Dashboard with adoption rate, contribution velocity, and bundle impact tracked monthly
- 5 = Real-time dashboard covering adoption, contribution velocity, bundle impact, token coverage, and visual regression failure rate
11. Feedback Loops
- 1 = No formal feedback mechanism; complaints arrive as Slack pings
- 2 = A dedicated Slack channel for questions, monitored inconsistently
- 3 = Slack channel plus a component request backlog visible to all teams
- 4 = Regular office hours, a prioritized backlog from team feedback, and a quarterly satisfaction survey
- 5 = Structured feedback loops including office hours, satisfaction surveys, and analytics on component usage patterns fed directly into roadmap planning
12. ROI Documentation
- 1 = No ROI measurement; investment is justified by faith
- 2 = Anecdotal evidence ("it saved us a lot of time on the checkout redesign")
- 3 = Estimated time savings tracked for major projects
- 4 = Quantified impact on engineering velocity and defect rates, reported quarterly to leadership
- 5 = DS ROI tracked in business terms — engineering hours saved, inconsistency bugs reduced, onboarding time compressed — and used in budget conversations
Scoring Guide
Add your scores across all 12 dimensions (maximum 60 points):
- 12-25 points: Level 1-2 (Ad-hoc to Emerging) — Focus on foundations and basic ownership
- 26-37 points: Level 2-3 (Emerging to Defined) — Focus on documentation and code parity
- 38-45 points: Level 3-4 (Defined to Managed) — Focus on governance and metrics
- 46-52 points: Level 4 (Managed) — Focus on measurement, contribution health, and cross-platform
- 53-60 points: Level 5 (Optimized) — Focus on continuous improvement and strategic integration
The Design System Maturity Roadmap
Your scorecard result tells you where you are. Here is where to focus your next two quarters.
Advancing from Level 1 to Level 2 (Q1-Q2 Focus)
Do not start by building. Start by auditing.
Use Figma's component audit plugin to document every unique button, input, and card variant currently live across your product. Count them. The number is usually alarming — most teams discover 8-12 button variants when they thought they had two or three. That audit becomes your argument for investment and your design brief for the shared library.
- Audit: Document every unique button, input, and card variant across your product surfaces
- Build: Create a shared Figma library with the top 20 most-used components; establish color and typography tokens as the first layer of your design token architecture
- Publish: Pin the library to all team projects; hold a single kickoff session to explain what the library is, why it exists, and how to use it
- Measure: Establish a baseline for your Figma component detachment rate — the percentage of component instances that designers break away from the library before handoff — so you can track improvement
Advancing from Level 2 to Level 3 (Q1-Q2 Focus)
The bridge from Level 2 to Level 3 is built on three pillars: documentation, code parity, and ownership.
- Document: Write usage guidelines for every component in the library — when to use it, when not to, what accessibility behaviors it must support. No component graduates to "ready" without this
- Build: Create code components in Storybook that mirror Figma components precisely. The Storybook for Angular design system documentation guide covers the full setup for Angular teams
- Establish a token pipeline: Use Style Dictionary or the Figma Tokens plugin to connect design tokens to CSS custom properties or SCSS variables. This is the single highest-leverage investment at Level 2 — once tokens flow automatically from design to code, synchronization stops being a manual burden. The design tokens Angular guide with Figma Variables and Style Dictionary covers this in full
- Assign ownership: Secure at minimum 20% of one senior designer's time, dedicated to the design system. Document that commitment formally with their manager
Advancing from Level 3 to Level 4 (Q1-Q2 Focus)
The jump from Defined to Managed is fundamentally about adding governance infrastructure to an already-working system.
- Instrument adoption: Count how many UI elements across your product use design system components versus custom implementations. Even a rough audit done manually once per quarter tells a story that informal estimates cannot
- Write the contribution RFC template: Define the form a component proposal must take, who reviews it, what the criteria for acceptance are, and how long the review takes. Publish it where every designer and engineer can find it
- Introduce semantic versioning and a CHANGELOG: Every release of the component library, however small, should have a version number and a record of what changed. This is the foundation of consumer trust — teams will adopt more readily when they can predict what a library update will affect
- Schedule a quarterly DS review: Bring product and engineering leadership into a 45-minute review each quarter. Present adoption metrics, contribution velocity, and roadmap priorities. This is how the design system graduates from a design team concern to an organizational asset
Advancing from Level 4 to Level 5 (Ongoing)
Level 4 to Level 5 is not a sprint — it is a set of ongoing practices that compound over time.
- Automate visual regression testing: Integrate Chromatic into your CI pipeline so that every component change is visually compared against the baseline. Regressions that previously reached production will now be caught at pull request review
- Build a multi-platform token pipeline: If your products span web, iOS, and Android, establish a single token source of truth — typically a JSON or YAML file in a shared repository — that feeds platform-specific outputs. Style Dictionary handles this transformation. A single token change in the source propagates to all platforms automatically
- Publish a public-facing design system site: Following the model of Polaris, Carbon, or MUI Docs signals organizational maturity to recruits, partners, and the broader community. It also creates an accountability mechanism: a public site is a commitment to maintaining quality
- Track DS ROI in business terms: Work with your engineering and product partners to quantify the impact the design system has on sprint velocity, bug rates, and onboarding time. Present this to leadership. Budget conversations go differently when you can show that every dollar invested in the design system returns measurable engineering hours
Common Design System Maturity Anti-Patterns
Understanding what failure looks like at each stage is as valuable as knowing what success looks like.
The "Museum" Design System is beautifully documented but essentially unused. Every component has a perfect Figma frame, a Storybook story, and three paragraphs of usage guidelines — but component adoption sits at 22% and engineers build custom implementations because the DS components are too rigid for real product use cases. The root cause is almost always that the system was built in isolation, without involving the consumer teams in design decisions. The fix: establish a contribution model and co-design components with the product teams that will use them from day one. A system built with your consumers is a system those consumers trust.
The "Library Masquerading as a System" has components but no tokens, no usage guidelines, and no governance. Developers re-implement every component because they cannot tell which Figma frame is the source of truth, and the Storybook that exists has not been updated since last year. This is the most common Level 2 anti-pattern. The fix is counterintuitive: stop adding components and start adding the governance layer. Tokens, documentation standards, and ownership clarity deliver more value than component 41 through 60.
The "One Hero" Anti-Pattern describes a system that exists entirely in one person's head and one person's calendar. When they go on leave, the system stalls. When they quit, the system collapses. This is not a talent problem — it is an organizational design problem. The fix is a formal ownership charter, a documented contribution process, and a bus factor greater than one. Two people with shared context and documented processes is an institution. One person with no documentation is a single point of failure.
The "Premature Optimization" Trap occurs when a team spends three months designing a perfect three-tier token architecture before any team has adopted anything. The token system is theoretically sound but built on assumptions about use cases that turn out to be wrong. By the time the team is ready to ship, the product has moved on and the token model needs to be redesigned. The fix: launch with a simple, working version of the token layer — even just color and typography — and iterate from real feedback. Perfect is the enemy of shipped, and a 70%-right token system in production generates more useful signal than a 100%-right token system in a Figma file.
The "Invisible ROI" Problem is a governance failure that looks like a business problem. Leadership cuts design system investment because nobody can prove its value in terms leadership cares about. The design system team talks about component count and token coverage while leadership talks about shipping velocity and product quality. The fix is to instrument adoption metrics from day one — even a simple spreadsheet tracking component adoption rate per product team — and to connect those metrics to business outcomes. Tie the design system's adoption rate to the metrics leadership already tracks: time to ship, bug rate, onboarding time. The conversation about budget looks very different when you can show that teams using the design system ship features 25% faster than teams building custom.
Design System Metrics That Actually Matter
Metrics give the design system a voice in organizational conversations where gut feel is not enough. Here is what to track, organized by the questions each category answers.
Adoption Metrics
These answer the question: is the design system actually being used?
- Component adoption rate: The percentage of UI surfaces built using design system components versus custom implementations. A healthy Level 4 system targets more than 80%. Measure by scanning your codebase for component imports and comparing against total UI surface area
- Figma detachment rate: The percentage of design system component instances that designers detach — break away from the library — before handoff. A rate above 20% is a signal that components are not flexible enough for real use cases, or that designers do not understand how to use them properly. Target below 15%
- Token coverage: The percentage of design decisions in both Figma and code represented as named token values versus hardcoded values. Hardcoded values are technical debt that compounds at every brand refresh
Contribution Metrics
These answer the question: is the design system growing in a sustainable, distributed way?
- Contribution velocity: The number of external pull requests or RFC proposals per quarter from teams outside the core design system team. A growing contribution velocity signals that the federated model is working
- Review turnaround time: The median time from RFC submission to a decision (approve, reject, or revise). A target of under two weeks keeps contributors engaged. Longer than a month, and contributors start building custom instead of contributing
- Component request backlog age: The median age of open component requests. A growing median age signals that the core team is becoming a bottleneck — the contribution model needs strengthening
Quality Metrics
These answer the question: is the design system improving product quality?
- Inconsistency bug rate: The number of UI bugs filed per sprint that trace to design system non-compliance or gaps. Track this over time; a mature system should show a declining trend
- Visual regression failure rate: The percentage of Chromatic builds with unexpected visual changes. This metric only applies to teams running automated visual regression testing, but once in place it is one of the most reliable indicators of system health
- Accessibility audit pass rate per component: The percentage of components in Storybook that pass automated accessibility checks (axe-core, Storybook a11y addon). Target: 100%. Any component shipped without a passing accessibility audit is a liability
Business Impact Metrics
These answer the question: is the design system worth the investment?
- Engineering hours saved per sprint: Survey engineering teams periodically to estimate how much time DS components save versus building custom. Compare against the baseline from before the system existed. Even a conservative estimate of two hours saved per engineer per sprint represents significant ROI at scale
- Time from design approval to production deployment: Track this for features built with DS components versus features requiring custom builds. The delta is the efficiency argument for continued investment
- Designer onboarding time to first contribution: How long does it take a new designer to understand the system well enough to contribute meaningfully? A well-documented, mature system should compress this to under two weeks. Compare against your historical baseline
For a deeper treatment of how to build the measurement infrastructure that captures these metrics and connects them to business outcomes, the UX metrics and design impact ROI guide covers the full measurement stack.
The System That Serves Itself
At Level 5, a design system becomes a flywheel. Adoption creates contribution — product teams that rely on the system also improve it. Contribution creates improvement — new components and refined tokens raise the quality of every product built on the system. Improvement creates more adoption — teams that once built custom now reach for the system first because it already covers their use cases.
This flywheel is not automatic. It requires sustained organizational investment, clear ownership, and governance structures that enable contribution without requiring heroics from a single team. But it is achievable — and the maturity model gives you the navigation instrument to work toward it deliberately rather than hoping it emerges on its own.
The maturity model is not a judgment. A team at Level 1 is not failing — they are at the beginning of a valuable journey. A team at Level 3 that has held there for two years without advancing is not broken — they have probably hit one of the common anti-patterns described above, and identifying it is the first step to resolving it.
Use the scorecard this week. Score your system honestly across all twelve dimensions. Identify the two or three dimensions with the largest gaps between where you are and where you want to be. Those gaps are your roadmap for the next two quarters.
If you are building your design system on Angular, the comprehensive guide to building a design system in Angular and the scalable UI/UX design systems guide are the right starting points for the technical foundations. For the organizational and operational layer, the DesignOps guide covers the team structures, tooling stacks, and governance models that mature design systems run on.
The system that serves itself is within reach. The maturity model shows you the path.