From Figma to a Playable Ad: The Handoff That Does Not Need Redrawing

A playable comp usually arrives as one beautiful portrait artboard, and the rebuild takes twice as long as it should. Not because the design is wrong, but because a design file is a picture of one state at one size, and a playable is a live layout that has to hold together in two orientations, across a range of aspect ratios, inside a strict byte budget, on a webview.

Most of that friction can be removed with small changes. Agree this handoff spec once and reuse it.

Design two orientations, not one

Most networks accept or expect both orientations, and a landscape layout derived by someone else from a portrait comp is a guess about the designer's intent. Two artboards from one system (same components, same type scale, deliberately different arrangement) takes far less time than it sounds and removes the biggest cause of rebuilds.

The decision to make explicitly, per element, is what it does when the aspect changes: does it stay pinned to an edge, stay centred, scale with the canvas, or move to a different position entirely? Marking that on the file is more useful than any amount of spacing annotation, because it is the thing the builder otherwise has to invent.

Respect the safe area

The canvas is not the visible area. Notches, rounded corners and the home indicator take space at the edges, and the ad container adds its own furniture: usually a close button in a top corner, sometimes a countdown, occasionally a branding strip.

Put a safe-area frame on the artboard and keep anything that must be read or tapped inside it. The specific mistake to design out is a CTA or a critical piece of the mechanic in a top corner, where the container's close button will land on top of it. That is not something the builder can fix later without redesigning the layout.

Export at the size it renders, not the size it was drawn

The byte budget is the constraint designers most often have no visibility of. Under a 5 MB cap it is easy to get away with carelessness; under Meta's 2 MB requirement for the HTML itself, one oversized hero image consumes the whole budget.

• Export at roughly twice the on-canvas size. A 3000-pixel-wide hero for an element that occupies 180 points is between four and nine times more data than the ad can use.
• Two times, not three. The extra resolution is not visible in a creative that has a couple of seconds of attention, and it is a substantial share of a tight budget.
• WebP for anything photographic or painted; PNG only for crisp edges on flat colour with transparency. Google's published figure for WebP is 25 to 34 per cent smaller than comparable-quality JPEG.
• Transparency only where it is needed. An alpha channel on an image that sits on an opaque background is paid for and unused.
• Trim the bounds. Exported assets frequently carry a large transparent margin from the frame they were drawn in, which costs bytes and makes positioning ambiguous.

Effects that do not survive the trip

Some things in a design tool are not properties an exported asset can carry, and each one either has to be baked into the image or rebuilt in the editor. Knowing which in advance avoids the round trip.

Layer blurs, background blurs, blend modes and multi-layer shadow stacks are the usual culprits. A blur baked into a background plate is fine and often the right answer. A blur behind an element that moves has to be rebuilt at runtime, which is a real cost and worth deciding on deliberately rather than discovering.

Shadows on interactive elements deserve a specific rule: do not bake them into the sprite. A shadow baked into a button image cannot be animated separately, expands the asset's bounds, and makes the tap area ambiguous. Specify it as a property instead.

Text is an object, not a picture

Every string that could be localised, tested, or changed in a variant must ship as a live text object with a font, a size and a colour, never as part of an image. Text baked into a plate cannot be translated, cannot be A/B tested, and cannot be shortened when a German string runs 30 to 50 per cent longer than the English one and wraps out of its box.

Two things the handoff should state for every text element: what happens when the string gets longer, and what the minimum legible size is. Wrapping, shrinking and truncating are three different answers and the designer should choose which.

Fonts, including the licence

A playable embeds its fonts, because it cannot fetch them. That has two consequences designers are well placed to settle and builders are not.

The licence has to permit embedding in an ad creative. A font that is fine on the marketing site is not automatically fine inside a distributed HTML file, and this is worth checking before the design is approved rather than after.

And the file has to be subset to the glyphs in use, per locale if the creative is being localised. A Latin subset renders empty boxes for Cyrillic or CJK and it fails silently. Nothing errors, the text simply does not appear. Every weight is a separate file, so a comp using four weights is asking for four embedded fonts; two is usually enough.

Name things after what they are

The builder is reconstructing a scene graph from a layer tree. Names that describe role (cta-button, board-tile, reward-burst, headline) map onto objects. Names like Group 47 and Rectangle 12 copy do not, and the cost is a conversation per element.

Group by scene where the creative has more than one state. A file organised as hook, loop, end card is immediately buildable. A file organised as one flattened artboard requires the builder to infer which elements belong to which moment, which is guesswork about timing they were not present for.

Why this pays for itself

A playable is rarely built once. It becomes a variant set, then a localised set, then a re-engagement version, then a refresh when it fatigues. A file that hands off cleanly is re-used across all of them; one that does not is re-interpreted every time, and the interpretations drift until the variants are no longer comparable to each other.