Blog / Design to Code
The Figma handoff checklist I send every designer before I build
The short version
- I have built seven WordPress themes from Figma files. File quality varies enormously.
- The gap between a good file and a loose one is roughly a week of my time.
- This is not a demand that you work my way. It is the list of things I will otherwise guess.
I have built seven WordPress themes from Figma files. Some arrived as component libraries with variants, tokens and named text styles. One arrived as a single frame called Homepage FINAL v4 (use this one).
Both are workable. But the gap between them is about a week of my time, which is somebody’s money.
So here is what I now send before quoting. It is not a demand that designers work my way, and it is not a complaint. It is the list of decisions that exist whether or not the file answers them. If the file does not, I make them up, and my guesses are more expensive than your answers.
1. States, not just the happy path
The single most common gap. A file will have a beautiful button and no indication of what it looks like on hover, on focus, while submitting, or when disabled.
Focus states matter most and get drawn least. They are how keyboard and screen reader users navigate, they are a legal accessibility requirement in Ontario under the AODA, and if you do not draw one I will invent one that probably does not match your intent.
2. Empty and error states
What does the search results page look like with no results? What does the contact form look like when the email address is invalid? What does the project gallery look like on day one, before the client has added any projects?
Every one of these will happen. The empty state in particular is what the client sees the very first time they log in, which makes it the state that shapes their opinion of the whole build.
3. The middle breakpoint
The 900px problem
Most files contain a 1440px desktop frame and a 375px mobile frame. Almost none contain anything in between, and a large amount of real traffic sits at tablet widths and small laptops. If nobody draws it, the developer designs it, at build speed, without you in the room.
I do not need every breakpoint drawn. I need to know what you want to happen: does the three-column grid go to two or straight to one? Does the sidebar move above or below? Two sentences will do.
4. Real content, or at least realistic content
Lorem ipsum has a suspiciously even texture that real language never has. Real project names are longer than you think. Real German or French translations are longer still.
Show me the longest realistic headline and the longest realistic person’s name. If the card breaks, better we find out in Figma than in production.
5. Components that are actually components
If a card appears on six pages, it should be one component with variants, not six copies that drifted apart. Not because I need it tidy, but because copies tell me nothing about intent.
When I see six similar cards with 4px of padding difference, I cannot tell whether that is a deliberate variant or a mistake. If it is a component, the answer is unambiguous, and it becomes one Blade partial instead of six.
6. Text styles, not one-off sizing
Named text styles become a type scale in code, which becomes the only set of options your editors can pick from. That is what stops pages drifting off-brand two years later.
If every heading is hand-sized, I have to reverse-engineer the scale from the values you used, and I will get it wrong wherever you were improvising.
7. A spacing system, even a loose one
Spacing on a consistent scale, usually multiples of 4 or 8, converts directly into code. Spacing that drifts between 22px, 26px and 25px does not, and I have to decide whether those differences are intentional.
They almost never are. But I cannot know that without asking, and asking about every measurement is how a project develops a bad mood.
8. Which parts the client will edit
This one is not visual and it changes the build more than anything else on the list.
Every section that the client can change becomes an ACF field group and a custom block. Every section that is fixed can be hard-coded in a template. Building everything as editable is slow and gives editors enough rope to wreck the design; building nothing as editable means they call me to change a phone number.
Marking up the file with what is editable takes ten minutes and it is the highest-value ten minutes in the whole handoff.
9. Assets, exported and named
Icons as SVG, logos as SVG with a transparent background, and photography at the actual resolution rather than scaled down inside a frame. I can pull assets out of Figma myself, but I will pull them at the size you placed them, which may not be the size you meant.
What good handoff actually looks like
Costs a week
One frame per page, text hand-sized, six near-identical cards, no states, no annotation, assets embedded at display size.
Costs an afternoon
Components with variants, named text and colour styles, hover and focus drawn, one note on breakpoint behaviour, editable regions marked.
The second file is not more work to make. It is mostly the same work done in a way that records the decisions rather than only the result.
A Figma file is not a picture of a website. It is a specification, and the parts it leaves out get specified anyway, just by somebody else.
What I do when the file is loose
I still build it. Most files are somewhere in the middle and that is completely normal.
What changes is the first step: I go through the file and write down everything I am about to assume, then send that list back before I start. It takes an hour and it has never once been a wasted hour, because roughly a third of my assumptions turn out to be wrong and all of them are cheaper to fix in an email than in a theme.