The design handoff is where most website projects quietly go wrong. The Figma looks perfect. The build looks close. But "close" is where the arguments start — a heading that's 600 weight instead of 700, 32px of padding that became 24px, a card grid that drifts at tablet width. Nobody notices in a pull request. Everyone notices after launch.
This is a design handoff checklist for teams shipping real websites — what actually breaks between design and production, how to catch it before it ships, and a process that closes the gap without turning every review into a pixel-counting standoff.
Why design handoffs still break in 2026
Design tokens jumped from 56% to 84% adoption in one year. Figma-to-code pipelines exist. AI can scaffold a component from a frame. And yet, 91% of developers and 92% of designers still say the handoff process needs improvement. Why?
Because the tooling solves the artifact gap — getting specs, tokens, and measurements to the developer. It doesn't solve the context gap: the intent behind a design decision. A developer looking at a Figma frame sees a layout. They don't see why the card has 48px padding (to give the testimonial room to breathe), or why the CTA is indigo instead of the secondary blue (because research showed it converts better). Without the why, implementation becomes interpretation — and interpretation is where rework begins.
The two gaps that cause rework
The context gap
Missing intent. The team doesn't know why the UI looks the way it does — the user problem, the business rule, the research insight, the edge case that drove a decision. When a developer has to guess intent, they make reasonable calls that happen to be wrong.
The artifact gap
Missing build details. The visible design exists, but the spec is half there: missing states (loading, empty, error), unspecified responsive breakpoints, no hover/focus styles, token names that don't match the codebase. The developer fills in blanks and hopes for the best.
Most handoff failures aren't about bad tools or careless developers. They're about a design that's finished for presentation but not finished for engineering.
The design handoff checklist
Run this before handing any page to development. Every item you catch here is a revision round you don't run later.
Before handoff (designer)
- 1Every component has all states designed: default, hover, focus, active, disabled, loading, empty, and error. If a state doesn't apply, delete the frame — don't leave it undesigned.
- 2Responsive layouts are specified at desktop, tablet, and mobile. Not "it should stack" — actual frames showing how it stacks, what reorders, and what hides.
- 3Spacing and sizing use the shared token scale, not magic numbers. If you used 13px instead of 12px or 16px, note why.
- 4Colors and type styles reference named tokens, not hex values. "Brand/Primary" not "#394DF3".
- 5Every interactive element has a note on behavior: does it open a modal, navigate, submit, or toggle? What happens after?
- 6Edge cases are called out: What if the title is 80 characters? What if the list is empty? What if the user has no avatar?
- 7Assets are exportable: icons at the right size, images with clear crop guides, any illustration as SVG.
During handoff (designer + developer)
- 1Walk through the design together — 15 minutes, not async. The designer explains intent; the developer flags what's hard to build. This one conversation prevents more rework than any spec doc.
- 2Agree on what's exact vs. flexible. Some spacing is precise (the hero layout); some is approximate (the blog body). Say which is which so the developer knows where to be strict.
- 3Identify anything the design assumes but the data doesn't guarantee: a name that's always short, a list that's always five items, an image that's always landscape.
- 4Document the three things the developer will definitely forget or get wrong — every project has them. Put them in a pinned comment, not buried in a 40-frame Figma file.
After build (design QA)
- 1Compare each page against its Figma design — not by memory, not by switching tabs, but by overlaying the design on the live page. Tab-switching catches big layout errors; an overlay catches the 4px drift, the wrong font weight, the misaligned icon.
- 2Check at every breakpoint. The most common design handoff bugs live at tablet width — it's the breakpoint designers spec last and developers test least.
- 3Log every mismatch as a pinned comment on the exact element, not as a list in Slack. "The card padding is 24px, should be 32px per the design" anchored to the card beats "spacing seems off somewhere on the pricing page."
- 4Distinguish bugs from intentional deviations. If the developer changed the padding for a real reason (the Figma didn't account for dynamic content), that's a conversation, not a bug. Mark it, discuss it, and move on — don't revert a thoughtful call.
The overlay method: stop switching tabs
The single biggest time-saver in design QA is comparing the design against the live build in the same viewport. Here's why tab-switching fails: your eyes retain a general impression for about 200 milliseconds. By the time you switch from the Figma tab to the staging tab, you've already lost the precise spacing, weight, and alignment you were checking. You're comparing memories, not pixels.
An overlay puts the design image directly on top of the live page at adjustable opacity. At 50%, every mismatch lights up: a heading that's two pixels too high, a button that's the wrong width, a section that drifts at 768px. You catch in 30 seconds what tab-switching misses in five minutes.
See how overlay comparison works on a live page: Design compare in UX Peeker →
What "pixel-perfect" actually means in 2026
Strict pixel perfection — matching every measurement to the exact pixel across every browser and device — is neither possible nor desirable on the modern web. Fonts render differently across operating systems. Browsers have sub-pixel rounding differences. Content is dynamic. Responsive layouts flex by definition.
What "pixel-perfect" should mean today is: the build is faithful to the design's intent. The visual hierarchy is right. The spacing rhythm is consistent. The typography matches. The interaction feels the way the designer intended. And when there's a deviation, it's deliberate and documented — not accidental and invisible.
The goal is not that every pixel matches. The goal is that every difference is a decision, not an accident.
Common handoff mistakes (and what to do instead)
- Handing off a "finished" Figma with no states designed — the developer invents the loading, empty, and error states, and they're always wrong. Design them.
- Specifying desktop only and saying "it should be responsive" — that's a design brief, not a handoff. Spec the breakpoints.
- Using one-off hex values instead of tokens — this guarantees drift. Name your colors and use the names.
- Reviewing by memory instead of overlay — you'll catch the big errors and miss everything subtle. Overlay the design on the build.
- Treating every mismatch as a bug — some differences are improvements. The developer was closer to the content than the designer. Mark deviations as "accepted" or "bug" so the team stops re-litigating the same items.
- Giving feedback in Slack or email instead of on the live page — the developer has to find the element, guess the breakpoint, and hope they found the right one. Pin it.
Run the whole handoff QA in one place
UX Peeker puts design handoff QA in one workspace: overlay your Figma design on the live build with an opacity slider, review across desktop/tablet/phone breakpoints, and pin every mismatch as a comment on the exact element. Each comment becomes a tracked task automatically, so nothing gets lost between "that's wrong" and "that's shipped." Your Figma files sync directly into the overlay — no manual export needed.
Start comparing your design against the live build: The website feedback tool for live pages →