Tracking design system adoption technically

What's really being asked

The interviewer wants concrete instrumentation, not vibes. They are listening for static code analysis that distinguishes real component usage from off-system equivalents, plus aggregation and trend tracking.

The full answer

The core technique is static analysis: parse each consuming repository's source into an abstract syntax tree and count imports and JSX usages of design-system components. Compare that against off-system signals, such as raw HTML elements, inline styles, or hand-rolled equivalents, to compute an adoption ratio rather than a raw count. Run this as a scheduled job across all repos (or a CI step per repo) and push results to a central store. Build a dashboard showing adoption per project, per component, and trend over time, so you can see which teams lag and which components are underused. Optionally add lightweight runtime telemetry to capture actual rendered usage in production, and track design-token usage versus hard-coded values. Package download counts can be a coarse supplementary signal but should not be the primary metric.

The mistakes people make

Using npm download counts as the adoption metric, which only proves installation, not usage, and is skewed by CI. Relying on manual surveys, which are stale and subjective. Counting only design-system imports without measuring off-system code, so you cannot compute a real ratio.

What usually comes next

How do you measure off-system usage? How do you handle components used via re-exports? What ratio counts as healthy adoption?

A concrete example

A nightly job clones each repo, runs an AST scan that counts design-system Button imports versus raw button elements and styled hand-rolls, computes a per-repo adoption percentage, and writes it to a dashboard. A team sitting at forty percent adoption stands out, prompting targeted outreach and migration help.