There's a particular kind of Figma file that takes three days to build and another that takes seven, and the difference is almost never the complexity of the design.
It's whether the file was made with the browser in mind. A developer opening a well-prepared file starts building. A developer opening a badly prepared one starts guessing, and every guess is a decision you didn't get to make.
Here's what separates the two.
Auto layout on everything
Auto Layout is Figma's version of flexbox — the thing browsers actually use to lay out pages. It tells the developer how a frame should behave when its contents change: which direction things stack, how much space sits between them, what stretches and what hugs.
A frame built without it is a photograph of a layout. Someone has to work out whether that 32px gap was deliberate or just where the text happened to end, and sometimes they'll get it wrong.
Use it on every section, every card, every button group. Set the gap values deliberately. Use fill and hug so it's obvious what grows.
Real styles, not one-off values
Every colour should be a colour style. Every text treatment should be a text style. These map directly onto variables and classes in the build.
A file with forty hand-picked greys is asking a developer to invent a system on your behalf, halfway through a project, without asking you. They will, because they have to.
If you're using Figma variables, better still — they translate almost one-to-one into CSS custom properties.
A spacing scale you actually stick to
Pick a set of values and refuse to deviate: 4, 8, 12, 16, 24, 32, 48, 64, 96.
Two reasons this matters. A developer can tell the difference between a deliberate value and an accident. And the whole thing can be expressed as a small set of spacing utilities, which means changing the rhythm of the site later is a handful of edits rather than hundreds.
Same goes for type. A real scale with ratios, not sizes picked by eye.
Components, not copies
Real components with variants, not duplicated frames. If your design has four cards that are "basically the same but slightly different", resolve that in the design rather than shipping four cards.
The developer will build components either way. If you've already decided which pieces are reusable, they build the ones you meant.
Design the states nobody asks for
This is where most files are thin. A design that only shows the happy path leaves a dozen decisions to whoever is building.
Cover these:
- Hover and focus on every interactive element
- Error states on every form field, with the actual wording
- Empty states — what a filtered list looks like when nothing matches
- Loading, if anything takes time
- The longest and shortest realistic content in every flexible container
- A card with no image, if that's possible in your CMS
None of this is glamorous. All of it is the difference between a site that holds up and a site that only works in the screenshot.
At least two breakpoints
Desktop and mobile as a minimum. If a layout does something unusual in between — three columns becoming two before becoming one — show that too.
If you only supply desktop, someone else is designing your mobile experience, and it will be the developer, at speed, under deadline.
Name things like someone else will read them
"Frame 428", "Rectangle 12 copy 3" and "Group 91" are the design equivalent of unlabelled boxes in a loft.
Name components for what they are and what they do: `card / case-study`, `button / primary`, `section / hero`. It feeds directly into how someone understands the structure, and increasingly into how conversion tools interpret it.
Export-ready assets
- Images at roughly twice their display size, not the 6000px original from the camera
- Logos and icons as SVG
- Fonts identified by name, with the licence available
- Anything that needs transparency, flagged
A developer chasing a logo file for two days is a genuinely common way to lose a week.
A pre-handover checklist
Run through this before sending the link. Nine items, about twenty minutes.
- Auto Layout on every section, card and button group
- Colour and text styles defined, and actually applied
- Components with variants, not duplicated frames
- A spacing scale in evidence, with no stray values
- Desktop and mobile for every page
- Hover, focus, error and empty states designed
- Real copy, or at least realistic copy lengths
- Images exported at usable resolution and named
- Fonts identified, with the licence available
A file that passes all nine builds roughly a third faster than one that passes five.
Who should own what
A useful split, if you're deciding where the line sits:
The designer owns the system — the styles, the components, the spacing scale — and every visual decision including what happens at each breakpoint.
The developer owns the structure, the class naming, performance, accessibility mechanics and how the CMS is organised.
Both own the states. Designers tend to forget them; developers tend to invent them. Agreeing them together before the build is the cheapest hour in the project.
Questions we get asked
Do the Figma-to-code plugins make this unnecessary?
They've improved a lot and they're useful for getting a section into the browser quickly. What they can't do is make the architectural decisions — which pieces are components, what the class system is, how the CMS is structured. On a well-prepared file they save time. On a messy one they produce something nobody can maintain.
How much time does good preparation actually save?
On a typical eight-page marketing site, we'd estimate a well-prepared file builds around a third faster than a poorly prepared one. That's the difference between an estimate and a nasty surprise.
What if the design was made by someone else and it's a mess?
It's normal, and it's fixable. The first thing we do on an inherited file is an audit: list the unique components, agree the spacing and type systems, and then build. It costs a day at the start and saves several later.
If you have a Figma file waiting to be built, send it over. We'll tell you honestly what state it's in before we quote.