From Figma to Code: What a Good Design Handoff Actually Includes
"Here's the Figma link" is the starting point of many handoffs and the source of most of their problems. The file opens, the screens look great, and then the developer starts asking questions that were never asked in the other direction: what happens when this list is empty, what's the mobile version of this table, what does the button say after it was clicked once.
Designers aren't hiding information. They just weren't handed a checklist either. Here's the one we work from.
What needs to be in the file
Every state of every component. A button has more than a default state: hover, active, focus, disabled, loading. The input has error, focus, filled, disabled. If only the happy path is drawn, developers invent the rest, invent it differently per component, and the UI ends up inconsistent in ways nothing in the design file ever suggested.
The unglamorous screens. Empty states, loading states, error messages, 404 pages, and long-content states — a product name that wraps to three lines, a table with one column too many. These screens get no applause but they decide whether the product feels finished.
Real text, not lorem ipsum. Lorem copy hides layout problems with line lengths and makes developers guess the tone of labels, buttons, and validation messages. Placeholder text is also where most micro-copy decisions live, and those decisions have to be made by someone before launch.
Design tokens made explicit. Colors with their actual hex values, spacing as a scale (4/8/12/16, not "some space"), typography with sizes and weights per role. If it's only visible as pixel measurements on individual frames, every new screen becomes a forensic exercise. A published variable set in Figma solves this; a page with swatches solves it well enough.
Responsive rules, stated not implied. Which columns hide at tablet, where does the sidebar end up on mobile, what triggers the switch between the desktop and mobile navigation. A developer can guess, and will, and each guess is a small future review comment.
The review that catches things early
The single highest-value step costs one hour: a walkthrough where the designer presents the screens while the developer asks "how does this behave" out loud. In our experience, a third of the useful questions come out of this session, and no question is ever as cheap after the build has started.
The questions worth asking are almost boring:
- What happens if the image fails to load, or the user has no avatar?
- What does this screen look like with 500 items instead of 5?
- Which of these interactions are animated, and how?
- Is anything here keyboard-reachable differently than it looks?
Write down the answers where the file lives, not in a chat thread. Figma comments on the relevant frame are fine.
What the developer owes back
A handoff runs both ways. The developer's side of the contract: build from the tokens, not from pixels; raise gaps instead of silently filling them; and when a design decision turns out to be expensive in implementation (a table that doesn't fit mobile, an animation that drags on mid-range phones), say so with an alternative rather than either complaining or silently building a worse version.
The best handoffs we've had weren't the ones with the most polished frames. They were the ones where both sides had agreed which questions each was allowed to ask the other, and nobody solved problems alone that should have taken five minutes together.