From Figma to Production: A Designer–Developer Handoff Playbook
I have worked on roughly forty projects where a designer hands off Figma files to me or another engineer. The ones that ship smoothly and the ones that fall apart have almost nothing to do with Figma itself. They have everything to do with whether the handoff includes the things developers actually need — and most handoffs do not.
This post is the short, opinionated playbook I use with design partners now. Five failure modes to avoid, and a checklist that prevents 90% of the back-and-forth.
Why handoff breaks
Handoff rarely breaks because the designer was sloppy. It breaks because the two sides have different mental models of what a component is. A designer sees a rectangle with a label. A developer sees a component with props, states, responsive behavior, accessibility requirements, loading variants, and error states. The Figma file rarely captures the full matrix.
The five recurring failures
- Missing states: only the happy path is designed. Hover, focus, active, disabled, loading, and error are absent or inconsistent.
- Unnamed tokens: colors and spacing are hardcoded hex values and pixel numbers instead of named variables, so nothing is reusable in code.
- No responsive breakpoints: the mobile layout is either missing entirely or drawn at one arbitrary width that does not match the dev breakpoints.
- Inconsistent spacing scale: margins and padding use values like 13px, 17px, 22px — unrelated to any 4px or 8px grid.
- Invisible interactions: animations, transitions, and micro-interactions are described in Slack messages instead of the file itself.
A handoff checklist that actually works
- Design tokens live in Figma variables — colors, spacing, font sizes, radii — and their names match the Tailwind config exactly
- Every interactive component has five states: default, hover, focus, active, disabled. Forms add two more: loading and error
- At least two breakpoints are designed: mobile (375px) and desktop (1440px). Tablet is usually interpolated, not designed
- Spacing follows a 4px or 8px scale. No 13px margins. No 22px gaps. Ever.
- Component names in Figma match component names in the codebase. Button, not Rectangle 42.
- Interactions (hover transitions, modal animations, page transitions) are either recorded as short screencasts or described in a Notion doc linked from the frame
- Accessibility is explicit: focus order, ARIA labels, contrast ratios verified, keyboard navigation described
- An async review happens every Friday: the designer and developer walk the Figma file together, update what has drifted, and close the loop
“The best designer–developer collaborations I have been part of treated Figma and the codebase as two views of the same design system — not as upstream and downstream.”
The tools I actually use
Figma for design, with variables mapped one-to-one to Tailwind tokens. Storybook for component documentation on the developer side — every component in Figma has a matching Storybook entry. Loom for async walkthroughs when a static screenshot is not enough. Linear for tracking design changes that need developer follow-up. That is it. No Zeplin, no Avocode, no handoff plugin. The overhead is not worth it once design tokens are synchronized.
Most important, though, is mindset: treat the first sprint of a new project as a calibration sprint where designer and developer align on conventions before shipping anything. Two days of calibration saves two weeks of rework.
If your team is stuck in a handoff loop and you want an outside perspective — get in touch. I have run this playbook with design partners from solo freelancers to in-house product teams, and the fix is usually simpler than expected.
Need help with your project?
Let’s talk about your technical requirements. I offer a free discovery call where we’ll discuss architecture, tech stack, and timeline.
View my services