Search

Introduction to measuring design system adoption in zeroheight

Vinh
Vinh
  • Updated

We’re introducing new ways to measure the adoption of your design system in code. With these new features, zeroheight makes ensuring teams use the latest design system packages quicker and easier. We also give you insights into how many of your components are being used and where.

https://youtu.be/1Sx2ChrFlZw

Introduction to the new features

Package version monitoring

Make sure that your code bases are using the most up to date version of your design system packages. Via the zeroheight CLI tool, connect code repos or public NPM packages.

Read more here

Component usage metrics

Use the zeroheight CLI tool to scan your repos to dig into the usage of your design system components. Compare how they are used between different projects as well as over up to a 90 day time period.

Read more here

Color usage metrics

Use the zeroheight CLI tool to scan your repos to dig into the usage of non-token color usage. Compare how this differs between projects as well as over up to a 90 day time period.

Read more here

FAQs

How can I provide feedback on the new features?

Look out for a feedback link in the product when using the new features. This will allow you to submit feedback via a form. If possible, please include screenshots or screen recordings to accompany your feedback.

What security accreditations does zeroheight have?

zeroheight maintains ISO 27001, SOC 2 Type II, and GDPR compliance. Read more on how seriously we take security.

Are there any restrictions on the use of these features?

No, access will remain free and unrestricted during the beta period. All you need is a free zeroheight account to be enrolled in the beta.

Which repository services do you support?

We integrate with the following:

You can also reference public NPM packages for monitoring package versions.

Component usage metrics work independently of our repo integrations.

Code of conduct

We want to build the best possible product for our community. This may mean releasing beta features when we know they're not perfect. We do this to get feedback from real users to inform what we build. We ask that feedback be constructive. It may also mean that we decide to pause adding teams to the beta for periods of time while we make changes. We ask that everyone be patient.

Was this article helpful?