How to Prepare Your Figma File for Development: A 12-Point Handoff Checklist
Here is a secret developers rarely say out loud: most build delays start in the design file. Missing mobile frames, three slightly different greys, a button that has no hover state, an image exported at the size of a postage stamp. Each one is small. Together they turn a quick build into a week of back-and-forth messages.
Spend thirty minutes with this checklist before handoff and your build gets faster, cheaper and closer to pixel-perfect, whether it is going to Webflow, WordPress or Shopify.
The 12-point checklist
Structure
- Use auto layout. It tells the developer exactly how things should stretch, wrap and space out. It translates almost one-to-one into flexbox and grid.
- Name your frames and layers. "Hero", "Pricing", "Footer" beat "Frame 2481" every time.
- Build repeated elements as components. Cards, buttons and nav items as components signal "build this once, reuse it everywhere".
Styles
- Define colour styles or variables. If there are 14 greys, the developer has to guess which ones you meant.
- Define text styles. A clear type scale (H1–H6, body, small) becomes a clean typography system in code.
- Stick to a spacing scale. 8, 16, 24, 32, 48, 64. Random values like 13px and 27px make "pixel-perfect" a guessing game.
Responsiveness
- Include mobile frames for every key page, and tablet if your audience uses it. Without them, someone else decides how your design behaves on phones.
- Show the max width. What happens on a 1920px monitor? Centred container, or full bleed?
States and motion
- Design hover, focus and active states for buttons, links and inputs.
- Describe interactions. A short note ("fade up on scroll", "menu slides from right") or a prototype link saves guesswork.
Assets and content
- Use real or realistic content. Lorem ipsum hides problems that real headlines reveal, like a title that wraps to four lines.
- Make assets exportable. High-resolution images, SVG icons and web-licensed fonts, all in one place.
Bonus: write a one-page handoff note
A short note travelling with the file answers most of a developer's questions before they ask them. Include:
- The target platform (Webflow, WordPress or Shopify) and who will edit the site.
- Which pages are in scope for this build, and which are "later".
- Content that should be editable or come from a CMS (blog, team, case studies).
- Form destinations: which email or tool receives inquiries.
- Links to brand fonts, the logo pack and any image library.
- Your launch date, and the one person who approves revisions.
A quick self-check before you hit share
Run these six tests on the file. Each takes a minute or two, and any "no" is worth fixing before handoff.
| Check | Quick test |
|---|---|
| Styles are used everywhere | Click a random heading and button. They should show a style name, not raw values. |
| Mobile is covered | Every page in scope has a mobile frame beside its desktop frame. |
| Components are real components | Cards and buttons show as instances of a main component. |
| Content is realistic | No lorem ipsum on key pages, and long headlines have been tried. |
| Assets are ready | Images export sharply and fonts have web licences. |
| The file is tidy | Old explorations sit on a separate, clearly named page. |
Accessibility basics to check in the file
Accessibility is far cheaper to get right in Figma than to fix after launch. A few checks cover most of it:
- Contrast. Body text and buttons should be easy to read against their backgrounds. A contrast checker plugin makes this a quick test.
- Text size. Body copy that is too small on mobile gets zoomed or skipped.
- Focus states. Keyboard users need to see where they are, so design focus states alongside hover states.
- Tap targets. Buttons and links on mobile should be big enough for a thumb, with space between them.
- Image notes. A short line on what key images show makes writing accurate alt text quick.
Platform notes: what each one cares about
Webflow
Webflow mirrors your structure closely, so auto layout and consistent naming pay off the most here. Mark which content belongs in the CMS and describe any interactions, because Webflow can build most motion without custom code. Our Figma to Webflow guide shows the full process.
WordPress
WordPress builds are organised around blocks or templates. Group your design into clear, reusable sections and say which ones editors should be able to add, move or remove. The Gutenberg vs Elementor guide explains how that choice shapes the build.
Shopify
Stores need more than a homepage. Design the product, collection and cart pages, plus states like sold out, sale price and empty cart. See how a Figma design becomes a Shopify theme for the details.
Common handoff mistakes
Designing every page at a different width
Pick one desktop width (1440px is common) and one mobile width (around 390px) and use them consistently, so measurements mean the same thing on every page.
Hidden layers and old versions
Delete or clearly archive old explorations. Developers waste time when three versions of the hero sit on top of each other.
Text inside images
Headlines baked into images cannot be edited, translated or read by Google. Keep text as text.
Effects that cannot be built cheaply
Heavy blurs over moving content, very complex masks or 3D effects can be done, but they add time. Flag them so they are quoted honestly instead of becoming a surprise.
How developers read your file
Understanding the other side helps. A developer reads your file in roughly this order: the style system (colours, type, spacing), the components, the page layouts, then the details like states and motion. The cleaner the first two layers are, the faster and more faithful everything after them becomes.
What if your file is not perfect?
That is fine, and normal. A good developer reviews the file first, flags what is missing and fills gaps using your own design rules, then shows you before launch. The checklist just shortens that conversation.
Share the file the right way
A tidy file can still slow things down if access is awkward. Share one link with view access, or edit access if you want the developer to tidy as they go. Put the pages in build order and add a cover page that says which version is final. If your team uses Figma's Dev Mode, marking frames as ready for development makes the scope obvious at a glance.
Hand it over and get it back live
When your file is ready, our 24-hour builds turn it into a live site: Figma to Webflow, Figma to WordPress or Figma to Shopify. Send the link and we will reply within the hour with a fixed quote and a note on anything in the file worth fixing.
Frequently asked questions
How long does it take to prepare a file for handoff?
For a small site with a tidy file, about thirty minutes with this checklist. A file that grew over months without styles may take an afternoon, which is still faster than sorting it out during the build.
Do I need mobile frames for every page?
For every key page, ideally yes. If time is short, design mobile for the homepage and one inner page, and let the developer follow the same rules for the rest.
Should I use Figma variables or styles?
Either works. What matters is that colours, type and spacing are defined once and used everywhere, so the developer can turn them into a matching system in code.
Can a developer fix my file for me?
Yes. A good developer flags gaps and fills them using your own design rules. It just adds a little time, so the more of this checklist you cover, the quicker the build.
What if I do not have a design yet?
Start with a brief instead. Our 24-hour website build designs and launches the site from an approved brief, so you skip the handoff step entirely.