Reversing stagnating design system adoption

WHAT THIS TESTS The interviewer wants strategic thinking: adoption is a product and trust problem, not a compliance problem. They are listening for diagnosis before prescription, concrete developer-experience improvements, and metrics that prove value.

A GOOD ANSWER COVERS Diagnose first: interview the complaining teams and instrument the codebase to learn whether the friction is missing components, poor APIs, slow releases, weak docs, or painful migrations. Then reduce friction on multiple fronts. Improve developer experience with cleaner component APIs, TypeScript types, and good defaults. Speed up releases so fixes land fast. Ship codemods and migration guides so upgrades are cheap. Invest heavily in documentation and live examples. Embed core engineers with product teams temporarily to unblock them and learn. Pair these carrots with selective guardrails, such as lint rules that flag off-system components, but only after the system is genuinely easier than rolling your own. Communicate wins publicly.

COMMON WRONG ANSWERS Mandating adoption by executive decree while the underlying friction remains, which breeds resentment and workarounds. Adding more components when the real problem is API ergonomics or release speed. Tracking only vanity metrics like component count.

LIKELY FOLLOW-UPS Which metric proves the system saves time? How do you handle a team that refuses? How do you avoid gaming the adoption metric?

ONE CONCRETE EXAMPLE Interviews reveal upgrades are painful, so you ship codemods, cut release cadence to weekly, and embed an engineer with the slowest team for a sprint. You track design-system adoption rate, override or escape-hatch rate, median time-to-build a screen, upgrade lead time, and a developer-satisfaction survey, then show adoption climbing as override rate falls.