Figma Handover That Developers Can Actually Build
By CodexierPublished 6 min read
The gap between a Figma file and a working product is where projects lose time. The design looks finished, the developer starts building, and within a day the questions begin: what happens when the list is empty, which grey is this, does the button really need six variants. A good handover answers those questions inside the file. This guide describes what that file contains and the one meeting that catches what the file misses.
The short answer
This is the working method behind our design system and UI kit service, and it applies just as well to a single-product design as to a full system.
Components before screens
A developer builds components, then composes pages from them. If the Figma file is organised the other way, as forty screens each drawn from scratch, the developer has to reverse-engineer which buttons are the same button and which differences are intentional. Every ambiguity becomes a question or, worse, a guess. Start the file with a components page: buttons, inputs, cards, navigation, tables, modals, each with its variants defined as Figma variants and properties. Then draw the screens using only those components.
- Name components the way the code will name them: Button, Input, Card, not Rectangle 14.
- Expose variants as properties: size, state, icon on or off. A developer reads those as props.
- Detach nothing on screens. If a screen needs something the component cannot do, change the component.
- Keep one source: a shared library file that product files link to, so a change propagates.
States: empty, loading, error
Screens in a Figma file are almost always shown full of pleasant data. Real products spend much of their life empty, loading, or reporting a problem. When those states are not designed, the developer designs them at eleven at night, and the result is a blank white area or a red text string. Every list needs an empty state that tells the user what to do next. Every fetch needs a loading state. Every form needs an error state per field and a failure state for the whole submission.
| Element | States to design | Common omission |
|---|---|---|
| List or table | Empty, loading, populated, filtered to zero, error | Filtered to zero results |
| Form | Default, focused, filled, per-field error, submitting, success, server failure | Server failure after submit |
| Page | First visit with no data, partial data, permission denied, not found | Permission denied |
| Button | Default, hover, focus, active, disabled, loading | Focus ring for keyboard users |
Spacing, type and colour tokens
A design with hex codes and pixel values scattered across screens produces code with the same scatter. Figma variables let you define colour, spacing, radius and typography once, name them by purpose, and apply them everywhere. The developer then implements the same names as CSS variables or a theme object, and the design and the code share a vocabulary. Name by role, not by value: text-primary, surface-raised, space-4, not grey-700 or 16px. A named token can change value; a value cannot change its meaning.
Keep the scale small. A spacing scale of six or eight steps and a type scale of five or six sizes cover almost every interface. Every extra step is a decision the developer has to make on every screen.
Annotations and interaction notes
A picture shows what a screen looks like; it does not show what happens. Annotate next to the frame, in a consistent style, the things the developer will otherwise ask. What a button does and where it leads. Which fields are required and what the validation message says. What the maximum length of a title is and how it truncates. What happens on mobile when the table does not fit. Whether an animation is required or a nice-to-have. Figma's prototyping links help for navigation flow, but plain text notes remain the most reliable way to communicate rules.
Annotate rules, not appearance
The frame already shows appearance. Notes should cover behaviour, limits, and content rules.
Mark what is out of scope
If a screen shows a feature that is for a later phase, say so on the frame, or it will be built.
Write the copy in the file
Final button labels, error messages and empty-state text belong in the design, in both Swedish and English if the product is bilingual.
A handover review meeting
No file is complete, so plan for the gaps. Before development starts, book an hour where the developer, not the designer, drives: they open the file, walk through each flow, and ask every question as it comes up. The designer answers and writes the answer into the file on the spot. Most projects find a dozen missing states and a handful of impossible interactions in that hour, all cheaper to fix in Figma than in code. Repeat a shorter version at the end of each build phase to compare the built product against the design.
When you do not need any of this: a one-page marketing site with a single template and a developer who is also the designer can skip the ceremony and build from a sketch. The handover discipline pays off when there is more than one screen type, more than one person, or a product that will keep changing. If you are about to hand a design to a developer, or receive one, book a call and we will review the file for the gaps above; our fixed prices for design and design-system work are on the pricing page.
Frequently asked questions
Should the designer export CSS from Figma for the developer?
Developers read Figma's inspect panel themselves; exported CSS is rarely used as-is. What helps far more is variables with meaningful names, so the values the developer inspects are tokens they can map to the codebase rather than raw numbers.
Do we need to design every state for every component?
Design each state once at the component level, and it applies everywhere the component is used. Then only screen-level states such as empty pages and permission errors need individual attention. That is the practical reason to build components first.
What if the developer finds something impossible to build as designed?
That is what the handover review is for, and it is normal. Agree a rule up front: the developer proposes the closest buildable alternative, the designer accepts or adjusts within a day, and the file is updated so the design stays the source of truth.
Is a full design system necessary before a handover?
No. A component library inside the product's own file, with tokens and states, is enough for a first product. A design system as a separate maintained asset makes sense once several products or teams share the same components; we cover that decision separately.
About to hand a design over, or receive one?
Share the Figma link. In fifteen minutes we tell you which states, tokens and annotations are missing and what it will cost you in build time if they stay missing.
Book a free 15-minute call