Figma to Email: The Developer Handoff Checklist

A Figma file is a picture of an email. The developer's job is to reconstruct it in a medium with different rules, and everything you did not specify becomes a decision they have to make for you.

This is what to provide, and what goes wrong when you do not.

First, be clear about what Figma does not produce

Figma does not export production email HTML. There are plugins that generate markup, and for very simple layouts some are usable, but email HTML has to satisfy Outlook's rendering engine, inconsistent CSS support and a range of clients that ignore modern layout entirely. Generated output generally needs rebuilding.

Plan for a build step. The design's job is to make that build unambiguous.

Provide both frames, and the behaviour between them

Two frames — 600px desktop and 375px mobile — are the minimum. But the frames show two states, not the transition, and the transition is where the questions are.

Specify explicitly:

How each multi-column row collapses. Two columns to a stack is obvious. A three-across product row could stack, or become two-plus-one, or drop an item. Say which.
Stacking order for image-and-text pairs. Source order puts the image first. If a right-aligned image should appear below its text on mobile, that is a deliberate reversal and it needs stating.
What is hidden on mobile, if anything.
How the type scale changes, if it does.

An alternating image-left/image-right layout is the classic trap: on mobile it alternates too, which often reads as inconsistent rather than rhythmic.

Export images properly

2× the display width. No reliable responsive image support means one asset sized generously.
Correct format. JPG for photography, PNG for anything with transparency or flat colour, and be aware that WebP support is good but not universal — provide a fallback if your audience includes older Outlook.
Named for their content, since the filename often survives into the build.
Compressed. Under about 200KB each.

Do not export text as an image to preserve a font. It breaks with images blocked, it is invisible to screen readers, and it cannot reflow.

Specify the type stack including the fallback

Give the developer the actual stack, in order, not just the name of the font you designed in:

font-family: 'Inter', Helvetica, Arial, sans-serif;

And be explicit about whether the webfont is required or nice-to-have. If it is nice-to-have, the fallback appearance should have been designed and approved, because a serif fallback for a sans headline changes line breaks and can change the layout height.

Include size, weight, line height and letter spacing for each text role. Line height especially — it is the value most often omitted and it changes the vertical rhythm of the whole email.

Give exact spacing

Developers cannot infer your spacing scale from a picture; they measure, and measurements from a screenshot drift. Provide the numbers:

Padding inside each band, top and bottom.
Gaps between elements within a band.
Side padding, desktop and mobile.
Button padding, and minimum height.

If you built with auto layout on a spacing scale, this is already consistent and you can hand over the scale itself.

Alt text is your job, not theirs

Every image needs alt text written by whoever knows what the image is meant to communicate. A developer will otherwise write the filename, or nothing.

Write it to carry the message when the image does not load: "Spring collection — three new colourways" rather than "hero image". For purely decorative images, specify empty alt so screen readers skip them rather than announcing a filename.

Provide every link

Including the ones that feel obvious. Header logo, every button, every product card, every footer link, the social icons, the view-in-browser link, the unsubscribe.

A missing link destination is the most common reason a build comes back for a second pass.

Specify the parts a frame cannot show

Preheader text. 40–90 characters, extending the subject line. If you do not supply it, the client will pull whatever text comes first — often "View in browser".
Subject line, if you own it.
Dark mode intent. Some clients invert palettes. Decide whether your email should adapt, and if a logo needs a light-on-dark variant, provide it. The dark mode guide covers what is actually controllable.
Background colour outside the content column.
Dynamic or personalised content, with what happens when the value is missing. A "Hi {first_name}" with no fallback produces "Hi ,".

What to check when it comes back

Test the build rather than the picture:

Desktop Outlook, Gmail web, Gmail mobile app, iOS Mail, Apple Mail. These five cover most failure modes.
Images blocked.
Dark mode in at least one client.
Every link, clicked.
The rendered width — a horizontal scrollbar means something exceeded the container.
Screen reader order, at least once for a template you will reuse.

Agree who owns what

Most handoff friction is not missing information, it is unclear ownership. Three things routinely fall in the gap:

Copy changes after handoff. If the copy is still moving, say so and agree a freeze point. A build reworked three times for copy edits costs more than the copy review would have.

Rendering compromises. Some designs cannot be built identically across clients — a rounded button in older Outlook, a gradient, an overlapping element. Decide in advance who chooses the compromise. A developer making that call silently is how a design ships subtly wrong; a developer flagging it to nobody in particular is how a build stalls.

The test list. Agree which clients matter before the build, not after. "It looks broken in Outlook 2016" is a very different conversation depending on whether Outlook 2016 was on the list.

The review loop

Review the rendered email, not a screenshot of it, and review it in the clients you agreed on. A screenshot hides exactly the things that go wrong: link behaviour, reflow at intermediate widths, dark mode, and what happens with images blocked.

When sending feedback, separate the two categories explicitly. Build defects are places the render does not match the specification. Design changes are places the specification was wrong. Mixing them in one list is how a second round becomes a third, because the developer cannot tell which items are their responsibility.

A handoff package

What to attach:

Figma link with view access, frames named
Exported images at 2×, named, compressed
Alt text for each image
Type stack with sizes, weights, line heights
Colour hex values, semantically labelled
Spacing scale and band padding
All link destinations
Preheader text
Collapse behaviour for every multi-column row
Dark mode intent and any light-on-dark assets

Handing off a template versus a campaign

These are different deliverables and conflating them causes most of the rework.

A template is built once and reused. It needs to be specified for variability: what happens when the product name runs to three lines, when a section is removed, when a row has two items instead of four, when a personalisation value is missing. The handoff should include those cases explicitly, because the developer is building something that has to survive content it has not seen.

A campaign is one send with known content. It needs the content and the assets, and nothing about variability, because there is none.

The efficient pattern is to hand off templates rarely and carefully, with the edge cases documented, and then hand off campaigns as content briefs against an existing template. Treating every campaign as a fresh build is what makes email production expensive, and it is usually a handoff-process problem rather than a design or development one.

Where the templates help

Every design in this library is built with named bands, auto layout and a mobile frame, which is most of the specification work already done. The transactional collection is a useful place to see structured layouts that translate cleanly, and the design system guide covers the naming and component structure that makes handoff routine.

Figma to Email: How to Hand Off an Email Design a Developer Can Actually Build