Tackling design system adoption

TL;DR: We’re trying to help design system teams understand adoption and we’ve landed on two brand new features that are currently free for everyone. You can even use them if you don’t use zeroheight to create design system documentation. Just sign up for a zeroheight account and head to the Adoption tab to get started.

I've been at zeroheight for two years, and since I joined, an ever-present question has been how to measure design system adoption.

We had a selfish motivation in our quest to get it answered. We thought that if we could create some magic number that showed how valuable design systems are, everyone would have to buy our software (cue maniacal capitalist laugh).

But there was more. We wanted our customers to know that their design systems were making a significant impact, and they wanted to know, too.

We started with docs adoption

Since folks use zeroheight to create design system documentation, we started there. Our first attempt at analytics allowed customers to see how many people viewed their documentation.

We've iterated a lot since then to offer even more insights.

Here's where we're at:

I'm super proud of it!

Our customers now know how views are changing over time; they know whether consumers are finding the information helpful or not, and there's a way to understand how much the design system is changing.

But this still didn’t feel like enough. It was like we were offering teachers a way to see whether their students had opened the textbook, which was helpful. But they really want to know if students are reading the textbook, comprehending it, and able to apply the information.?

Our search for the right metric

We’ve known for a while that measuring design system adoption would require moving beyond documentation-level analytics.?

We want customers to understand things like:?

• How much time they’ve saved with product teams using design system components vs. building from scratch
• Which product teams have adopted the design system
• Where they can focus their efforts on growing design system adoption

The next question was, “Where should analytics go?”?

We certainly could have started to consider design analytics, but Figma has a great suite for that.?

And, using a component in a design doesn’t exactly match up with product use and can lead to false positives. Consider this: a designer may go through five different explorations of a checkout page, using design system components in each version. Should we show that the design system has been “adopted” five times? Or is it just once? And what happens if that design never actually makes it to code?

There’s a whole lot to consider, and ultimately, design analytics felt like it didn’t capture what we were trying to show.

If we go back to the example of the teacher, it would be like showing that a student could apply concepts on classwork without data on whether they could apply those same concepts on a test.?

With further thought, we came to the conclusion that our “test” was the use of design system components and packages in code.?

With data on how the design system is being used in code, customers can answer all of the questions above and perhaps a few they haven’t even asked yet.?

What we built

So far, we’ve built two things that should help design system teams understand the impact of their work.?

The first is a component usage counter. Folks can now connect zeroheight with their repos and see how often components are used across all repos or specific ones.

I’m really excited about how folks can use this data. They could get a count of how much engineering effort they’ve saved, like the team at Eventbrite. Or, they may find out that they’ve been investing loads of time in the wrong components and can confidently move toward new priorities.?

The second thing we’ve built is a tool to track the adoption of design system packages. Lots of design systems compile their work into handy packages hosted on tools like GitLab, GitHub, or Bitbucket, or maybe into npm packages).

Here's how it all looks:

Understanding how product teams consume code from design system teams should be a game changer. I’m especially hopeful about the flag letting folks know when a product team uses an outdated package.?

We talk a lot about the main goal of design systems—reducing technical debt and ensuring product consistency. I'm hoping monitoring package versions will make it easier to determine if we've realized that goal. And in instances where teams are using outdated packages, this feature lets teams know who's using the outdated package for fast correction.?

If you're looking for a more in-depth look at the Adoption tab, check out this video overview from Seth Corker :

Rolling out our new design system adoption features

These new features are brand new territory for zeroheight. So, we want to hear feedback and understand how the community uses them.?

So, these features are totally free. Just sign up for a zeroheight account and head to the Adoption tab. And, since the new feature set isn't dependent on our core documentation feature-set, you can track design system adoption even if you aren't yet leveraging our documentation features.

We're genuinely hoping these feature provide valuable insights for design system practitioners but, we'll only know if we accomplished that goal if you tell us. So, don't be shy with the feedback.