Figma to Shopify: handing a design over so it gets built properly

The gap between "the design is finished" and "the store looks like the design" is a handover problem. A folder of flat screens gets approximated, because the developer has to invent everything the screens don't specify — and there's a lot of it.

Hand over components, not screens

Shopify themes are assembled from sections a merchant rearranges. A design delivered as twelve unique page layouts can't be built that way; it has to be reverse-engineered into components first, by someone who wasn't in the design conversations.

Deliver instead:

• A type scale with sizes, weights and line heights, named.
• Colour roles — background, surface, text, muted text, border, primary action, error, success — not just brand colours.
• A spacing scale, used consistently.
• Component specs: buttons in every state, form fields including errors, product cards, section headers, badges.
• Section patterns — the reusable bands a page is built from.
• Page compositions showing how sections stack, at two or three widths.

Specify the states nobody screenshots

This is where handovers most often fail, and it's the same list every time:

• Hover, focus, active and disabled on every interactive element. Focus especially — it's what keyboard users see, and removing it makes a store unusable (accessibility).
• Out of stock, and one variant out of stock.
• A product with one image and one with twelve.
• A very short and a very long product title.
• Empty cart, empty search, empty collection.
• Form validation errors.
• Loading states for anything asynchronous.
• A discount applied, and a discount rejected.

Unspecified states get invented, and invented states are where visual consistency dies.

Specify responsive behaviour, not just breakpoints

Two artboards at 375px and 1440px leave everything between them to interpretation. Say what happens:

• How does the grid reflow — four columns to two to one?
• Does the type scale change, or just the layout?
• What collapses, what stacks, what disappears entirely?
• Where do sticky elements apply, and how many are allowed at once?

Design mobile first and the answers are mostly already made.

Include a section map

The single most useful artefact, and the one almost never provided. For each section: what it's called, what the merchant can change, whether it repeats, and how many times.

Without this, the developer decides — and they'll either make everything configurable, producing an unusable theme editor, or nothing, producing a store where every change is a ticket. Both fail, and both are avoidable with the table above.

Assets, properly

• SVGs for icons and the logo, not PNGs.
• Images at 2× the largest rendered size, no larger. A 4000px hero is a performance problem shipped as an asset.
• Fonts with licences that permit web use. Check this before the design is approved, not after — it has killed more than one launch week.
• Named layers. A developer inspecting Rectangle 47 learns nothing.

Questions to answer in advance

Write the answers down and the build goes twice as fast:

1. What's the performance budget?
2. Which sections must work on every template, not just the homepage?
3. What happens to this design when the catalogue triples?
4. Who maintains the store afterwards, and what do they need to change?
5. Are there existing product images that don't meet the new photography standard, and who's redoing them?

Question five is the most common cause of a design that looks worse live than in Figma.

Stay involved through the build

The best handovers aren't documents, they're conversations. A short review at 30% and 70% of the build catches drift while it's cheap to correct. A design reviewed only at the end produces a list of fixes that the budget has already been spent on.

A design handover isn't a delivery, it's a specification. Everything you don't specify, someone else decides — usually at 6pm, under time pressure.