Explain a past product's design system: principles, components and trade-offs

An interviewer asks you to pick one product you have managed as its product manager and walk them through that product's design system. ```hint Explain the why, not the inventory Choose a product where you can say why the system looks the way it does: a principle that came from users, a component you pushed to change, or a moment when consistency and team speed pulled in opposite directions. ``` ### Clarifying Questions - By "design system", do you mean the shared design language (principles, color and type tokens, components, interaction patterns and usage guidelines), or how the product's screens and services fit together end to end? - Should I pick the product I know best, or one where I personally drove the design system work, even if it is smaller? - Some details of that product are confidential; is it fine to describe them at a general level? - How deep should I go on visual detail versus the product reasoning and how design, engineering and product worked together? ### What a Strong Answer Covers - Short product context (users, platforms, the job the product does) that explains why the system is shaped the way it is. - A layered walk-through: principles, foundations such as tokens, components, patterns and flows, and how the system is governed and kept current. - A clear account of the candidate's own role, separate from what designers and engineers owned. - At least one real trade-off, the evidence used and the decision taken. - Results and how they were measured (consistency, delivery speed, accessibility, user outcomes), plus what the candidate would change in hindsight. ### Follow-up Questions - A team needs a component the system does not have for a launch next week. What do you do? - How did you know the design system was worth its maintenance cost? - How did accessibility requirements change the components or the patterns?