Classifying a visually breaking padding change

WHAT THIS TESTS The interviewer wants to know whether you apply Semantic Versioning to the full consumer contract, including visual output, not just the TypeScript signature. Visual changes that shift layouts are a classic trap.

A GOOD ANSWER COVERS The key insight: for a design system, the component's rendered output is part of its public contract. A padding change that shifts layouts across consumer pages breaks their expected appearance, so under strict SemVer it is a breaking change deserving a major version bump. Pragmatically, you might instead expose the change behind a new token or opt-in prop so existing consumers keep current spacing, releasing it as a minor and letting teams migrate deliberately. Release safely by running visual regression tests to enumerate exactly which screens shift, writing a clear changelog and migration guide, communicating the change ahead of time, and ideally shipping it behind a flag or deprecation window so teams adopt on their own schedule. Coordinate with consuming teams on timing.

COMMON WRONG ANSWERS Calling it a patch because the function signature is unchanged, ignoring that visual output is part of the contract. Shipping it silently with no migration note, surprising teams with broken layouts. Forcing the change on everyone at once with no opt-in.

LIKELY FOLLOW-UPS When is a visual change merely a patch? How do tokens let you avoid a major bump? How do you batch breaking changes?

ONE CONCRETE EXAMPLE The designer wants 4px more vertical padding. Visual regression shows it shifts twelve screens, so you classify it as breaking. You add a spacing token defaulting to the old value, ship a minor release, document the new recommended value, and let teams flip the token per app, then bundle the default change into the next major.