What governance model would you propose for a centralized design system?

WHAT THIS TESTS: This tests your ability to design socio-technical architecture for a design system that must function as a centralized, living ecosystem rather than a static artifact. The interviewer cares whether you understand that governance is about people and process, not just components, and whether you can navigate the tension between standardization and the autonomy of mature product teams running legacy tech stacks.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, it defines the governance model as federated or hybrid, where a small core platform team owns foundational primitives like design tokens, accessibility standards, and interaction patterns, while distributed product teams own framework-specific implementations and contribute back via clear contribution contracts. Second, it addresses the legacy stack problem by proposing an incremental adoption strategy such as wrapping legacy components with new system contracts or using tokens as a bridge layer rather than forcing a big-bang rewrite. Third, it emphasizes clear rules for how the system is used and maintained, including a decision-making council with representatives from each silo to avoid bottlenecks and ensure the system evolves continuously alongside what it supports. Fourth, it explicitly weighs trade-offs: consistency and accessibility improve but migration cost is real, team autonomy decreases in the short term, and the core team risks becoming a service desk if boundaries are not enforced.

COMMON WRONG ANSWERS: Common wrong answers include proposing a fully centralized dictatorship where one team controls all components and mandates immediate adoption across every stack, which ignores migration cost and kills buy-in. Another red flag is treating the design system as a one-time project or a static style guide rather than a living product that must evolve continuously. Candidates also stumble by ignoring the legacy constraint and assuming every team can simply migrate to React or a single framework within a quarter.

LIKELY FOLLOW-UPS: Interviewers often follow up by asking how you would measure adoption and health of the system, how you would handle a team that refuses to participate, or what you would do when a product team needs a component that does not fit the existing patterns. They may also probe on how to fund the core team long-term or how to version the system across multiple tech stacks without breaking changes.

ONE CONCRETE EXAMPLE: Imagine an organization with a React web team, an Angular legacy admin team, and a native mobile team. The core platform team publishes design tokens as JSON and CSS variables, owns a shared accessibility checklist, and maintains a React component library as the reference implementation. The Angular team is not forced to rewrite; instead, they consume the tokens and build Angular wrappers that match the interaction patterns, contributing any new patterns back through a design system council for review. Mobile follows the same token contract but owns Swift and Kotlin components. This respects legacy constraints while driving consistency through shared primitives and governed rules.