Core roles on a design system team

WHAT THIS TESTS The interviewer wants to know whether you treat a design system as a long-lived internal product with dedicated owners, or as a folder of components someone updates occasionally. The roles you name reveal how seriously you take governance, adoption, and maintenance.

A GOOD ANSWER COVERS A product manager who owns the roadmap, prioritization, adoption metrics, and stakeholder relationships, treating consuming teams as customers. Designers who own design tokens, component specifications, interaction patterns, and visual consistency. Engineers who build and maintain the component library, the build and release pipeline, versioning, and developer tooling. An accessibility specialist (sometimes embedded) ensuring components meet standards like WCAG. A documentation or developer-relations role keeping usage guidance, examples, and migration guides current. On smaller teams these collapse into fewer people, but every responsibility still needs a clear owner.

COMMON WRONG ANSWERS Naming only visual designers and forgetting engineering, which makes the system undeliverable. Saying it is everyone's shared responsibility, which in practice means no one owns adoption or quality. Omitting product management, so the roadmap becomes reactive ticket-taking. Ignoring documentation and accessibility entirely.

LIKELY FOLLOW-UPS How would these roles change for a five-person startup versus a large enterprise? Who decides what goes into the core library? How do you fund the team and justify headcount?

ONE CONCRETE EXAMPLE At a mid-size company you might run a four-person core team: one PM tracking component adoption across forty repos, one designer maintaining the Figma library and tokens, two engineers shipping the React package on a two-week release cadence. Accessibility reviews are a shared rotation, and documentation lives in a Storybook site the engineers update with every release. Product teams contribute through a federated model the core team curates.