Lesson 25 of 30
A shared set of components, tokens, and rules that makes a product's UI look and behave consistently — the thing that turns 'every team invents its own button' into one button, used everywhere, fixed once.
12 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 2
Why does fixing an accessibility bug once inside a shared Modal component benefit every team using it, in a way that wouldn't happen if each team built its own modal?
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
A design system is the source of truth for how a product looks and behaves — reusable components (Button, Modal, Input), design tokens (named values for color, spacing, typography — not hardcoded hex codes scattered through every file), and documented rules for when to use what. A component library is the code that implements it.
// ❌ every team reinvents "primary button" slightly differently
<button style={{ background: "#3b82f6", padding: "8px 16px", borderRadius: "6px" }}>Save</button>
// ✅ one shared component, one place to fix/update it
<Button variant="primary">Save</Button>
Design tokens are the layer underneath the components: --color-primary: #3b82f6 defined once, referenced everywhere — change the token, every component using it updates together, instead of hunting down every hardcoded hex value across the codebase.
Ten teams, ten slightly different buttons — same product, inconsistent look and duplicated CSS.
Modal component with correct focus trapping and ARIA roles means every team using it gets that correctness automatically — the alternative (every team building its own modal) means the same accessibility bugs get fixed, or missed, N separate times."How would you keep a large product's UI visually and behaviorally consistent across many teams?" is a real organizational-scale question, and naming design tokens plus a shared, versioned component library (not just "everyone should try to be consistent") is the concrete, correct answer.