How to hand off a Figma design to a development partner

What a developer actually needs from the file

A developer reads a design as a set of decisions. Every decision you leave open becomes a question, a guess or a revision round. The file should answer four things without a call:

• What to build. Which pages and flows are in scope, and which frames are drafts or explorations.
• How it behaves. Hover, focus, loading, empty and error states, plus how layouts change across screen sizes.
• What goes in it. Final copy, real images, and rules for content that changes, like CMS items.
• How it will be checked. Which browsers and devices matter, and who signs off.

If the file answers these, the developer can estimate accurately and build with fewer interruptions.

Structure the file before you share it

Developers lose time hunting through pages full of old versions. Before sharing:

• Separate final work from exploration. Keep a clear page for approved screens. Move rejected options to an archive page or a separate file.
• Group screens by flow. Use sections for each page or flow (for example, Home, Pricing, Checkout). Sections matter later because you can mark them as ready for development.
• Name frames clearly. "Pricing / Desktop / 1440" is better than "Frame 284". Names show up in Dev Mode and in conversations.
• Name layers that matter. You do not need to name every rectangle, but name the components, key containers and anything that maps to real content.
• Save a named version. In version history you can save a version with a title and description. Do this at handoff so both sides can point to the exact state that was approved. Figma notes that titles longer than 25 characters get clipped, so keep them short.

Components and variables

Consistent components are what make a design buildable as a system instead of a pile of one-off pages.

• Use components for anything repeated. Buttons, cards, nav items, form fields, badges. If two buttons look the same, they should be the same component.
• Use variants for real differences. Primary and secondary buttons, sizes, icon or no icon. Avoid detached instances that look like a component but are not.
• Define tokens as variables or styles. Colors, spacing, radii and type sizes should come from variables or styles, not raw values typed into each layer. Dev Mode shows the variables and styles applied to a layer, which lets the developer map them to CSS variables or a theme file.
• Use modes if you have themes. Figma variable modes let one variable hold different values per context, such as light and dark themes. If the site has a dark mode or multiple brands, set this up before handoff.
• Flag anything custom. If one section breaks the system on purpose, say so in an annotation. Otherwise the developer may "fix" it.

States and interactions

Most missing work hides here. Static screens show the happy path. A real site needs the rest.

For each interactive element, include or describe:

• Default, hover, focus and active for buttons, links and form fields. Focus states matter for keyboard users; WCAG 2.2 requires a visible focus indicator.
• Disabled and loading for buttons that submit data.
• Error and success for forms, including the error message copy.
• Empty states for lists, search results, carts and dashboards.
• Open and closed for menus, accordions, modals and tabs.

For motion, a short prototype or a note with duration and easing is enough. If an animation is a must have, say so. If it is a nice to have, say that too, because it changes the estimate.

Annotations are the cleanest way to document this. In Dev Mode, annotations can include plain text and component properties, and Figma offers categories like Development, Interaction, Accessibility and Content. Adding annotations requires a Full seat and edit access; viewing them works with a Full or Dev seat.

Responsive behavior

"Make it responsive" is not a spec. Give the developer something concrete:

• Design at least two widths, usually desktop and mobile, for every unique layout. Add tablet for complex layouts like data tables, multi column grids or navigation.
• State your breakpoints. List the widths where the layout changes.
• Use auto layout. Frames built with auto layout communicate spacing, alignment and how elements stack. Fixed positioned layers force the developer to guess.
• Describe what happens between breakpoints. Does the grid go from three columns to two? Does the image crop or scale? Does the nav collapse into a menu?
• Set max widths. Say how wide content gets on large screens and what happens to backgrounds beyond that.

Content and assets

Placeholder content is the most common reason a "finished" build needs a second pass.

• Use final copy where possible. Real headlines are longer or shorter than lorem ipsum, and that changes layouts.
• Test long and short content. Show a card with a two word title and one with a two line title. Show a name with 30 characters.
• Define CMS fields. If the site uses Webflow, Framer or a headless CMS, list each collection and its fields: type, required or optional, character limits.
• Prepare assets. Mark icons and illustrations as exportable. Dev Mode can export assets as PNG, JPG, SVG and PDF, and it detects icons automatically, but only if they are built as clean vector layers.
• Include licenses and fonts. Confirm font licenses cover web use, and share font files or the font service account. Same for stock images.
• Check contrast. WCAG 2.2 asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Catching this in design is cheaper than in code.

Access, Dev Mode and statuses

Access problems can stall a project for days. Sort them out before kickoff.

• Share the file with the right level. Figma lets you share with view or edit access, by invite or by link. On paid plans, there is a setting to allow viewers to copy, share and export. Check it so the developer can export assets.
• Check Dev Mode availability. Dev Mode is available on Professional, Education, Organization, Government and Enterprise plans, and the developer needs the right seat (Full or Dev) for features like statuses and notifications. Decide early who provides that seat: the agency or the dev partner.
• Mark sections as ready for dev. Select a section, frame or component and click "Mark as ready for dev". Developers with access get a clear signal of what is approved.
• Watch the "Changed" status. If a design marked ready for dev is edited afterwards, Figma sets a "Changed" status automatically. This helps, but it does not replace telling the developer what changed and why.
• Share every other account. Webflow or Framer workspace, CMS, hosting, domain DNS, analytics, forms, email tools and any API keys the build needs. Use a password manager or the platform's own invite system, not plain email.

QA and change requests

Agree on how the work will be checked before it starts.

• List target browsers and devices. For example, the latest two versions of Chrome, Safari, Firefox and Edge, plus iOS Safari and Android Chrome.
• Define "done" per page. Matches the design at the agreed breakpoints, all states work, content is final, forms submit, pages pass a basic accessibility and performance check.
• Use one channel for feedback. Comments in Figma for design questions, one tracker or document for build issues. Scattered feedback in chat gets lost.
• Separate bugs from changes. A bug is the build not matching the approved design. A change is a new decision. Changes affect scope and timeline, so label them.
• Name one approver. One person on the agency side decides when feedback conflicts.

Checklist

Use this before every handoff:

• Final screens are on their own page, explorations archived
• Screens grouped in sections by page or flow
• Frames and key layers have clear names
• A named version saved for the approved state
• Repeated elements are components with variants
• Colors, type and spacing use variables or styles
• Hover, focus, active, disabled and loading states designed
• Form error and success states, with copy
• Empty states for lists and dynamic content
• Desktop and mobile designs for every unique layout
• Breakpoints and max widths written down
• Auto layout used for main containers
• Final copy in place, long and short content tested
• CMS collections and fields defined
• Icons and images exportable, fonts licensed for web
• Text contrast checked against WCAG
• File shared, export allowed, Dev Mode seat sorted
• Approved sections marked as ready for dev
• Access to platform, hosting, domain and tools shared securely
• Target browsers, definition of done and approver agreed

Sources

The Figma facts in this guide come from the Figma Help Center. Accessibility thresholds come from the W3C.

• Guide to Dev Mode
• Dev Mode statuses and notifications
• Add measurements and annotate designs
• Share files and prototypes
• Guide to variables in Figma
• View a file's version history
• WCAG 2.2: Understanding Contrast (Minimum)
• WCAG 2.2: Understanding Focus Visible