Tracking design system component usage and versions
building adoption telemetry across many apps.
static scan of code or lockfiles, a central reporting store, and a dashboard; data drives deprecation and roadmap.
only counting npm downloads as real usage.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Why is static analysis of consuming repos preferred over npm download counts for measuring design system adoption?
- a.Downloads are inflated by CI and caches and reveal nothing about which components renderCorrect
- b.Download counts cannot distinguish between major versions at all
- c.Static analysis is the only legal way to inspect another team's code
- d.npm does not expose download statistics for scoped packages
Why? this is the answer
Download numbers are skewed by automated installs and tell you nothing about actual component usage, whereas AST scanning counts real imports and props. The legal and npm-capability claims are false.
Just read this? Test yourself on what you have been reading.
Read the original → engineering.brevo.com
- #design-systems
- #adoption-metrics
- #static-analysis
- #tooling
- #telemetry
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design-systems — each one lists the topics its interview covers.
See open roles