Are you a Design System designer or Design System product manager, who is frequently asked why the system “can’t do this” or “doesn’t do that”? And do you just respond with “we are aware”? Then this article is for you.
What is design system maturity?
Design system (DS) maturity is a subjective scale of how developed / experienced a company’s design system is.
Factors of DS maturity
Not an extensive list by any means, but design system usefulness, adoption, complexity, and comprehensiveness all factor into maturity.
Non-factors of DS maturity
Company maturity and product maturity have no bearing on DS maturity. A company can be 20 years old with an established product, but have no design system. Conversely, a startup company could have built out a DS in parallel with its product. Neither of these situations are “good” or “bad”, just prove the point.
Stages of maturity
Thee stages (and their definitions) below should be used as a starting point, and refined to fit your company’s style.
Stage 1: Absence
A lot of software companies never get to the point of wanting or needing a design system. It’s not for everyone, and especially may not be needed at a startup.
At this stage:
- Teams (if there are even teams) are pretty siloed when it comes to designing and developing features.
- There may be some form of a component library on the design or engineering side, but this probably spawned from a passion project or learning opportunity. Many may not even know about it.
Stage 2: Acknowledgment
Leadership and/or powerful players realize the need for a design system, but have yet to put resources (people / money / time) into it.
At this stage:
- Most of design and engineering are starting to realize they need some sort of system in place.
- Whispers of product consistency start to emerge in back channels and some team members may even start an unofficial style guide in their spare time.
- Component libraries have been made on the design and engineering side. They can be useful in the right setting / context.
Stage 3: Actualization
People / money / time has officially been invested, and now DS assets (component library, style guide, process documentation) are actually being made.
At this stage:
- Full-time employees either scrap old component libraries and start fresh, or make significant improvements to it.
- Component libraries on design and engineering side start to be synced.
- Work starts to get communicated across all teams.
- A style guide starts to pair with the libraries.
Stage 4: Adoption
“If you build it, they will come.” Not for design systems. You may get stuck in the Actualization phase if holdouts in your org refuse to use/reference what the DS has to offer.
At this stage:
- 90% of all core components have been built.
- Future core work is on optimization of already-made components.
- Focus starts to shift to component usage, larger components / patterns and internal documentation/evangelism.
Stage 5: Acceptance
People are adopting e.g. components / foundations in everything they do. They may not see the big picture but understand the personal gains they have received and start to trust the DS team more and more.
At this stage:
- More funding is thrown at the growing DS team.
- DS “dream” projects start to become a reality (e.g. product-specific components, foundation optimizations).
- Office hours and onboarding documentation are now an expectation.
- Metrics are not only collected, but acted upon.
Stage 6: Acceleration
With everyone on board, the sky is now the limit!
At this stage:
- Design system operates just like any other feature team.
- Delighters (e.g. animation, public styleguide) are absorbed/introduced into the system.
Defining your stage
The best way to define your company’s DS maturity is from the bottom, up. If you have a DS team, work with each other and agree what stage you are in. This can be as formal or informal as you’d like. If you have a DS team of 1 this exercise should be even easier.
Next, share your agreed-upon stage with your manager. First communicate what DS maturity is, and what the stages are. Then share what stage your company is in. To reiterate this is not an exact science, rather an expectation exercise that will serve as a communication tool.
If your manager disagrees, then this is a clear sign there is a communication/perception gap. Work together to agree upon a stage.
Depending on company size, your manager should carry out the same exercise with their manager, and so on. I’m not saying this needs to reach the CEO, but it does need to reach the people who make resource and long-term product decisions for the company.
Benefits of knowing your company’s design system maturity
As alluded to above, DS maturity is a communication tool at its core. The benefits below reflect this sentiment.
1. Aligns expectations at all levels of the company
The last thing you want is leadership expecting an artifact like Carbon in the Actualization stage. Conversely, you don’t want a rogue team assuming they can continue to avoid the component library when you are in the Adoption stage.
Everyone knowing the stage you’re in (and not in) will help form initial ideas/opinions for those not as close to the system.
2. Helps communicate decisions
We’d love to let people know all the reasons why e.g. another button variant wasn’t added to the system, but quite frankly we don’t have the time. Furthermore, if someone doesn’t agree with 1 of the 8 reasons you provide, they’re subject to attack that one reason. Referring to your company’s maturity resets context, simplifies the response, and implies thought was put into the decision.
3. Helps actually make decisions
DS maturity shouldn't just be a tool to explain why a decision was made, it should help when actually making the decision. DS maturity should help define your team’s backlog, long-term planning etc.
4. Further emphasizes the point that a design system is a product, not a project
Because people see the stages, it’s more apparent that a DS doesn’t just end after v1 of the component library, or once a style guide is spun up. You may get some questions once you are in the Acceleration stage, but at this point a design system’s value should already be well understood.
TLDR: DS maturity charts
As I always recommend, “show, don’t tell” — charts like these will boost all the benefits above, further ensuring everyone is on the right page.
Of course you may tweak the lines, change the stage names, and even come up with new charts (I have several more myself). The idea here is to get the juices flowing.
Once you know which charts you want and how you want them to look, plot the “current state” marker, like the example below.
Closing
I hope this article will inspire you to define your own maturity stages, plot your DS’s current stage and share with your company.