When a build doesn't match the design, the developer usually gets the blame. But a lot of drift starts earlier, in a Figma file that left too many decisions to guesswork.
A developer working from an ambiguous file has to make calls. What's the spacing between these cards on tablet? Is this grey the same grey as the one on the other page? What happens when the heading runs to three lines? Each call is small. Together they're the reason the live site feels slightly off.
A good handoff removes the guesswork. Here's what it needs.
Name the pages after the site, not the process
“Homepage v4 final FINAL” tells a developer nothing about which frame is the real one. Name pages and frames after the URLs they'll become, and archive old versions somewhere clearly separate.
This matters again later, when you check the build against the design. If the frame for /pricing is called “Pricing”, matching them up takes seconds.
One frame per page, named after the page. Variants and explorations live on a separate Figma page called something like “Archive”, so nobody builds from them by accident.
Use styles and variables, not one-off values
If a colour, font size or spacing value is a style or variable, the developer can map it straight to a token in the build. If it's a one-off hex code typed into a single layer, they'll either copy it exactly, creating a near-duplicate, or round it to the nearest token, creating drift.
Show the states, not just the happy path
Hover and focus states for buttons and links. Empty, error and success states for forms. What a card looks like with a long title. What the nav does on mobile. If it isn't in the file, it'll be invented during the build.
Design at least two breakpoints
Desktop-only files are the single biggest source of responsive drift. You don't need every breakpoint, but a desktop and a mobile frame for each template give the developer a clear start and end point.
Figma Handoff Checklist
7 checksWrite down the decisions you made
A short note on the cover page goes a long way: which frames are approved, what's out of scope, anything that's intentionally different from the design system. Developers can't ask the file why something looks the way it does.
Handoff is a conversation, not a file
Even a perfect file leaves questions. The fastest teams treat handoff as a short meeting rather than a link in Slack: half an hour where the designer walks the developer through the file, points out anything unusual, and answers the questions that would otherwise be guessed at.
It's also the moment to agree what “matching the design” means. Pixel-perfect at the designed widths? Faithful to the system, with sensible decisions in between? Writing that down saves an argument later.
Keep the file current during the build
The file and the build drift apart in both directions. A developer finds a better solution and the design never gets updated. A designer tweaks a frame after the developer has built it and nobody mentions it. A week later, nobody knows which one is right.
A simple rule helps: if the build changes something visible, the file gets updated the same day. If the file changes after handoff, the developer gets told. Either way, there's one source of truth, and it's the design the client approved.
Do This
- Walk the developer through the file in a short call
- Agree what “matching the design” means up front
- Update the file when the build changes something visible
- Tell the developer when a frame changes after handoff
Avoid This
- Dropping a Figma link in Slack and moving on
- Leaving explorations next to the approved frames
- Tweaking frames quietly after the build has started
- Treating the file as finished the day it's handed off
When you set up a project in Frank, you map each page of the live site to its Figma frame. A well-named file makes that a two-minute job, and from then on every page shows the live build side by side with its design. Get started with Frank →
A Cleaner Handoff Means a Cleaner Review
Prepare the file properly, then check the build against it page by page before your client does.
