Governance for design system contributions

WHAT THIS TESTS The interviewer wants a realistic process that keeps quality and consistency high while still letting product teams contribute, plus clarity on who reviews and against what criteria.

A GOOD ANSWER COVERS Start with intake. Before code is written, a contributor opens a proposal, an issue or a lightweight RFC, describing the need, prior art, and proposed API. The core team triages: is this generally useful, does it duplicate something, should it be a variant of an existing component? This avoids wasted work and scope creep. For implementation, contributions come as pull requests against the system. Reviewers should include core maintainers who own consistency, a design representative for visual and interaction correctness, and an accessibility-aware reviewer. Approval criteria should be explicit: accessibility (roles, keyboard, contrast), API and naming consistency with existing components, correct use of design tokens rather than hardcoded values, adequate unit and visual regression tests, documentation including examples and props, and adherence to the contribution guidelines. Decisions and rationale should be recorded.

COMMON WRONG ANSWERS A pure gatekeeping model where only the core team can change anything discourages contribution and creates a bottleneck. No criteria at all leads to inconsistent, untested additions. Skipping the proposal step means people build the wrong thing before review. Letting any reviewer approve without design or accessibility input lets regressions through.

LIKELY FOLLOW-UPS How do you scale when the core team is a bottleneck, leading toward federated or distributed models? How do you write contribution guidelines? How do you handle disagreements between design and engineering? What is the difference between a centralized, federated, and hybrid governance model? How do you measure contribution health?

ONE CONCRETE EXAMPLE A product team needs a Stepper. They open an RFC; the core team confirms it is broadly useful and agrees an API. The team builds it with tokens, tests, accessibility, and docs, and opens a pull request reviewed by a core maintainer, a designer, and an accessibility reviewer against the checklist. Once it passes, it merges into the system and the team is credited as a contributor.