Designing a UI consistency score

WHAT THIS TESTS The interviewer wants you to operationalize a fuzzy concept. They are listening for multiple concrete, measurable signals, sensible weighting, and automation, plus an actionable breakdown rather than a single mystery number.

A GOOD ANSWER COVERS Define the signals that proxy consistency. Token adherence: the ratio of design-token usage to hard-coded colors, spacing, and typography values. Component adherence: design-system component usage versus raw HTML or hand-rolled equivalents. Override rate: how often consumers override component styles or use escape hatches, which signals the system is not fitting. Pattern divergence: deviation from sanctioned layouts and interaction patterns. Optionally, visual signals from screenshot diffing to detect drift. Automate collection with AST-based static analysis across repos, a linter or custom rules feeding a central store, and visual regression tooling, all run in CI or a scheduled job. Aggregate the signals into a weighted score per application, but always expose the underlying breakdown so a team sees exactly which signal is dragging them down and can act. Track the score over time to show progress.

COMMON WRONG ANSWERS Producing one opaque score with no breakdown, so teams cannot improve it. Relying on a single signal like component count. Manual audits that do not scale. Weighting that lets one easy-to-game signal dominate.

LIKELY FOLLOW-UPS How do you weight the signals? How do you stop teams gaming the score? How do you account for legitimate one-off needs?

ONE CONCRETE EXAMPLE For each app a CI job computes token adherence at eighty percent, component adherence at seventy percent, and an override rate of fifteen percent, weights them into a consistency score, and renders a dashboard. A team scoring low on token adherence sees that exact signal flagged and migrates hard-coded hex values to tokens to raise it.