How would you structure design and Figma for phased rollout?

WHAT THIS TESTS: The interviewer wants to see if you treat design deliverables as living infrastructure during a migration. They are assessing your ability to reduce ambiguity for engineers shipping behind flags across multiple sprints, not your ability to make isolated pretty screens. The focus is on scalability, version control hygiene, and cross-functional coordination.

A GOOD ANSWER COVERS: First, file organization using separate pages or branch files for legacy, transition, and target states so both experiences are documented simultaneously. Second, component architecture using Figma variants or boolean properties tied to feature flag states so engineers can map props directly to code. Third, a rollout map that sequences the redesign by user segment or flow step rather than all at once, with clear acceptance criteria for each phase. Fourth, annotation and handoff practices such as embedded flag names, ticket links, and a cleanup calendar so dead screens do not linger. Fifth, stakeholder alignment rituals like design reviews after each phase to catch regressions before the next increment ships.

COMMON WRONG ANSWERS: Proposing a single page overwrite where old designs are deleted once new ones are approved, which prevents rollback. Suggesting engineers build the entire flow in a branch and merge at once, ignoring production edge cases. Treating Figma as just a canvas rather than a specification tool, leaving flag logic and state transitions undefined. Claiming that a design system automatically solves migration without explaining how deprecated components will be unlinked and removed.

LIKELY FOLLOW-UPS: How would you handle a hotfix on the legacy flow while the new flow is partially rolled out. What happens if analytics show the new step drops conversion by fifteen percent halfway through the rollout. How do you keep Figma libraries from bloating when supporting two versions of every component. When do you decide to force-migrate remaining users instead of maintaining dual paths indefinitely.

ONE CONCRETE EXAMPLE: Imagine redesigning a three-step checkout. In Figma, you maintain a page called Checkout Legacy and a branch called Checkout V2 Phase 1. You create a checkout card component with a variant property named flagState set to legacy and v2. The engineering ticket for phase one references only the screens where flagState equals v2 and covers step one only. After the first cohort hits a ninety-nine percent success rate, you copy the approved v2 step into a Phase 2 page, update the variant, and archive the legacy step one frames. This keeps the file navigable and gives QA a single source of truth for what is currently live versus what is upcoming.