Design systems maturity as a tree

The design world is filled with more and more design systems, and it’s safe to say that it’s not something new. But more design systems bring more complexity, and it might be difficult to assess how mature your design system is. Besides, are we all on the same page when defining what maturity is?

• Do we mean how skilled our team working on the design system is?
• How rich our documentation is?
• How ready our design system to be consumed is?

Let’s dive into each of these topics to understand better what a mature design system really is.

Grow your people

I like to say that design systems are made by humans, for humans. In other words, design systems are about people, way more than tools. So, you should not underestimate who will be part of your design system team.

It’s not an easy job, and design systems are not an inexperienced person’s game; that’s why we recommend having senior people with experience to ensure a high-quality design system.

It’s not surprising to discover in our survey that 56% of people working on design systems have 10+ years of experience. However, 45% of respondents have been working on design systems for 1-3 years. The main reason could be because design systems are still young in organizations and it’s hard to build a significant experience on this expertise. That could also explain why only 8% of job titles explicitly state “design systems” among the 220 unique job titles we identified.
But this is something that will change in the coming years.

Why have a mature design system, you may ask? I could tell you how difficult building a good component library is or how important it is to federate everyone around your project. All of these reasons are part of the answer, but there’s more: the design system teams need to be tough and able to endure failure, isolation, and misunderstanding. They need to be strong enough to overcome any unhappiness they may encounter from the challenges of creating a design system. Check our article about design system team happiness if you’re curious.

Fortunately, I think that as design systems are becoming the new normal, the easier it will be to work on and so, the happier people will be 🙂

Grow your documentation

We already mentioned that documentation is the heart of a design system, but, in this metaphor, maturity doesn’t mean a young heart or an old heart.

As most design systems are relatively young, it’s no surprise to see 74% of systems are 3 years or younger, with only a small percentage beyond the 5-year mark, and a 44% majority are only 2 years old. However, a promising sign is the difference between starting your design system and documenting it seems to be relatively low, with 87% of systems starting to document within 3 years. In this case, having mature documentation doesn’t necessarily mean an aging one.

So, what makes mature documentation for your system? According to our survey, even if a vast majority of the respondents are concerned about adoption, let’s not forget the 54% who have documentation concerns, too. It’s a pressing problem since there are 59% documenting less than 50% of their overall system. How to answer this concern, you may ask? You should have a look at your content guidelines.

When somebody is contributing to documentation, only 36% of respondents provide content guidelines or templates to work from. However, this goes up to 54% on “mature” design systems. It’s interesting to link these numbers with what respondents answered about what their documentation includes. Unsurprisingly, colors, buttons, typography, and forms are the most documented patterns (over 75%).

But the most interesting part is below: example pages, accessibility (A11y) guidelines, code usage guidelines, illustration guidelines, motion guidelines, UX research, and sound guidelines are at the bottom line (less than 30%). Can you see the pattern? “Example”, “guidelines”, “research”… it’s all about understanding how to use the design system. Your users don’t only need to have the right icon or the right code snippet; they need to understand how they should apply it for their project.

So here it is: mature documentation is not about how old it is or how rich it is; it’s about how helpful it is for your users.

Grow your maturity like a tree

Growing your people and documentation are only part of the design system maturity journey. One good metaphor to help you visualize a design system’s maturity is by considering it as a tree. You need to plant the seed and sprout the design system idea to your teams to develop the roots that will help you grow and bloom this system until it is self-sufficient to pollinate the projects and even breed other systems. It’s also a very fragile system that needs regular maintenance and extra care, with solid foundations to ensure its longevity.

We identify seven stages to this design system maturity journey, from the seed you plant to the beautiful breeding tree you get in the end.

Stage 1: Plant the seed

This is where you start to plant the design system “seed.” The idea is to work better, faster, and more efficiently thanks to the design system. It is the seed to convince everyone this design system is the next big thing your organization needs. You may conduct a design and/or technical audit to help you justify the need. Also, interviewing your teams can help you better understand their needs and expectations with this design system.

Stage 2: Make it sprout

Once you managed to convince some people at your organization, you need to sprout this design system seed idea. You are at a framing stage to start your design system on solid foundations by asking the right questions: which tools, what kind of governance, and what this design system is going to solve…. these are strategic questions you and your team need to answer through workshops or meetings to be sure you’re heading in the right direction.

Stage 3: Develop the roots

You have a better understanding and vision of what your design system should look like: tools, user needs, team set-up, prioritization, a backlog…

You can start working on the roots of your design system with your first patterns and the first needs you identified. This is usually the beginning of any kind of library to help you make this design system more concrete.

Stage 4: Make it grow

You can see the first branches of your design system! It’s usually an exciting part because it’s no longer abstract and you are finally making your design system alive. At this stage, you should have defined and documented your foundations before starting to document and/or build your components. You might have a small team with one designer at least spending a significant amount of time working on the design system.

Stage 5: Let it bloom

You may take some time to reach this stage as the previous stage can be very time-consuming. You can consider having a solid and stable first version of your design system with good documentation and libraries. In the blooming phase, it’s time for small projects to use it so you can do some tests and learn from experiments to improve your design system. Your team may have grown with at least one designer and one developer who are dedicated to this design system.

Stage 6: Spread use through pollination

You are now in a more comfortable position since your design system is now well implemented into your organization and it starts pollinating with a lot of projects using it and relying on it. It’s the source of truth for everyone and you have a solid team who now keeps updating and improving this design system and trying to take it to the next level with more complex patterns and better processes. This is now a real and living product pollinating your whole organization.

Stage 7: Self-sufficient breeding system

This final stage aligns your design system with your organization’s ambitions: you probably have multiple design systems addressing different targets, brands, platforms, or product specifics. You managed to articulate your design system that breeds different and specific needs through these multiple branches. You also have more significant teams dedicated to your design systems and your documentation covers most of all the patterns, even the complex ones.

You may not follow this exact timeline and feel like you are between several stages. This is both a maturity model and a vision of how a design system should ideally proceed. But we are not in a perfect world and I know that sometimes you may be at a stage without passing the previous ones. Consider this visualization as a way to position yourself but also to help you understand what you may be missing.

Grow at your own pace

Remember that building a design system is a marathon, not a sprint, and defining the maturity stage of a design system is not an easy task.

It’s not just about your people, documentation, or your design system’s longevity. It’s a living product and like all living things, it has its own complexity. Not all design systems evolve at the same rhythm or in the same way. There is no need to be impressed or compare yourself the next time you see someone else’s design system. We’re all just in a giant forest with unique and very different trees, and you’re one of those trees, growing at your own pace.