Handoff friction is rarely about the design. It is about a file where components are called Group 47 and half the spacing is eyeballed. Five naming and structure habits that make a design file buildable.
A design file has two audiences: the person approving it and the person building it. Most files are optimised entirely for the first.
1. Name components the way the code will
Button / Primary / Large / Disabled translates directly into props. CTA blue big greyed out translates into a conversation. Match the naming convention the front end already uses — if the codebase has a Card component with a variant prop, your Figma component should be Card with a variant property, not Product Tile v3 FINAL.
2. Use variants and properties, never duplicates
Eight copies of a button with small differences is eight things to keep in sync and eight opportunities for the built version to diverge. One component with a variant set is a single source of truth, and it forces you to decide what actually varies.
3. Tokenise spacing, colour and type — and use only tokens
If a developer measures a gap and finds 14px in one place and 16px in another, they have to guess whether that was intentional. Define a spacing scale, bind it as variables, and let auto layout apply it. The same for colour and typography. A single hard-coded hex in a file undermines the whole system, because now every value is suspect.
4. Design the states nobody asks for
Empty, loading, error, one item, forty items, a name that is sixty characters long, a price that is four digits, a translated string that is twice as long. These are where builds stall, and where the developer's improvised answer becomes the product's behaviour. Designing them takes an hour; discovering them in QA takes a week.
5. Annotate intent, not measurements
Developers can read the numbers from the file. What they cannot read is why. Note the things the geometry does not say: what happens on hover and focus, what the tab order should be, which element gets the accessible name, what happens on slow connections, and what should not shrink when the screen does.
The test
Hand the file to someone who was not in the project and ask them to describe how one component behaves. If they have to ask you, the file is not finished.
Looking for more? Browse all resources.