A Figma handoff checklist is a binary pass/fail review that catches incomplete design files before they reach code. We run this 18-point version at the start of every Figma to WordPress project so developers open the file with answers instead of a queue of questions. Work through the table top to bottom; one failed row means the handoff is not ready.
The checklist spans file structure, components, tokens, states, breakpoints, imagery behavior, and motion notes. It is short enough for a project manager to run in a single review and strict enough to protect the schedule when several client deliveries overlap.
Why Figma handoffs break down
Handoffs rarely fail because the mockups look wrong. They fail because a static frame cannot answer what happens on hover, which token is the real primary at body size, how the layout collapses between 768px and 1024px, or whether a hero image should lazy-load. When those answers live in chat instead of the file, developers either stop to ask—instant context switching—or invent defaults, which resurface later as redesigns in code. Both outcomes erode the margin on white-label work.
A checklist turns taste into a gate. Design knows exactly what done looks like before handoff, engineering trusts the file enough to build without side conversations, and the agency gets a repeatable quality bar across accounts instead of relying on whoever is staffed that week. The surrounding workflow lives in our white-label Figma to WordPress process guide if you need the full delivery picture.
The 18-point Figma handoff checklist
Every row is yes or no. If any row is no, send the file back before templates are built.
| # | Area | Check | Passes when |
|---|---|---|---|
| 1 | Layers | Page and layer names are semantic | No “Frame 422”; names match content or component purpose |
| 2 | Layers | Structure is grouped by section | Header, main, and footer groups exist; no orphan layers on the build page |
| 3 | Layers | Hidden and unused layers removed | Exploration variants sit on an archive page, not the page being built |
| 4 | Components | Repeated UI is a component | Buttons, cards, and nav items are instances, not detached copies |
| 5 | Components | Variants cover real states | Hierarchy (primary/secondary), size, icon on/off, and disabled where the UI uses them |
| 6 | Components | Instance overrides are intentional | Text or icon swaps happen through variants or overrides that are documented in the file |
| 7 | Tokens | Color styles or variables defined | No raw hex on shared components; primary, secondary, surface, text, border, and feedback exist |
| 8 | Tokens | Type scale documented | Named styles for display, heading levels, body, and small; weights and line-heights set |
| 9 | Tokens | Spacing and radius consistent | Reusable spacing steps (for example a 4/8-based scale) and one radius scale per surface type |
| 10 | States | Interactive states designed | Default, hover, focus-visible, active, and disabled for every control |
| 11 | States | Content states included | Empty, loading, error, and long-text cases shown—or explicitly waived in writing |
| 12 | States | Focus treatment is visible | Focus ring stays clear on every background the control appears on |
| 13 | Breakpoints | Key breakpoints designed | Desktop, tablet, and mobile frames exist for each template—not a single artboard only |
| 14 | Breakpoints | Behavior between frames noted | Column collapse, image crop, and navigation switch (including the menu pattern) are stated |
| 15 | Imagery | Assets are final or labeled | Real photos or illustrations in place, or placeholders tagged replace with target ratios |
| 16 | Imagery | Crops and focal points set | Artboards show the intended crop; responsive crop rules are written down |
| 17 | Imagery | Export plan defined | Formats, dimensions, and ownership of alt text are agreed before build |
| 18 | Motion notes | Animation intent documented | Per section: trigger, what moves, duration, easing, and reduced-motion behavior |
Motion notes belong in the handoff
A frame cannot show that the hero staggers on load, that cards lift on hover, or that route changes crossfade. Add a short motion note beside each page or section: trigger, elements involved, duration, easing curve, and what happens when the user prefers reduced motion. Ambiguity here is how a tasteful prototype becomes a performance problem in production.
Decide the motion system before build starts. Our GSAP motion systems in production guide covers structuring timelines so they stay maintainable, and page transitions without killing INP explains why heavy route changes can push interaction latency past the 200ms Core Web Vitals threshold. Accessibility is not a late QA task: fold prefers-reduced-motion expectations into the same note so engineering implements it once, correctly. For interface-heavy motion scopes, our motion web development service starts from this handoff format.
Scope disputes are a second common failure. If design added sections the statement of work never covered, that conversation belongs with your delivery partner early—white-label pricing models explains how project and sprint boundaries are usually drawn before anyone eats the overage.
Key takeaways
- Run the 18 points as a gate, not a suggestion: one failed row blocks the build. The review takes minutes and removes days of clarification later.
- Keep tokens, states, breakpoints, imagery rules, and motion notes in the file. Anything that only exists in chat will be missed when the deadline is real.
FAQ
Who should run the Figma handoff checklist?
The developer who will implement the file should own the final review, with the project manager tracking completion. Design can self-audit first, but the pass that counts needs someone who knows which ambiguities turn into bugs. Splitting ownership across roles with no single closer is how rows quietly get skipped.
How many breakpoints must be designed?
Three is a practical minimum for marketing and content sites: one desktop, one tablet, and one mobile frame per template, plus notes on what happens between them. Exact pixel values matter less than documented behavior for column collapse, image cropping, and the navigation switch. If a template is identical across widths, state that explicitly instead of shipping one artboard by omission.
What if design cannot provide every state?
Waive the gap in writing and log it. A missing empty state that engineering improvises will not match the next component design ships. Partial handoffs are acceptable only when the hole is recorded, owned, and scheduled—never when it is discovered mid-sprint after templates are already built.
Should motion be specified in Figma or in a separate document?
Either works if it is attached to the handoff. Comments on the frame keep context tight; a linked one-pager scales better when several sections animate. What fails is motion described only in a kickoff deck three weeks earlier. Always include reduced-motion behavior in the same note so it is not treated as optional polish.
How does this checklist help white-label delivery specifically?
When the end client never sees the delivery partner, ambiguity cannot be resolved in a quick side call. The file has to carry full intent on its own. A strict handoff is how white-label web development stays predictable for the agency that owns the client relationship.