Design Systems interview questions
Design Systems questions a UX / UI designer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A system button exists. You want a slightly different one. First move?
The strongest answer: Use the system, or propose a change with a reason — I do not quietly fork a one-off
Why it works: Exactly. Use or propose. Quiet forks and campaign sizes are how you get 14 buttons.
- Use the system or propose a change.
- Do not quiet-fork.
- Do not invent a campaign size.
- Taste ≠ a fork licence.
Where should the accessible name live?
The strongest answer: In the component API so every instance gets it — I do not hope authors remember a sticky note
Why it works: Exactly. The system carries the name. Pages, late tickets, and density-skips fail the instances.
- Put names in the component API.
- Do not hope for memory.
- Do not park a11y in sprint eight.
- Density ≠ skip the name.
What has to be in a component’s documentation before people will actually use it?
The strongest answer: When to use it and when not to, the states and properties it supports, its accessible name and keyboard behaviour, and a copy rule — plus one example of the wrong use
Why it works: Right — the “when not to” and the accessibility contract are what stop the next one-off component.
- Document the decision, not the picture.
- Say when not to use it.
- List states and keyboard behaviour.
- Show one wrong use.
When is breaking the design system allowed?
The strongest answer: When the job cannot be done with it, and you document the exception — I do not break it for a campaign vibe
Why it works: Exactly. Job plus a written exception. Boredom, sacred-never, and hidden breaks fail the next person.
- Break only for a job the system cannot do.
- Document the exception.
- Not for a vibe.
- Do not hide the break.
Eight squads ship eight dropdowns. What do you standardise?
The strongest answer: The component, the tokens, and the a11y contract — I do not standardise every campaign illustration
Why it works: Exactly. Behaviour and tokens. Illustration-only, novels, and snowflake-autonomy miss the a11y contract.
- Standardise component + tokens + a11y.
- Let campaign art differ.
- Do not write a visual novel.
- Do not bless eight dropdowns as autonomy.
You need a new pattern. How do you add it without a fork farm?
The strongest answer: A proposal, a use, and a path into the library — I do not hide a local component “just for now”
Why it works: Exactly. Propose, use, graduate. Hidden just-for-now and Slack screenshots are forks.
- Propose, use, graduate into the library.
- Do not hide a just-for-now fork.
- Do not wait forever.
- Slack ≠ shipped to the system.
A second brand arrives. What do you refuse to do?
The strongest answer: Fork the whole library — I theme through tokens and keep the behaviour, I do not copy-paste 200 components
Why it works: Exactly. Tokens, same behaviour. Copy-paste, hard hexes, and forced sameness fail the second brand or the a11y.
- Theme via tokens; keep behaviour.
- Do not fork-paste 200 components.
- Do not hard-code hexes.
- Do not force visual sameness as the only path.
Three brands, one platform. What do you protect?
The strongest answer: Shared behaviour and a11y; theme the skin — I do not let each brand fork the keyboard model
Why it works: Exactly. Shared behaviour. Drift-forks, one-skin-punishment, and invented consistency % miss the point.
- Share behaviour and a11y.
- Theme the skin.
- Do not fork the keyboard model.
- No invented consistency %.
What does design-system governance actually decide?
The strongest answer: What gets in, what is deprecated, and the a11y bar — I do not meet to admire a colour
Why it works: Exactly. In, out, bar. Colour-hours, icon stamps, and invented contribution % are theatre.
- In / deprecate / a11y bar.
- Not a weekly colour salon.
- Not a stamp on every icon.
- No contribution percentile.
A pattern used on hundreds of screens is being replaced.
How do you retire it?
The strongest answer: Announce it with the replacement and the reason, mark it deprecated in the library and the docs while it still works, give teams a window and help, then remove it — never a silent delete
Why it works: Exactly — deprecation is a period with a replacement, a date and support, not an event.
- Deprecate, then remove.
- Ship the replacement first.
- Mark it in library and docs.
- Give a window and give help.
The org celebrates hero screens. What do you celebrate instead?
The strongest answer: A reused pattern that made a state cheaper — I do not clap only for a shot that will rot in a case study
Why it works: Exactly. Reuse and states. Likes, snowflakes, and reels-without-states are how the system starves.
- Celebrate reused patterns and cheaper states.
- Not only hero shots.
- Not snowflakes.
- Not reels without states.