Design System Maturity Model

Systems have always been an important part of what we do at Sparkbox—from the branding systems we worked on in our early days to the current modular systems we use when writing software today. In 2015, we began to build a large-scale, multi-brand design system for one of our clients. For us, this was the culmination of years of previous work. We started the Design Systems Survey in 2018 as a way to capture data about these systems from around the world. Over the last year or two, I’ve been privileged to supplement the quantitative survey through a series of qualitative conversations with some brilliant folks solving similar problems with design systems.

After years of research and interviews, we’ve documented a more complete model of the way organizations approach design systems, including how they’re initiated and how they mature over time. This article is a high-level explanation of that model.

Model Overview

The Stages

Here’s an overview of the four stages of design system maturity.

Stage 1: Building Version One

This is the very earliest stage of a design system, beginning with a specific problem (for example, inconsistent experiences or inefficient processes) and ending with the first release. There are a lot of decisions to be made during this phase, such as technology selection, initial component definition, and what tools and frameworks will be supported.

Stage 2: Growing Adoption

Once an initial design system is in place, the critical challenge is adoption. In order for the system to succeed, the owners need to educate a growing number of internal team members (potential subscribers) about the system and persuade them to use it.

Stage 3: Surviving the Teenage Years

When the design system is part of the day-to-day rhythm of the organization, there’s a new set of issues to address, including enforcing standards while allowing for creativity, assessing and prioritizing growth, and analyzing return on investment.

Stage 4: Evolving a Healthy Product

In this final stage, the design system is a fully-realized product. The focus turns to long-term sustainability, growth, and governance, often with highly evolved communication and product management strategies.

Origin Stories Matter

As I immersed myself in these ideas, I wanted to make sure I understood what had already been done in this space. One of the biggest missing pieces I’ve seen is a failure to consider the major impact of a system’s origin. Based on my interviews with design system leaders, the approach taken to release the first version makes a big difference in the priorities and challenges the team will experience. The two major approaches I’ve seen are “grassroots” (a passionate individual contributor drives the initial release) or “top-down” (an executive drives the work from the beginning). I’ve done my best to demonstrate how these two different origin stories typically affect the maturity path a system takes. And I’m almost certain that there are an infinite number of combinations between these two.

A Maturity Model for Design Systems

With all this context, let’s dive a little deeper.

Stage 1: Building Version One

Decisions, decisions. We make many compromises early in the life of a design system. We have to choose which technologies we’ll support, what components to include initially, any tooling we want to use, and more. These decisions are often rushed, and the people working on the system usually struggle to find the right priority and scope for their organization.

Top Priorities

• Release version one

• Find a balance between releasing quickly and showing value

Top Challenges

• Discover the most valuable first release

• For the top-down origin story: find cross-discipline partners

• For the grassroots origin story: find time to work on the system

What to Measure

• Qualitative value of the system for the first round of subscribers

Organizations in this phase are primarily working toward releasing the first version of their system. So they don’t have a system in place already (or they are replacing whatever they do have). There is usually a conversation about how to balance the speed at which they can release with the value version one needs to show in order to last. Where the line is drawn and how to get there are heavily influenced by the origin story, especially in this earliest stage.

Origin Story: Grassroots

Early in the history of design systems, almost every system was started by passionate individual contributors. Because the industry didn’t really know what design systems were or the extent to which they could benefit an organization, a grassroots approach was much more common. As design systems become more widely understood and valued, the “grassroots” origin story is less and less common.

Grassroots Origin Characteristics

• Very informal or no budget (this is a side project)

• A single person or very small, unsanctioned group creating the system

• Requirements, process, and tools determined by the creator

• Limiting the scope to what helps the creator (also the likely future subscriber)

• Low pressure to deliver

Origin Story: Top-Down

There is enough industry momentum behind design systems now that executives are more easily swayed. Many times they see their peers pushing for a more systematic approach, so they do the same. When a system is started because an executive believes it’s the right thing to do, the path is different.

Top-Down Origin Characteristics

• A more formal budget

• A formal team (recruited from within, new hires, or an outside consultant)

• Requirements, processes, and tools determined by committee

• A broad scope focusing on subscribers outside the creator team

• High pressure to deliver

Because the “top-down” story is driven by leadership and the scope is usually more about the impact a system can have across the organization, this stage often includes a Discovery-like phase—interviews with stakeholders, audits of existing experiences, and conversations about tooling and workflow with future subscribers.

Once the organization has a first version released, things get fun!

Stage 2: Growing Adoption

Once we have a working system, creators get excited to show its value. The easiest way to show a design system’s value is to show that people want to use it. That’s why this stage is clearly defined by the overwhelming sense of urgency to get other people to use the system.

Top Priority

• Demonstrate that multiple teams will use the design system

Top Challenges

• Increase the number of subscribers

• Prioritize improvements to the system that show value to potential subscribers

What to Measure

• Adoption of the system

• Implementation variations from the documented patterns

In almost all cases after the initial release, no one will be using the system simply because it’s new. Releasing a design system is essentially asking everyone to change how they work. This change takes time, and there are multiple paths to drive adoption. I’ll share the most common path I’ve observed for each origin story.

Origin Story: Grassroots

At this point, the creator is thinking “This works really well for me—maybe it will be helpful for others too.” They share the system with friends in the organization, and early adopters start using it, providing feedback, and encouraging others to see the value/adopt the system as well. These early adopters often support improving the design system by contributing back.

Grassroots Origin Characteristics

• The creator wants to allow others to use the system

• The creator seeks out friendly early adopters (typically in similar roles)

• If there is genuine value, early adopters will start using it

On the other hand, if there isn’t much demonstrable value at this stage, a system may simply fade away or remain a small tool in the back pocket of a few passionate folks.

Origin Story: Top-Down

In this origin story, the executive sponsor is thinking “We’ve invested in this—I must show immediate organizational value.” Many times they mandate that others use the system. This works, but the mandate for adoption tends to crush the collaborative spirit, often removing subscriber desire to contribute back to the system. Instead, they let the owners of the system know when it’s not working and wait for a new version.

Top-Down Origin Characteristics

• The executive sponsor wants to allow others to use the system

• Leadership mandates that everyone must start using the system, and teams will typically do what they’re told

• If there is genuine value, teams will start using it and often offer ideas for how the system could better serve them

The real challenge comes when the system doesn’t do much for people and yet there is a mandate that they use it. In this scenario, a lot of resentment can grow, leading the system to be built on an unhealthy and unsustainable foundation.

But if the system persists and adoption grows, scaling to support these new subscribers often leads to other disciplines participating in the work. The organizations that succeed at this stage start conversations with more than just designers and developers. They are thinking about the entire product lifecycle, and that big vision is contagious. How far a system can scale is dependent on (1) the work done initially to determine the scope of the first release and (2) the cultural willingness of an organization to evolve their processes.

Stage 3: Surviving the Teenage Years

If a design system successfully grows adoption, it eventually becomes a known tool inside the organization, and adoption is no longer the top concern. Increased awareness means more eyes are on the system, and questions about its validity are surfaced.

Top Priorities

• Demonstrate the value of the system to leadership

• Begin to build deeper engagement with subscribers

• Evolve the system to better serve a variety of subscribers

Top Challenges

• Continue to add valuable patterns, integrations, and documentation

• Balance flexibility with consistency

• For the top-down origin story: maintain funding

• For the grassroots origin story: find executive support

What to Measure

• Efficiency of product design and development process

• Consistency of products built with the system

• Accessibility regressions

Metrics play a key role in ensuring the survival of a teenage design system. But it’s also critical the system is seen as an enabling force, not a restricting one. This is where design system teams from either origin story are tasked with finding a healthy balance between the flexibility a system offers and the consistency of the products built with it.

Origin Story: Grassroots

Grassroots Origin Characteristics

• Metrics become the path to executive support and a dedicated, cross-discipline team

• New, heightened pressure to meet growing expectations

• Resisting the urge for the system to lean too far toward consistency by removing flexibility

Origin Story: Top-Down

Top-Down Origin Characteristics

• Metrics required to continue the funding and growth of a team

• Increased pressure to prove original expected value and possibly growing expectations

• Resisting the urge for the system to lean too far toward flexibility by removing consistency

The metrics leadership asks for in this stage are notoriously difficult to capture, so this can be a challenging time for a system. Every system is unique, but I share measurement advice in this A List Apart article. Here are a few more resources: Measuring Design System Success, Interview on GitHub’s Design System, and How to Understand your Design System’s Health.

When a system is adopted because it has shown real value, this often changes how the organization works, how the various groups inside the organization communicate, and sometimes even how teams are structured. These changes can create a healthy dependence on the system and a sense that the system has been the initiator of necessary improvements in the product development process.

When leadership is convinced the system is meeting the promises made in earlier stages, and when the system is seen as an enabler by a growing set of subscribers, it can evolve to become a truly valuable internal product.

Stage 4: Evolving a Healthy Product

Reaching this stage means the product mindset is fully realized—the organization values the system as much as other customer-facing digital products. The origin story no longer bears a heavy influence on how these teams work because they have the same tools, processes, budgets, structures, and roles as the larger organization.

In this stage, the long-term health of the system becomes a priority. A healthy product also means healthy teams and a well-supported user base. This means the organization is focused on contribution models, regular subscriber interviews, and ambassador programs, all in an effort to better understand their users and continuously add value to the system.

Top Priorities

• Establish the design system as a full-fledged product

• Spread design system value to all disciplines in the product life cycle

• Support subscribers

Top Challenges

• Establish healthy governance and contribution models

• Ensure your system remains an enabler and not a restrictor

• Stay relevant as the organization and products evolve

What to Measure

• Subscriber engagement (adoption of new releases, variance from core system, etc.)

• Onboarding speed and effectiveness

• Process and cultural changes driven by the system

• Product metrics for the system (velocity, release cadence, etc.)

This stage is characterized by a cross-disciplinary team that cares about measuring the engagement of their subscribers, the rate at which new releases are adopted, and much more. These teams create product roadmaps, incorporate feedback from all disciplines, and regularly demonstrate how the system can be helpful at every decision point in the product life cycle. They’re faster to market and create more consistent experiences for their users. They understand the benefits of working in this way and know how to demonstrate those benefits by looking at their own history.

Please Share Your Story

This framework has helped me understand where folks are in the process and what they should be focused on in order to continue maturing their system. Ultimately, this kind of thinking is only helpful if it allows all of us to see things more clearly. So far, I’ve felt that. The understanding of why we need to focus on adoption early, the shifting priorities around what to measure, the end goal of a cross-discipline team treating the system like the true product that it should be—all of these ideas are critical to the work we’re all doing. My hope is that this framework removes some of the mystery, and maybe that it even gives young teams an idea of what they can expect.

Now, I need your feedback.

As you read this, which stages did you identify with? Or maybe you followed a different path? Regardless, we want to hear your story. To this end, we’ve made a very short form where you can share as much or as little information as you’d like. Please, please, please, take just a few minutes to share your story.