The health metric of the design system needs to be reviewed quarterly.

Most teams look at the design system and ask: "How many components have we created?" That is the wrong question. The right question is: "Is what we have created being used, by which teams, and is it being used correctly?" Quarterly audits are only valuable when they answer that right question, leading to specific decisions, not just creating a pretty report.

Four core indicator groups

Sinh Vũ recommends organizing quarterly metrics into four groups in order of the system's maturity.

• Output: the number of completed components, patterns, tokens; the number of releases in the quarter; the number of support cases resolved. This metric is the easiest to measure and often serves as a starting point when the system is still immature.
• Coverage: How much of the actual product is using system assets, measured by features or interface areas. High but uneven coverage is a sign that some teams are neglecting the system.
• Team adoption level: Not just total usage but which team uses which components the most and which team hardly interacts with the system. This is a metric emphasized by Nathan Curtis: it is essential to understand who is using what and how.
• Quality of execution (usage quality): How well components are installed according to standards, whether they are misused, overwritten carelessly, or customized outside the system. This group is the hardest to measure but is the earliest signal that the system is becoming diluted.

Support signals should be monitored further.

In addition to the core four groups, some secondary signals help you gain a fuller picture.

• Number of recurring questions: If the same question appears multiple times in a quarter, the existing documentation or guidelines have gaps.
• Onboarding speed: How long it takes for new users to perform tasks independently without asking for help. A prolonged duration indicates that the system is more complex than necessary.
• Technical quality metrics: Accessibility, loading performance, and code cleanliness if the industry has standard constraints or multiple teams using it.

Sparkbox notes that only about 16% of design systems have measurable metrics systematically. However, those systems that invest in actual quality metrics have a clearly higher application rate compared to systems that only count components.

When to prioritize which group

Common errors when reviewing

• Only boast about the number of components produced without measuring if anyone uses them. Output is not value; application is what matters.
• Measuring total usage while overlooking which teams. A good total can hide the fact that two teams have completely stopped using the system.
• Set too many metrics to the point where no one can review them each quarter. A small set that can be reviewed regularly is better than a large set that is reviewed once and then ignored.
• Viewing the review session as a performance report, not a decision-making meeting. Each review must conclude with at least one specific action that will be done differently in the next quarter.

Start by measuring output, then move to measuring application, as the value creation system relies on the product's shipping experience. Don't just measure usage; understand who is using which component and how.

Nathan Curtis, Measuring Design System Success (EightShapes)

Sinh Vũ's viewpoint

In the deliverable package with management, Sinh Vũ provides a set of metrics to track application levels by team, linked to quarterly review minutes. The goal is for each team to reflect each quarter: whether the system is still strong or becoming diluted, and what to prioritize in the next quarter.

Sinh Vũ does not provide a percentage figure as a firm commitment, as that number depends on the team and product that you will operate after delivery. What Sinh Vũ commits to is designing a set of metrics that are concise enough to reflect reality, not just pretty enough for reporting.

If you are reviewing the system for the first time and don't know where to start, choose one metric from each core group, review it over a quarter, and then adjust. Don't try to design a perfect set of metrics right from the beginning.