How do you migrate a breaking change in a mature design system?
This tests organizational change management at scale, not just code changes. A strong answer covers SemVer major versioning, beta testing with key consumers, phased deprecation timelines, and automated file audits.
What's really being asked
This question evaluates whether you view design system maintenance as a socio-technical contract rather than a pure UI task. The interviewer wants to see if you understand that a breaking change in a mature system affects hundreds of designers, product roadmaps, and production codebases. Success requires balancing semantic versioning discipline, automated migration tooling, transparent communication, and stakeholder management without halting every team's sprint.
The full answer
First, define what a breaking change means for your system using a decision tree and socialize it across the organization so teams know what to expect from SemVer major bumps. Second, identify key consumers, a representative subset of teams with varied adoption levels and complexity, and invite them to beta test the new component and migration guide before public release. Third, publish a phased timeline: announce deprecation in the current major version, release the new version alongside migration docs, set a hard removal date, and use analytics to track adoption across hundreds of files. Fourth, provide automation such as Figma swap libraries, codemods, or find-and-replace scripts so the migration is not manual busywork for dozens of designers. Fifth, communicate through multiple channels including Slack, office hours, and embedded design system liaisons to ensure the message reaches teams who do not read release notes.
The mistakes people make
A major red flag is suggesting an overnight global swap or deleting the old component immediately without a deprecation window. Another is focusing entirely on the visual redesign while ignoring the migration cost for consumers. Candidates also stumble by proposing a single communication email and assuming that is sufficient, or by failing to mention versioning strategy at all. Avoid answers that treat designers as passive recipients rather than partners in the rollout.
What usually comes next
The interviewer may ask how you would handle a team that refuses to migrate before the deadline, what metrics you use to decide if a component is worth deprecating, or how you would coordinate the Figma library change with a corresponding React component update. They might also probe whether you would support both versions indefinitely and how you would resource the maintenance overhead.
A concrete example
At Spotify, the Encore design system team faced breaking changes by first defining their own breaking change decision tree. They selected key consumers ranging from high-adoption legacy products to new low-adoption teams to beta test major releases and migration guides. Before finalizing a new major version, they validated that their migration documentation actually worked in real consumer files, then rolled out the change with clear SemVer signaling and analytics tracking to ensure adoption.
Interview question
When migrating a breaking change in a mature design system used by hundreds of teams, which strategy best balances system evolution with consumer impact?
- a.Beta test the migration guide with representative consumers, release automated migration tooling alongside a phased deprecation timeline, and track adoption before hard removal.Correct
- b.Announce the change via release notes and a single email, then expect manual file updates across design and engineering teams before a fixed deadline.
- c.Execute an overnight global swap in Figma and code, then immediately delete the deprecated component to enforce adoption and prevent fragmentation.
- d.Publish a major SemVer release and let individual teams decide when to migrate based on their own roadmaps, avoiding a hard removal date to reduce friction.
Why? this is the answer
The correct approach treats migration as a socio-technical contract by validating docs with beta testers, automating busywork, and using phased timelines with analytics. Option C is tempting because it appears to eliminate tech debt decisively, but an overnight swap violates the deprecation window and ignores real-world sprint constraints and validation needs.
Just read this? Test yourself on what you have been reading.
Read the original → designsystemsforfigma.com
- #design systems
- #breaking changes
- #figma
- #migration
- #semver
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles