Tracking design system component usage and versions

WHAT THIS TESTS The interviewer probes whether you can turn the vague goal of measure adoption into a concrete data pipeline and explain why the data is worth collecting. Adoption metrics are how a design system team proves value and steers its roadmap.

A GOOD ANSWER COVERS Describe a static analysis approach that parses each consuming repo's source into an AST and counts imports from the design system package, including which components, which props, and how often. Pair this with reading the resolved version from each repo's lockfile so you know who is on which release. Run this as a CI step or a scheduled crawler over your repos, then push structured results to a central service or data warehouse. Build a dashboard showing per-application coverage, version spread, and the most and least used components. You can complement static counts with lightweight runtime telemetry for dynamic cases, sampled and privacy-safe.

COMMON WRONG ANSWERS Treating npm download numbers as usage, since CI and caching inflate them and they say nothing about which components are actually rendered. Relying solely on manual surveys, which go stale immediately. Heavy production instrumentation that raises privacy and performance concerns.

LIKELY FOLLOW-UPS How do you handle repos in different languages or frameworks? How do you detect components that were copied and modified instead of imported? How do you keep the crawler current as repos change?

ONE CONCRETE EXAMPLE A nightly job clones each repo, runs a TypeScript AST visitor counting design system imports and props, reads the version from the lockfile, and posts JSON to an adoption API backing a Grafana dashboard. The team then sees that one app still pins v2 and uses a deprecated Modal heavily, so they target that app for hands-on migration before removing the old component.