Measure the application of the design system using real metrics
The launch date of the system is not the success. Success is when the product ships features based on the components of that system.
The core metric is the dependency level of each product on the design system in the source code, plus the coverage of components and the recency of the version in use. Do not measure the number of available components or downloads, as that measures inventory, not usage levels. Set goals by tier: core products achieve a high level, while secondary products achieve a moderate level, rather than a common threshold for all.
- system has been coded and many products are used together
- Want to know if the component truly meets real needs (measure the separation ratio in Figma).
- organizations with both core and supplementary products
- consider the system launch day as a success, with no product actually in use yet
- measuring downloads instead of usage levels to ship features
In most organizations, the answer to "Does the team use the design system?" is one of two things: the number of components built or the launch date of the system. Both measure the wrong subjects. They measure inventory and history, not the actual behavior of the team while working.
The base metric that needs to be measured.
There are three layers of metrics to measure actual application, ranked by directness:
- Dependency level in the source code: Does the product declare a design system as a library in the package file (package.json)? This is a point of reference that can be monitored and reported for each product, by version.
- Component coverage: How much of the product's interface is built from system components, rather than being rewritten from scratch or using a different library.
- Newness of the version: Which version of the product is currently in use compared to the latest version of the system? The larger the gap, the harder it is for end users to benefit from new improvements.
These three metrics combined provide a sufficient picture to decide: is the system active or dormant in the repo.
Signals from Figma.
The design team has an indirect metric to monitor: the component detach rate. When a designer detaches a component from the library for manual adjustments, there are two main reasons: the component is not flexible enough for real needs, or the workflow has not been clearly guided.
A high separation ratio does not mean the team is lazy. It often indicates that the system is not adequately aligned with needs. This is a diagnostic metric for improving components, not a summary metric for reporting to management.
Setting goals by product type
A common mistake is applying a universal threshold across the entire organization. In reality, core products and secondary products have different roles, resources, and conversion costs.
Supplementary products: Expect moderate levels, prioritizing the most used components instead of covering everything. Overemphasizing this group often wastes time without delivering proportional value.
Clear hierarchy from the start helps avoid situations where core products are not taken seriously due to low targets, while secondary products are unrealistically pressured.
The value of a design system becomes apparent when the product ships features that utilize parts of the system. Aim to apply it in tiers: core products achieve a high level, while secondary products reach a moderate level, rather than demanding everything or nothing.
Nathan Curtis, EightShapes: Measuring Design System Success
Common errors when measuring
- Consider the launch day of the system as a success, while no product has truly declared its dependencies.
- Measure the number of components available in the library, not how many components are used to deliver actual features.
- Measure download numbers without knowing who downloaded and what they used it for.
- Do not conduct periodic reviews: measure once and then stop, while the level of application changes each quarter depending on team conditions and product priorities.
The viewpoint of Sinh Vũ
During the implementation phase, Sinh Vũ does not hand over the system and leave the team to figure it out. We provide it along with a set of metrics to measure adoption by each team, along with quarterly review minutes so that the numbers do not just sit in the dashboard but lead to real decisions.
The way to adhere to the principle of transferring a sample product to the system is to measure the results before scaling. This ensures that the level of application has real evidence, not just numbers for internal reporting. You can tell if the system is active or dormant by looking at the package.json of the most important product, not by the number of components in Storybook.
Decision checklist
Topic: What metrics to use to measure the actual usage of the design system by the team. Sinh Vũ guide, sinhvu.com
Select each item you find appropriate, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
Nathan Curtis, EightShapes: Measuring Design System Success (high reliability). Nathan Curtis, EightShapes: Adopting Design Systems (high reliability). Practical experience of Sinh Vũ Studio during the implementation and delivery phase of the system.
Frequently asked questions
We have published the design system on npm. Is that the end of the measurement part?
Publishing is a necessary condition, not a success. The measurable anchor point is whether the product has declared the system as a dependency in package.json, and what percentage of the interface is built from the system's components. If that number is not available, you still lack evidence of actual use.
Does Figma have any metrics to measure usage?
There is an indirect signal: the detach rate of components in the design file. If the team often detaches components to edit them manually, that is a sign that the components do not meet real needs, not that the team is lazy in using the system. This is a diagnostic indicator, not a summary metric.
Do supplementary products need to meet the same standards as the main products?
It doesn't need to be done and shouldn't be. Setting a common goal for all products often leads to two extremes: the flagship product not being taken seriously enough, and the secondary products being overly constrained. Clear hierarchies should be established: the expected application levels for each product group should be different and reviewed separately.