Maturity stages
According to this model, this how you can progress to mature your design system to ideally reach the stage 4:
- Building version one — Foundational work
- Growing adoption — Have people using it
- Surviving the teenage years — Discovering real-world problems to solve
- Evolving a healthy product — Sustainability
Origin
Ben Callahan describes two different points of views in terms of scaling a design system, from which you started and that can teach you where to go:
- One that comes as a top leadership initiative (Top down)
- One that comes from design necessity (Grassroots)
This forms a sort of spectrum of conditions for design systems to evolve in organizations.
| Top down | Grassroots |
|---|---|
| More visibility | Less visibility |
| Formal budget | Informal/no budget |
| Dedicated team | No team |
| Broad scope | Narrow scope |
| Leadership pressure | No expectations |
Growth can shape differently within this spectrum, to each organization case. For example, take this chart, that shows one can start below and then fluctuate between leadership buy-in and survival mode quickly. The other way around is also possible and has multiple factors affecting it.
How to mature
Ben describes this as a way to grow between the stages; you continuously practice these actions until at one point, through evaluation, you understand that you can grow to the next stage.
| Educate | Engage | Evolve |
|---|---|---|
| Spread the word | Get others in it | Make it better |
| One-way interaction | Two-way interaction | Iterate and test |
1. Building version one
Educate
- Define what a design system could be in your organization.
- Share benefits, costs and approach.
- Cast the vision.
- Present it to the broader audience of your organization.
Engage
- Discover what will make it right for teams to use — interview, talk with people
- Identify early adopters to use/test
Evolve
- Iterate toward the initial release.
- Build a documentation resource.
- Write usage guidelines.
2. Growing adoption
Educate
- Share each release or evolution bump up.
- Share adoption stories — What little wins could you share to inspire?
- Create and share a roadmap.
- Share the goals and metrics you have defined.
Engage
- Gather feedback.
- Get roadmap collaboration — Add your (adopter) own needs to it.
- Support your adopters and, if needed, work closely with them around problems.
- Ask for leadership and adopters support.
Evolve
- Documentation to use and effectively adopt it.
- Strategically help it grow by:
- adding requested features
- fixing pressing issues/bugs
3. Surviving the teenage years
Educate
- Capture and share the analytics.
- Effective way to communicate to adopters.
- Explain how to contribute.
Engage
- Have design system personnel working in projects.
- Have adopters working sporadically on contributing.
- Directly help onboard into full adoption.
- Have a long-term leadership commitment to support it.
Evolve
- Well-oiled and working contribution model.
- Space to add components and guidelines.
- Improvements requests popping up.
4. Evolving a healthy product
Educate
- Explain how it can impact the development of a new initiative from inception and formalization.
- Showcase the wins of using it internally.
Engage
- Continuously interacting with adopters to sense if the current needs are met or if new ones arise.
- Have the design system in the leadership conversations, when new ideas are forming.
Evolve
- Ensure the system is still relevant to build new and better products.
- Regularly incorporate new tooling and ways of doing ingrained into the processes.
System stability
Some of the core principles, or “stabilizers” as Ben names it, that a design system should seek out to get. Not only to achieve a certain stability and actually be supported, but to continue existing and impacting products positively.
Authority
Leadership actively supports the design system team and their goals.
Value
The system provides true value to adopters and users.
Use (Tradition)
The system has become the core way to build products within the organization.
I would very much prefer here to use the term “Use” as in “has use”, meaning the system is actively used in projects. As opposed to not being archived or old as the “tradition” wording could imply, even if very much still useful.
This means, that the system still, today, being adopted. It is used and regularly evolves and grows through the surfacing of issues and an active team to solve them and improve its adequacy to the organization’s reality.
An example of regression
An important note here: to pay attention to the regression aspect. Take as an example the system that has Authority and Use (signaled with the top triangle in the previous diagram).
On this case, we can discover that a balance is needed at the center of the graph. We would need the system to still have stabilization, in equal measures, in Authority, Use/Tradition and Value.
Credits to Ben Callahan that presented these tips in “A Maturity Model For Design Systems” shared in YouTube’s video published by Into Design Systems channel. Images of diagrams are screenshots from Ben’s presentation.
Most of these are notes that I took while learning. It is not exactly “vanilla” in the sense that I added or tweaked around according to my own experience with building design systems. I would say it’s about 5% my input.