Two years ago we wrote about why enterprise software needs a design system. Since then we've helped four organisations assess and improve their design systems, and we've continued evolving our own. The most useful thing we've learned is that design system maturity isn't binary. You don't either have one or you don't. There are stages, and knowing which stage you're at determines what to do next.
What You Need to Know
- Design system maturity follows four predictable stages: Ad-Hoc, Managed, Systematic, and Governed
- Most enterprise teams are at Stage 1 or 2 and don't realise it
- Jumping to Stage 4 from Stage 1 fails. Progress is sequential
- The biggest risk isn't having no system. It's having a system nobody uses
Stage 1: Ad-Hoc
This is where every team starts. Components are built per-project. A developer needs a dropdown, they build a dropdown. Another developer on another project needs a dropdown, they build a different one. Both work. Neither is reusable.
What it looks like:
- No shared component library
- Design files are project-specific
- Colours and spacing vary between screens, sometimes within the same screen
- "Consistency" depends on whether the same person worked on both features
What it costs: Developer time on rebuilding solved problems. Design drift that erodes user trust. Onboarding friction when new team members need to learn each project's conventions from scratch.
When it's fine: If you have one project and one team, ad-hoc is manageable. The cost of building a system exceeds the benefit.
Stage 2: Managed
Someone notices the inconsistency and starts collecting components. Usually a designer creates a Figma library or a developer builds a shared component folder. It's a step forward, but it's informal.
What it looks like:
- A component library exists, but usage is optional
- Some projects use shared components, some don't
- The library was built by one person and reflects their preferences
- There's no documentation beyond the code or Figma file
- When the library maintainer goes on leave, it stagnates
53%
of design system initiatives fail to achieve adoption beyond the founding team
Source: Sparkbox Design Systems Survey, 2022
What it costs: Inconsistent adoption creates a worse problem than no system at all. Some screens look governed, some don't. Users notice the inconsistency even if they can't articulate it.
The trap: Most teams get stuck at Stage 2. Building the library feels like progress. But a library without governance, documentation, or adoption strategy is just a folder of components.
A component library that nobody uses is not a design system - it's a hobby project with a Confluence page.
Rainui Teihotua
Chief Creative Officer
Stage 3: Systematic
The design system has documentation, contribution guidelines, and is the default way to build. Components have defined APIs, accessibility built in, and clear usage examples. New team members can be productive with the system within a day.
What it looks like:
- Documented component library with props, variants, and examples
- Design tokens (colours, spacing, typography) defined centrally
- Usage is the default, not the exception
- New components go through a review process
- Design and development share the same language
What it takes: Dedicated time. Someone (or a team, depending on organisation size) needs to maintain the system. Not as a side project. As actual work. This is where most organisations hesitate, because it means allocating people to infrastructure instead of features.
What it delivers: Faster feature development because common patterns are solved. Consistent user experience across the product. Accessibility by default. Reduced design-to-development friction because both sides reference the same source of truth.
Stage 4: Governed
The system is a product. It has a roadmap, a versioning strategy, and a feedback loop with its consumers. It evolves based on actual usage data, not assumptions. Breaking changes are managed. Deprecation is communicated.
What it looks like:
- Versioned releases with changelogs
- Usage analytics (which components are used, which are ignored)
- Formal contribution process for new components
- Regular audits of existing components against accessibility and design standards
- The system team actively removes unused components
Who gets here: Large organisations with multiple product teams. Government digital services. Companies where design consistency is a competitive differentiator.
What most teams don't need: If you have one product and one team, Stage 4 is over-engineering. Stage 3 is the right target for most enterprise teams. Stage 4 matters when you're serving multiple teams across multiple products.
How to Assess Where You Are
Answer these questions honestly:
- If a developer needs a button, where do they look first? (Their own project = Stage 1. A shared library = Stage 2+)
- Is there documentation for your components beyond the source code? (No = Stage 1-2. Yes = Stage 3+)
- When someone builds a new component, is there a process? (No = Stage 1-2. Informal = Stage 2. Documented = Stage 3+)
- Do you know which components are actually used in production? (No = Stage 1-3. Yes = Stage 4)
- Can a new team member build a feature using only the design system in their first week? (No = Stage 1-2. Yes = Stage 3+)
The Path Forward
The critical insight is that you can't skip stages. We've seen organisations try to jump from Stage 1 to Stage 4 by purchasing a design system tool and mandating adoption. It doesn't work. The tool becomes shelfware because nobody contributed to building it, nobody understands its conventions, and nobody feels ownership.
From Stage 1 to Stage 2: Start collecting. Pick one project as the pilot. Extract the common patterns into a shared location. Don't aim for completeness. Aim for usefulness.
From Stage 2 to Stage 3: Add documentation and process. Make the system the default, not an option. Allocate real time for maintenance. This is the hardest transition because it requires organisational commitment, not just technical effort.
From Stage 3 to Stage 4: Add measurement and governance. Version your releases. Track usage. Build a feedback loop. This only makes sense when you have multiple teams consuming the system.
Where We Are
Honestly, we sit between Stage 2 and Stage 3. Our internal design system has good components, decent documentation, and reasonable adoption across projects. But we don't have formal contribution processes or usage analytics. For a team our size, that's appropriate. If we grow significantly, we'll need to push to Stage 3 properly.
The point isn't to be at Stage 4. The point is to know where you are, know where you should be, and take deliberate steps to get there.