Describe your process for preparing a high-fidelity Figma file for developer handoff
Tests operationalizing the design-engineering boundary. Strong answers cover file structure, auto-layout tokens, responsive annotations, all UI states, and exported assets with naming conventions.
WHAT THIS TESTS: This question evaluates whether you understand developer handoff as a systems and communication problem, not merely a visual fidelity exercise. Interviewers want to see that you reduce cognitive load for engineers by encoding decisions into the file rather than relying on synchronous explanations.
A GOOD ANSWER COVERS: First, file hygiene and structure. Mention separating exploratory work from signed-off screens, using a single source of truth page, and archiving old iterations so developers do not accidentally build the wrong version. Second, component and token discipline. Describe using auto-layout, constraints, and semantic color or spacing tokens so that inspect-mode values map cleanly to the codebase. Third, behavioral annotations. Call out responsive breakpoints, max-widths, truncation rules, and how grids behave between mobile and desktop. Fourth, exhaustive states. Include empty, loading, error, disabled, hover, active, and focus states rather than assuming engineers will infer them. Fifth, asset preparation. Export icons as SVGs with preserved bounding boxes, provide raster images at 1x and 2x or 3x densities, and use consistent naming conventions. Sixth, interaction and motion specs. Document transition timings, easing curves, and prototype flows for anything beyond static layout. Seventh, accessibility notes. Specify color contrast ratios, focus order, screen reader labels, and minimum touch targets of 44 by 44 points. Finally, the handoff ritual. Mention scheduling a walkthrough meeting and leaving Figma comments for open questions.
COMMON WRONG ANSWERS: Saying you just share the link and developers can inspect it themselves. Treating handoff as a single moment rather than a process with feedback loops. Focusing only on perfect pixels while ignoring edge cases, responsive behavior, or state variations. Failing to mention design tokens or auto-layout, which signals you have not worked at scale. Claiming that redline plugins replace structured thinking.
LIKELY FOLLOW-UPS: How do you keep the Figma library in sync with production when drift occurs? What do you do when a developer pushes back saying a micro-interaction is not performant? How do you document complex gestures or conditional logic that prototypes cannot capture? Tell me about a handoff that went wrong and what you changed.
ONE CONCRETE EXAMPLE: A strong candidate might describe a checkout redesign where they created a dedicated handoff page containing only approved screens. Every frame used auto-layout with an 8px baseline grid and referenced semantic tokens for surfaces, text, and borders. A sticky-note layer annotated that the summary card collapses to a bottom sheet below 768 pixels and that input fields show a skeleton state for 400 milliseconds before content loads. Icons were exported as 24 by 24 pixel SVGs, and hero images were provided as WebP at 1x and 2x with descriptive file names. The candidate documented that primary buttons have a 2 pixel focus ring with a 3 to 1 contrast ratio and that the success toast animates over 250 milliseconds using an ease-out curve. They ran a 20 minute sync with the frontend engineer to click through the prototype, then moved the ticket to ready for dev only after the engineer confirmed asset receipt in the Figma comments.
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.