Product Designer interview question
How do you build a design system?
Build a design system from repeated product needs: establish accessible tokens and foundations, create composable components with documented states and content rules, align code and design ownership, version changes, and measure adoption.
Direct answer
What a strong answer covers
How it works
A design system is built from what the product repeats, not from a wish list. It starts with foundations, colour, type, spacing, and motion tokens, defined with accessible contrast and scale baked in, and shared between design tools and code so a token change flows to both. Components are added when a pattern appears in three places, designed with every state, responsive behaviour, and content guidelines documented, and built once in code with the design file as its mirror. Ownership is shared between design and engineering with a contribution process, changes are versioned with migration notes, and adoption and defect rates are measured so the system proves its value rather than assuming it.
Example
A team audited the product and found eleven button variants and four spacing scales; the first release of the system defined tokens, a button with all states, and form inputs, published as a Figma library and a React package with the same names. A contribution guide let product teams propose components, adoption was tracked by counting system components versus custom ones per screen, and within two quarters the ratio moved from 30 to 80 percent while UI defects per release halved.
Common mistakes
- Building fifty components before any product team needs them.
- Letting the design file and the code diverge until neither is trusted.
- Shipping the system with no contribution path so teams fork it.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.