How mature is your design system?
A model to identify the different stages of design system maturity to support healthy evolution and growth.
Shortly after I joined the community Into Design Systems hosted by Silvia Bormüller, I attended an incredibly fascinating talk discussing applying a maturity model to building your design system by Ben Callahan. His framework offers clarity to those seeking context and direction when starting their design system journey.
But before we start, let’s unpack what defines a design system? A set of patterns, principles, and guidelines to enable design at scale — a shared language for all involved in designing and building products.
Design systems are comprised of four essential layers:
- Foundations define a subset of the organisation’s brand elements for designing and developing digital interfaces.
- Tokens take the design concepts expressed in the Foundations Layer and codify them for use in constructing digital interfaces.
- Core Systems offer solutions to common interface challenges such as layout, type scale, theming, etc. The simplest way to think of this is that codifying a single design decision results in a token, but codifying how those design decisions work together is a core system.
- Components function to specify and make accessible the reusable components of a digital interface. These can range from simple (a button or text input) to complicated (a header or navigation). They are constructed from foundations, tokens, and core systems when correctly created.
And to unpack further, these four layers each require three parts that work together to make a design system functional, educational, and sustainable. Those parts are Assets, Documentation, and Processes. But before I get hung up on these, let’s get back to the point of this article, the maturity model.
The maturity model
At first, Ben explained that there are four stages of maturity when you build your design system. Further steps follow these to help form stability once you have matured the approach to the point of impact within an organisation. Let’s start with the four stages.
Four stages of design system maturity
Building version 1 — The very earliest stage of maturity includes all the activities leading up to and including the first release. This stage can look wildly different depending on many factors, and it’s important to know that the decisions you make early on will significantly impact how the system matures. At its core, this stage is about discovering the right scope for your organisation, casting the vision for the design system, identifying the best partners, and learning from them to enable you to build something valuable for them.
Growing adoption — This stage begins as soon as you release your first official version. As soon as the first version is live, the primary focus shifts to getting teams to adopt it and how it works in the wild with those subscribed to the system. It’s about learning what will be valuable to new subscribers while supporting those already using the system.
Surviving the teenage years — This stage begins when you’ve reached the critical mass of system adoption. A new set of challenges can arise. More subscribers can lead to more bugs discovered. More feature requests can add strain to the releases. You will find teams using the system in ways you never imagined, all while being asked to prove the system is keeping the promises made quantitatively in stages 1 and 2. Stage 3 is complicated; you will need to demonstrate how you intend to support teams using the system and figure out how to allow others to contribute to the system to support its growth. Communication is vital to ensure the governance for contribution is clear about the process.
Evolving a healthy product — The focus shifts towards growth and sustainability. At stage 4, there is usually a highly involved engagement with subscribers. You need to pay attention to the forces of change around the organisation and put stabilisers in place to ensure the design system can last. When you are in this stage, many disciplines across the organisation see the design system as the way to design and build products.
The experiences different organisations have as they move through these stages can be very different. However, applying the next concept impacts how a system matures, and looking at maturity through these lenses helps identify patterns. That concept is origin stories.
Origins stories
These are one of the cornerstones that guarantee the maturity of the design system. How the first release is handled makes a big difference in the priorities and challenges that the team face. The two main approaches to origins stories are:
Top-down — executive leadership are involved, aware, and actively supportive of the initiative.
Grassroots — executive leadership were uninvolved, unaware, or unsupportive towards the initiative.
To know which origin story will support your design system, consider how leadership was involved early on. Here is how to think about the differences.
Top-down — With executive leadership’s involvement, there will be more pressure on the initiative early on.
- You will be more visibility across the organisation
- Formal budgets dedicated to the mission
- A sanctioned team
- Broader scope to deliver value to multiple parts of an organisation requires results
- Higher level of pressure to deliver the system
Grassroots — Without executive leadership’s involvement, there will be less pressure on the initiative and the design system team won’t be sanctioned compared to the top-down approach.
- Less (or no) visibility of the initiative
- Informal (or no) budgets at all
- Unsanctioned team
- Narrow scope focuses on maybe only a single area
- Low level of pressure to deliver
At the beginning (the start of stage 1), you may look at these two concepts and find it challenging to identify which one will suit you. It is likely you may have some mix of these, and that’s because these are two ends of a spectrum. The difference between a Top-down stage 1 and a Grassroots stage 1 will be very noticeable, but as the system matures, these differences become more subtle.
The goal is to have the origin stories for stages 3 and 4 closer to the middle of the spectrum and indistinguishable so that you have good support from executive leadership and individual contributors. A Top-down system will become more Grassroots as it matures, and vice versa for a Grassroots system. Of course, they are many different paths as the origin story for each system matures.
How to mature
Within each of the four stages outlined previously, teams must consider three areas of focus to support the maturing of each stage. Ensuring you cover these will help you move through each stage with more success. However, these aren’t sequential. Think of them as a cycle. You are essentially doing all three of these at once.
Educate — This is advocacy for the idea of a design system and the concept of why a design system will be necessary for the organisation. It will be more one-way interaction. Identify how you will approach the system, communicate with other teams, inform how to engage the system, and what rituals you set up.
Engage — Once you establish two-way interaction, you will start to learn from your design system users. You will get feedback, and it will help to grow the system. Including others is necessary for mass adoption and contribution to the system.
Evolve — At this point, it should be a team effort, and your shared objective is to improve the system. The system requires iteration, testing, evolving and prioritising of your design system assets, documents and process.
For example, the education, engagement and evolution required to support stage 1 don’t stop when you reach stage 2. These activities continue with the additional content needed to support the new stage. So at stage 4, you still support all activities required for all previous stages.
System stability
Design systems constantly evolve, and many things can work to try and destabilise the progress of the maturity of the system. There are three primary stabilising factors to focus on Authority, Value and Tradition.
Authority — That leadership actively supports the design system team and their goals. This support gives the confidence to carry out the work, knowing your leaders have your back. Being able to point to things that leadership does to support actively encourages organisational adoption. Dedicated budgets, time and staff help ensure that leadership endorses the initiative and encourages participation in the system’s evolution.
Value — The system offers actual value to those using it, as it improves their work, improves consistency or efficiency and solves real problems rather than creating new ones. Adoption becomes an easy decision because of the value it generates.
Tradition — The system has become how products are built inside the organisation. Once the system has taken root, disciplines across the organisation refer to it as the single source of truth. It’s unique because you can only earn Tradition by having Authority and Value over time.
The goal is to have all three stabilisers supporting each other, but of course, you’re not going to have them all as you get started. Appling your origin stories to these stabilisers allow you to process how to proceed.
Top-down — In this scenario, the first stabilising force will be Authority. With this, you will want to focus on making the system extremely valuable to those using the system. Once you have proven this Value over time, you will earn the Tradition stabiliser.
Grassroots — In this scenario, the first stabilising force will be Value. In this case, you will need to educate leadership on the system’s value, and only through their Authority will you earn the Tradition stabiliser.
Of course, earning these stabilisers doesn’t mean you get to keep them! You have to do the work to maintain the stabilising forces. For example, if you were to gain all three forces and slow the system’s evolution or stop engaging the system users, you would lose the Value stabiliser. This regression would lead to teams losing trust in the system, while the Authority and Tradition would still be communicating they must use the system. This type of regression could be demoralising to team morale.
In conclusion, building design systems will require you to go through multiple stages to reach maturity, each with numerous steps to support evolution and growth. Applying this maturity model and constantly monitoring and communicating the progress of the design system against each of these stages will help the system’s development. This adoption won’t guarantee success; however, it will help you get closer to a favourable future for your design system.
References
The Anatomy of a Design System
Design System Maturity Model
Into Design Systems
A Maturity Model For Design Systems–Live
