Tracking design system health across the org

WHAT THIS TESTS Whether you can build objective, automated visibility into how the design system is actually used, rather than guessing or relying on self-report.

A GOOD ANSWER COVERS Use static analysis as the backbone. Walk each consuming repo and parse the AST to detect imports from the design system, count component instances, and inspect props, including style overrides and escape hatches that signal misuse. Detect one-off implementations by scanning for raw elements styled to mimic system components, hardcoded hex values instead of tokens, or local copies of primitives. Read package.json and lockfiles to compute version drift, comparing each app's pinned version against the latest release. Optionally add lightweight runtime telemetry for real render counts. Aggregate signals into an adoption dashboard with per-team and per-component scores, trends over time, and a leaderboard. Tools include scanners built on Babel or TypeScript ASTs, plus services like the open approach popularized by adoption trackers.

COMMON WRONG ANSWERS Equating npm download counts with adoption, which ignores whether code is actually used. Relying on surveys. Counting imports but not overrides, missing low-quality usage. Ignoring version drift entirely. No aggregation, leaving raw numbers no one acts on.

LIKELY FOLLOW-UPS How do you detect a one-off that visually mimics a system component? How do you handle private or many repos at scale? Static versus runtime trade-offs? How do you turn metrics into action with teams?

ONE CONCRETE EXAMPLE A nightly job clones each app, runs an AST scanner that records every design system import, prop, and override, flags any div hand-styled like a Button, and reads the lockfile to find apps two majors behind. Results feed a dashboard showing team adoption percentage, override hotspots, and version-drift offenders, which the core team uses to prioritize outreach.