Design system maturity

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:

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:

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:

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:

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:

Stage 6: Acceleration

With everyone on board, the sky is now the limit!

At this stage:

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.


I hope this article will inspire you to define your own maturity stages, plot your DS’s current stage and share with your company.