Figma to Development Handoff: A 2026 Checklist for Designers and Agencies

Why handoff decides budget and timeline

A developer estimates what they can see. When a screen is missing, a button has no hover state or the text in the mockup is shorter than the real copy, someone has to decide how it should work. Either the developer guesses and the designer asks for changes later, or the work stops while everyone waits for answers.

Both cost time and money. A clear handoff turns those open questions into decisions before development starts, so the estimate is accurate and the result matches the design.

1. Layouts for every screen size

Since July 2024, Google crawls and indexes all websites with its smartphone crawler. If content or a feature exists only on desktop, Google may not see it at all. Mobile is not a scaled-down version of the site; it is the version search engines judge you by.

Prepare:

• Mobile (around 375 px) and desktop (1440 px) for every page template.
• Tablet only where the layout actually changes, for example a menu or a grid.
• Notes on what happens between breakpoints: what stacks, what hides, what scrolls.

2. Interactive states

Static screens show the happy path. Real users click, wait, make mistakes and land on empty pages.

Prepare:

• Buttons and links: default, hover, focus, active, disabled.
• Forms: empty, filled, error with message, success, sending.
• Data: loading, empty state ("No projects yet"), error state.
• Navigation: open and closed mobile menu, current page.

The focus state is often forgotten. It shows keyboard users where they are on the page, and it is required for accessibility.

3. Motion

"Smooth animation on scroll" means something different to every person. A short reference removes the guesswork.

Prepare:

• A video or prototype for every non-trivial animation: what triggers it, how long it takes, how it eases.
• What should happen on mobile, where hover doesn't exist and performance is lower.
• A reduced-motion version. Browsers let users ask for less motion (the prefers-reduced-motion setting), and the site should respect it.

4. Components and styles

A consistent Figma file becomes a consistent codebase.

Prepare:

• Colours, type and spacing as Figma variables or styles, not one-off values.
• Repeating elements as components with variants (button sizes, card types).
• Auto layout where the element should stretch or wrap.
• Clear layer and page names, and a page that marks what is final and what is a draft.

5. Real content

Lorem ipsum hides problems. A headline that fits in the mockup can break the layout when the real one is twice as long, or when the site launches in a second language.

Prepare:

• Real or realistic text for every block, including the longest expected title.
• All language versions, or at least the longest one.
• One H1 per page marked in the design, and the heading order below it.
• Page titles and meta descriptions, or a note on who will write them.

6. Assets and fonts

Prepare:

• Icons and logos as SVG.
• Photos and illustrations in the highest available quality; the developer will compress and convert them.
• Videos with a poster frame.
• Fonts with a licence that covers web use. A desktop licence often doesn't include embedding the font on a website.

7. Accessibility basics

Accessibility is cheaper to design than to retrofit, and for many businesses selling to EU customers it is now a legal requirement: the European Accessibility Act has applied since 28 June 2025.

Check in Figma:

• Text contrast of at least 4.5:1, or 3:1 for large text (WCAG level AA).
• Tap targets of at least 24×24 px, or enough space around smaller ones (WCAG 2.2, criterion 2.5.8).
• A visible focus state for every interactive element.
• Meaning that doesn't depend on colour alone, for example errors with an icon and a message, not just red text.

8. Performance-aware design

Google measures how fast real visitors experience a page with Core Web Vitals. A page passes when the main content loads within 2.5 seconds (LCP), the page reacts to taps within 200 milliseconds (INP), and the layout shifts less than 0.1 (CLS).

Design decisions affect all three:

• A heavy autoplay video or large 3D scene in the first screen slows down LCP, especially on mobile.
• Many font families and weights add load time. Two families with a few weights is usually enough.
• Elements that appear late (banners, cookie bars, embedded widgets) push content down and hurt CLS unless their space is reserved.

This doesn't mean avoiding motion or 3D. It means deciding where they matter most and agreeing on a lighter version for mobile.

9. Launch requirements

Prepare a short list:

• Who will edit what after launch, and how often. This decides the CMS.
• Where form submissions go (email, CRM, Slack) and who replies.
• Integrations: payments, booking, newsletter, analytics.
• Domain, hosting access and the launch date, including any fixed deadline.

The full handoff checklist

How we run handoff at ROOKS

We build websites from designers' Figma files every day, for design studios, agencies and businesses. Our process follows the same steps whether the project takes two weeks or thirteen:

1. You share the design: layouts, responsive states, motion references and launch requirements.
2. We estimate: we define the technical scope, flag risks and estimate the work and timeline.
3. We review with your designer: we work through interactions and responsive behaviour together, preserving the design intent.
4. We build and test: demos as we go, then real devices and browsers.
5. Handover: to you or straight to your client, with a guide.

The review in step 3 is where this checklist pays off. The more of it is ready, the shorter that conversation and the more accurate the estimate.