On Design System Maturity Models
To provide a bit of context, I think it’s valuable to have a rough idea on where I’m currently working. I’m part of a large scale company with a reasonably sized tech department. The tech department consists of 400+ individuals and we favour to do a lot of developments in house if we can. Our main focus is e-commerce and the solutions within the supply chain (think about distribution, stock optimisation, delivery and whatnot).
Since a couple of years, I’ve been invested in the component library we’ve built over the years and I gave talks on our organisational efforts surrounding the maintenance and developments. Within that capacity, I was able to share my story and chat with lots of peers from different types of organisations, but similar active topics. During those chats, the more people I talked to, the more I discovered patterns emerging. My attempts to structure these patterns have led to a model I came up with to capture Design System Maturity. Disclaimer: This is a work in progress and may be subject to change!
What’s a Design System anyway? 🤷♂️
Let’s talk about a definition, so that we establish a common understanding of what we’re considering when I mention a design system:
“A design system is a structured collection of reusable design elements and guidelines that help maintain visual and functional consistency across digital products and services.
It serves as a centralized resource for design and development teams, providing a set of standardized components, patterns, and principles that ensure a cohesive and user-friendly experience for both designers and end-users.”
The definition gives us some leeway, but that’s fine and actually intended, because design systems are not always strictly defined too.
A design system typically contains the following parts:
Guidelines and Principles: Design systems establish rules, best practices, and design principles to guide the creation of new interfaces. These guidelines help designers and developers make consistent design decisions.
Documentation: Comprehensive documentation accompanies the design system, explaining how to use and implement its components and guidelines. This documentation is essential for ensuring that the design system is effectively adopted by the organization.
Accessibility Standards: Many design systems also include accessibility guidelines to ensure that digital products are usable by all, including individuals with disabilities.
Design Components: These are the building blocks of a user interface, such as buttons, forms, typography, icons, and color schemes. Design systems define how these components should look and behave to maintain a unified visual style.
Code Components: In addition to design elements, some design systems provide code components or libraries that developers can use to quickly build and maintain consistent user interfaces.
Again, these are not always up to the same level of detail or maturity. They may even be unspoken rules, which can make it very hard to even identify them.
On Design System Maturity Models
In a regular development flow, design almost always matures first and ahead of other parts. You can’t build a Design System without Design! The “System” part will inevitably follow, given enough time, by necessity or by active direction from people involved.
So why would you be interested in this topic to begin with?
If you’re building on ongoing projects, a Design System is an accelerator when used correctly.
A Model helps you understand and explain topics by simplification.
You can compare where you stand and what possible next steps you want to take in order to improve your design system.
Let’s see how we can capture maturity of a design system in several stages.
Stages of maturity
🥚🐣🐥🐓🍗
I’ve drafted a couple of observable stages. While the stages are distinct, obviously you could be in between stages or having fulfilled some characteristic of a more mature stage.
Together with ChatGPT, we came up with a perfect analogy: star systems. These start chaotic, nebulous and over time start to gravitate towards more distinct and matured systems which have clear classifications as well. It’s perfect because I love the topic of space exploration almost equally as much as development explorations.
Stages of Design System maturity:
Nebula (small scale) 🌌
Little to no maturity, but has potential to grow;
There’s a cohesive brand or brand guides, but they’re not specifically for digital usage;
The existing patterns may or may not use a third party library with a branded theme to fulfil basic needs.
Blue Dwarf (small scale) 🔵
Designs according to brand and tailored to digital products;
Fragmented development takes place that follows design;
There are loosely coupled collections of developent patterns (such as validators, linting rules etc);
Any third party library is customised to fit the brand, but limitations are being met;
Star (small - mid scale) ☀️
Design is aligned with development components in terms of feature support and naming conventions;
Documentation on implementation and usage is present for most components;
There is a culture shift with a more focussed effort and encouragement on contribution to the Design System.
Red Giant (mid scale - large scale) 🧌
There is close alignment between Design, Development and other stakeholders.
Multiple platforms are considered and supported, yet fragmented;
Documentation is more extensive, including an interactive playground or sandbox;
The design system is supported by allocated resources from the organisation;
The adoption rate is very high: new projects default to adopting, existing projects may migrate to start adoption of the design system;
The Design System is considered a product in the organisations’ portfolio;
Goals and KPIs are set to success measurement.
Supernova (large scale) 💥 A massive explosion sounds bad, but it’s super so we're going with it.
There is cross platform alignment between Design, Development and other stakeholders;
Tokenised foundation supports better stability and separation of concern;
Components support multi platform usage;
The level of Developer Experience makes it the default development system;
Tooling is in place to quickly scaffold out contributions or new projects;
Strong governance on the contributions and quality assurance;
Facilitating different levels of contributions, a layered or tiered collection is adopted;
The Design System is a strategic asset of the organisation.
Properties and capabilities 🔖
Apart from the characteristics of those stages, a Design System can support different properties and capabilities. We can more or less map these to different maturities, but not in a strict way. They are signs of growth, but can exist on any stage. As a rule of thumb, more capabilities inevitably leads to more attributes that signify maturity.
These may include, but are not limited to:
Multi lang support (i18n)
Accessibility (a11y)
Styleguides & linting
Code testing
Visual testing
Automation
Tokenised setup
Design versioning
Code versioning
Packaging and publishing
Specialised packages
Third party support
Publicly available for partners
Support for theming
Now typically, you could reasonably expect more mature systems to support more of those properties. I don’t think it’s possible to exceed a certain stage before covering a set of these capabilities.
This image was made by Voyager 1 40 Astronomical Units (AUs) away from Earth. That’s 40 times 150 million miles. It shows the Earth, compressed to the size of a single pixel in a field of nothingness. It is where Voyager 1 came from. Voyager 1, by the way, knew exactly where it was going when it took this photo.
Why this matters
This is all about scaling the design system to your needs. As your organisation grows, your Design System needs will (need to) grow as well in order to keep up with new demands and requirements.
This model helps in making decisions and setting a course. Rest assured that the model is not a set of goals you should reach after a set amount of time. They need to match the needs of your organisation.
If you want to navigate to someplace new, you need to know where you are.
Lastly, if your Design System cannot keep up with needs, you will spin out of control: your design system effectively becomes a black hole of both patterns and resources.
Journey from our point of view 🔭
Let’s take a look at how our journey went, to give you a practical idea on how different stages can be reached. Our Design System is called “Kompas”, which is Dutch for “Compass”. It is a tool that helps us find the right direction and path. We can deviate from our compass if needed, but when you use it right, it helps you navigate to your goals very efficiently:
We started with applying designs to build our public facing applications, such as our e-commerce platform. With more and more teams being involved, the need for sharing patterns emerged. In order to fulfil the need, developers built a component library to share UI components. Our internal tooling did not get the same level of styled attention. To some extent theming was applied, but the care and investment simply didn’t allow for better adoption. Some legacy software is still in this state. I think it’s important to realise that applying a Design System is not a goal on its own.
In the last few years we made leaps moving from the Star to Red Giant stages even. We freed up resources to work on our design system, we collaboratively added documentation and our department and design system grew at continuously. We never called it a design system though. This was because of its origins: it was developed originally mainly for web and originated as a component library rather than a design system. At this point however, it does have lots of design system characteristics!
At the moment, we’re actively introducing tiers and layers to better govern the contributions from our stakeholders. We have design tokens in place and that helps us in aligning between native apps and web. We see future needs where we want to start exposing parts for third party consumption and make advances towards web components, but we’re also pragmatic in our approach. The design token introduction added a massive amount of value and opens up more capabilities we think we’ll need.
With allocated time we’ve been able to provide sensible governance and think about long term vision and strategies. We are still improving and learning from our design system.
Practical Tips and Lessons Learned ✍️
We’ve seen that lots of our innovation and improvements from the past were driven by necessity, but not based on strategy. Which meant that we often found ourselves circling back to previous iterations, or actually running into dead ends every now and then.
As we all know: systems reflect culture. We took two things out of that fact: You can’t design a system that’s not based on culture because that will lead to low adoption rates. But you can facilitate small cultural changes together with the system you’re building. We’ve found this valuable in fostering collaboration and a sense of ownership from people involved.
Not everything moves as fast as you’d want to. And not everyone has the same requirements or motivators. You have to be prepared to make pragmatic changes and also put features in the freezer.
If you are working on an internal design system, you are very, very close to your stakeholders. You can make generous use of them at very early stages so you can educate and train them, create ambassadorships and gain feedback every step of the way!
Ever changing nature 🌱
So to conclude, software and systems are ever changing, design systems alike. It takes effort to level up a design system. Having a clear roadmap helps you make informed decisions on where to go next. Lower maturity is not a bad thing, as long as it fits the organisational maturity and needs.
On the plus side, levelling up a design system doesn’t have to take eons in comparison to star systems.