Building a design system quarterly roadmap

WHAT THIS TESTS The interviewer wants to see structured, evidence-based prioritization and a deliberate stance on technical debt rather than feature-chasing. They are listening for concrete data sources and a framework that prevents debt from being perpetually deferred.

A GOOD ANSWER COVERS Gather quantitative signals: component adoption rates across repos, usage analytics on which components and props are most used, visual-consistency or override rates, and recurring themes in support tickets and bug reports. Gather qualitative inputs: interviews with product engineering leads, designers, and accessibility stakeholders to learn what blocks them. Maintain a technical-debt ledger so debt is visible alongside features. Score initiatives by reach (how many teams benefit), impact, confidence, and effort using a framework like RICE. Crucially, allocate a fixed capacity slice each quarter to debt, accessibility, and maintenance so they compete on a protected budget rather than always losing to new features. Sequence work so foundational fixes unblock later features.

COMMON WRONG ANSWERS Prioritizing by the loudest stakeholder or executive whim. Building only new components because they demo well, letting debt compound. Treating debt as something to handle later, with no protected capacity. Ignoring adoption data entirely.

LIKELY FOLLOW-UPS How do you say no to a senior stakeholder's pet request? How do you quantify the cost of a piece of debt? What if adoption data and stakeholder requests conflict?

ONE CONCRETE EXAMPLE Usage analytics show eight teams hand-rolling tables and tickets cite a flaky modal. You RICE-score the backlog, dedicate seventy percent of capacity to a new Data Table plus the modal fix (high reach), and protect thirty percent for token migration debt and an axe-driven accessibility pass, presenting the plan to leads for buy-in.