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.
Here’s an overview of the four stages of design system maturity.
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.
What do you need to support your design system?
Take the Maturity Model Assessment to get feedback on where you are now, and suggestions that will help you move forward to benefit your whole organization.
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.
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.
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.
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.
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.
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.
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.
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
Origin Story: Top-Down
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.
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.
What’s next for your design system?
Get feedback on where your design systems is now and suggestions that will help your design system further benefit your whole organization with the Maturity Model Assessment.