Figma Handoff Checklist for Freelance Designers (India)

You send the final Figma link, the client says "great", and three days later the developer messages you at 11 pm asking which of the five grey buttons is the real one. Most freelance designers treat the Figma handoff as a link to paste, so the unpaid support starts the moment the file leaves their hands. A Figma handoff checklist for freelance designers fixes that by making the file itself answer the questions before anyone asks.

This post walks through the checklist in the order a developer reads a file: structure, components, naming, variables, Dev Mode, exports and a one-page handoff doc. It also covers where the handoff ends and a paid change request begins. The contract clauses are already covered in the guide to contracts for freelance designers, so this post stays on the file.

A handoff is the file, a short doc and a walkthrough, and it should be priced

A proper handoff has three parts: a clean Figma file, a one-page doc that covers what the file cannot show, and a short walkthrough call or recorded video. Agree this scope before the work starts and put a price on it, whether as a line in the quote or part of the final milestone. Free-form "I'll help the dev if they get stuck" is how a fixed fee turns into weeks of unpaid support.

The guide to freelance UI/UX design in India makes the same point about pricing handovers upfront. Treat the checklist below as the definition of "done" for that line item. If the client wants more than this, that is a change request, and the scope creep guide has the scripts for saying so.

Structure the file with pages, a cover and a Ready for dev flag

Put one job on each page: a cover, the final screens, the component library and an archive for old explorations. Add a cover frame with the project name, version and date so nobody opens a stale copy. Move anything you would not want built into the archive page, because developers build what they find.

Group the final screens into sections by flow, such as onboarding, checkout and settings. When a section is final, mark it with Figma's "Ready for dev" status. Figma's Dev Mode guide says this status is available on every plan that includes Dev Mode, and it also describes a Ready for dev view, so developers can look at only the sections you have marked. That cuts down the "is this final?" messages.

Build components, variants and auto layout the way a developer thinks

Developers build components, not screens, so your file should show the same reusable pieces. Turn repeated elements into components, group their states into variants, and use auto layout so spacing and resizing behave like real layout. A button that stretches correctly in Figma tells the developer how it should behave in code.

Auto layout works only on frames and flows vertical, horizontal or as a grid (Shift A), as Figma's auto layout page explains. Check what "Suggest auto layout" produces, because it is not always right. An instance cannot have its auto layout removed. Detach it or edit the main component instead.

For variants, every variant in a set needs the same properties and a unique combination of values (see the variants help page). The top-left variant is the default, so put your most common state there. Publishing a library needs a paid plan, which is worth knowing before you promise a shared library to a client.

Name layers and set variables so nothing is guesswork

Name layers for what they do, not what they look like: "button/primary/default" beats "Rectangle 214". Use the same names in the file, the exports and your handoff doc. Frame names should match the screen names the client uses in their own tickets.

Variables let you store colours, spacing and text values once and reuse them. Variables are available on any plan, but extra modes, such as a light and dark theme, need an Education or paid plan (details in the variables help page). Variables can be scoped by type (number, colour and string), and a variable can alias only another variable of the same type. One collection holds up to 5,000 variables, which is far more than a freelance project needs.

Check who needs which seat before you promise Dev Mode

Dev Mode is not on Figma's free Starter plan. Per Figma's Dev Mode guide, it is available on the Professional, Education, Organization, Government and Enterprise plans, only in Figma Design files, and it needs a Full or Dev seat. So a developer who opens your link on a free account will not see it.

Dev Mode is where a developer reads measurements (Shift M) and your annotations, and Figma says annotations stay linked to their layers. What each seat includes depends on your plan, so check Figma's pricing page before you quote. This post gives no seat prices because they change. Ask the client which Figma plan their developers use, and if the answer is "free", deliver exports and a spec doc instead.

Set up exports so assets arrive with predictable names

Mark the assets developers need, such as icons, logos and illustrations, as exportable and name them with slashes. Slash-separated layer names create nested folders on export (see Figma's export help page), so "button/pill/default" exports as a button folder, then a pill folder, then a file called "default". Shift+Ctrl/Cmd+E opens the bulk export modal, and slices control padding.

Figma exports PDFs at 1x only, and a suffix is added to the exported file name. For other formats and scales, open the export panel in your own file and check the options available there before you tell a client what you will deliver. Decide per project whether you send exports only or the Figma source file as well. That choice is a pricing and ownership question, which the guide to IP ownership for freelancers covers.

Write a one-page handoff doc for what the file cannot show

The doc covers everything a static frame hides: interaction states, edge cases, responsive behaviour and open questions. Keep it to one page and link it from the cover frame of the file. If it grows past a page, the file is probably missing annotations.

Cover the empty, loading and error states for each screen, and say what happens with very long text, such as a 40-character name in a card. Add the breakpoints you designed for and what collapses at each one. Finish with a short list of open questions the client still owes you, each with a name and a date, so a missing answer cannot turn into a redesign later. Pair this with the dev-facing annotations in Dev Mode rather than repeating them.

Draw the handoff boundary in writing so change requests are paid

The handoff ends when the developer has the file, the doc and the walkthrough. Anything after that, such as new screens, redesigned states or "can you just tweak this for the new feature", is a change request with its own price. Say so in the quote and repeat it when you deliver.

A short post-handoff window for clarification questions is fair, and many designers cap it at a set number of days or hours. State the cap in your proposal, as the guide to the freelance proposal shows. For the bigger picture of running your design practice as a business, see the best tools for freelancers in India.

Rinto lets you send a contract with your scope in it, which on Pro and Agency plans the client signs in the browser with no DocuSign needed. You can also track time per task, so handoff support shows up as hours you can see rather than guess. This post is general information, not legal advice.

Frequently Asked Questions