From Figma to Frontend: A Practical UI Handoff Checklist
Tokens, states, responsive behavior, motion, and the design questions that should be answered before the first line of code.
A clean handoff isn't a Figma plugin. It's a small set of decisions made before the file is "ready for dev." When those decisions get skipped, the rebuild happens in code, in the wrong place, in front of stakeholders.
What actually goes wrong
Most handoff pain shows up at the same three places.
The empty state nobody designed
The screen exists, the data does not. Frontend ships a placeholder. The placeholder ends up in the product launch screenshot.
The error state nobody designed
A 500 from the API, a validation failure, a network drop. Frontend writes generic copy. The product feels brittle even when the engineering is solid.
The interaction nobody specified
Hover, focus, active, disabled, loading, success. Six states per button. The designer drew one. The other five get invented under deadline pressure by whoever is closest to the keyboard.
The checklist below exists to make sure all three get addressed before code starts.
Design tokens before components
Hand over the system, not just the screen. Specifically:
- Color tokens with semantic names (`surface.subtle`, `text.muted`) not raw hex. Names survive rebrands. Hex codes do not.
- Type scale with line-height paired to each size. "Heading 32" is half a spec without "leading 38."
- Spacing scale as a sequence (4, 8, 12, 16, 24, 32, 48) rather than freeform pixel values. The grid is the contract.
- Radius scale, even if it is just three values (small, default, full). It removes a class of one-off decisions.
If the tokens are not in code yet, hand them over as JSON. Style Dictionary or a hand-written tokens file is fine. The format matters less than the act of versioning them.
States, all of them
For every interactive element, the designer should have considered:
Resting and hover
Resting and hover are the easy ones. Both are usually drawn. Make sure hover is not just a color shift on touch devices, where it never fires.
Focus
Keyboard focus has to be visible. Not "subtle." Visible. A 2px ring with sufficient contrast against any background it can appear on. This is an accessibility requirement and the place teams cut corners first.
Loading, success, error
Asynchronous interactions need all three. Loading should not block the whole screen. Success should be ambient (a checkmark, a toast), not a blocking modal. Error should be specific enough to act on.
Disabled
A disabled state needs a reason. If the design doesn't say why a button is disabled, the engineer will guess, and the guess will be wrong half the time.
Responsive behavior
Frame the breakpoints explicitly, even if it is just "this layout breaks below 768px and rearranges to this." Don't ship a desktop frame and a mobile frame and assume frontend will interpolate.
For each breakpoint, decide:
- Which elements collapse, which stack, which disappear.
- How navigation behaves below the breakpoint.
- Whether the page-level container has a max-width on large screens (it should, ~1480px is a good default).
Motion
Motion is the part of a UI that feels expensive when it is wrong and invisible when it is right.
- 01
Spec the duration and easing "It animates" is not a spec. "240ms, ease-out (0.2, 0, 0, 1)" is a spec. Every motion in the file should have both numbers.
- 02
Decide what does not animate A spinner does not need a fade-in. A toast does not need a spring. Restraint reads as confidence.
- 03
Respect reduced motion A user who has set `prefers-reduced-motion` should still get a working product. Map every motion to a reduced equivalent (usually: instant transition, no parallax, no auto-playing video).
Accessibility notes
The designer doesn't need to write the ARIA. They do need to flag:
- Color combinations that fail WCAG AA contrast. A 4.5:1 ratio for body text, 3:1 for large text.
- Components that need keyboard semantics beyond the default (modals, tabs, comboboxes, menus).
- Form fields that need labels, hints, and error association.
The fifteen-minute conversation that saves a week
Before the file is "ready for dev," sit down for fifteen minutes and walk through:
1. What is the smallest version of this we can ship? 2. What happens when each API call fails? 3. What does this look like with no data, with too much data, and with weird data? 4. Which interactions are critical to the feel, and which are decoration?
That conversation costs you fifteen minutes and saves you a week of rework. It is the single highest-leverage thing on this list.
Build the AI layer you'd be proud to ship.
If your roadmap has voice, copilots, RAG, or agentic flows on it, the booking link below is the right move. 30 minutes, no pitch, straight answer on whether I can help.