On this page · 5 min read
Your designer approves the email in Figma. Then someone rebuilds it in the ESP.
Think about how strange that is. The layout exists. The copy is approved. Every design decision has already been made. But before anything can send, a second person recreates the whole thing inside the sending platform, resolves the places where their version doesn’t quite match, and runs it back through review. If that loop takes three hours per email and you send 15 campaigns a month, you’re spending 45 hours a month producing something that already existed.
We do this in email all the time, and we’ve somehow accepted it as normal. It’s worth asking why.
Why the rebuild happens
It happens because we’ve asked the ESP to be two things at once: the delivery platform and the design-production environment.
ESPs are built for delivery. Sending, segmentation, personalization, automation, reporting: that’s the job, and the good ones do it well. Design production is a different job, and it already has a home. Most brands with a design team have an email design system in Figma, maintained by a designer.
Put a template library inside the ESP anyway, and now there are two copies of the same design system: the one the designer maintains in Figma, and the one somebody else maintains inside the ESP. Every brand refresh gets made twice. Every new module gets built twice. The two copies drift, the drift gets caught in QA, and QA sends it back around.
The rebuild isn’t really the problem. Duplicate ownership of the design system is the problem. The rebuild is just where you feel it.
The headless idea
Headless email design borrows a principle from headless web architecture: separate the system that creates your emails from the platform that sends them.
One copy of the design system, living where your designers already work. Emails get designed and assembled there, export as production-ready HTML, and the ESP goes back to doing the thing it’s actually good at: delivery.
The visual system is also no longer tied to the ESP. Personalization syntax and platform-specific features still need adapting if you change platforms, but the components, layouts, and brand system stay intact, making it easy to migrate to a new tool or update your branding in one place.
Three architectures for an email program
Most teams run one of three models. None of them is wrong. They fit different situations.
1. The ESP editor
Everything happens in the ESP’s drag-and-drop editor. Fastest to start, zero setup, and for a solo marketer sending a couple of campaigns a month, it’s the right call: one person, one copy of the system, nothing to duplicate.
It strains when brand standards matter or more people enter the workflow. Designers rarely work in ESP editors, so brand consistency drifts one campaign at a time.
2. The ESP component library
Reusable blocks built inside the ESP: saved sections, synced modules, locked templates. A real step up. Marketers assemble instead of designing, and consistency improves.
But the library lives where your designers don’t. This is the two-copies problem in its most common form: the designer updates the system in Figma, then someone has to re-implement the same update inside the ESP. And because the modules are built in the ESP’s own format, they don’t come with you if you leave.
3. The independent design system
The headless model. One design system in Figma, maintained by the design team. Marketers assemble campaigns from its components and export production-ready HTML into whichever ESP you run. (This is the workflow our Figma plugin exists to enable.)
What changes in practice
Figma becomes the production environment. The ESP remains the sending environment.
The component library covers the patterns you actually use: headers, heroes, product grids, CTAs, footers, promotional modules, and so on. Responsive behavior and dark-mode treatments live inside the components, so you’re not solving the same implementation problems again with every campaign. A marketer composes the campaign from those pieces, review happens in Figma where stakeholders already comment, and the export lands in the ESP ready to send.
One team we work with went from a week-long design-to-send cycle to same-day sends for standard campaigns. Previously, each approved Figma design was handed to another person to rebuild in the ESP, then sent back through QA because the rebuilt version didn’t always match the design. Once the components themselves became the production system, that handoff and the QA around it disappeared.
Who should (and shouldn’t) do this
Three questions tell you most of what you need to know. How much do you send? How many people touch each campaign? How often are you rebuilding work that’s already been approved?
If you’re a solo marketer sending two campaigns a month, stay in your ESP editor. If you have no design resources at all, start with well-built templates; the architecture question comes later. But if several people touch every send and your designer keeps fixing the same drift, you’re already paying for two design systems. You just haven’t itemized the bill.
Measure your rebuild tax
Take your last 10 campaigns. Count the hours spent turning an already-approved design into something the ESP could send: the rebuilding, the reconciling, the extra QA round. If that number makes you uncomfortable, that’s the part of the workflow to fix.
Three ways to start
Start with the template library
The Email Love Figma Plugin ships with 100+ pre-built email components and a library of production-ready templates you can open in Figma and make your own. Swap in your brand, export clean HTML, send through your ESP. Plans start free.
Prefer a visual editing surface on the same system? Try our email template builder that syncs with Figma.
Build a custom design system with AI
Connect the Email Love MCP and the Email Love Skills to Claude, Cursor, or ChatGPT. Your agent researches what top brands in your space actually send, then builds a tailored design system from your brand guidelines using the Figma MCP — components, layouts, dark mode, all of it.
Set up the Email Love skills →
We build it for you
Our Enterprise plan includes a custom design system of up to 100 branded components, built and tested across ESPs and email clients. We train your team and stay with you through launch and beyond, with dedicated support for 12 months.
Much love,
Andy
Andy has spent two decades building email programs for brands and agencies, and now co-runs Email Love: the inspiration gallery of 473,000+ emails and the Figma plugin that lets teams design, build, and export production-ready email without leaving their design file. He writes about email design systems, production workflow, and where the industry is heading.
Customer.io is an AI-powered customer engagement platform designed for organizations to create personalized customer journeys that engage, convert, and scale. Orchestrate messages across all channels, including email, in-app, SMS, push, and webhooks. Over 8,000+ companies, including Notion, LESMILLS+, and Angi, rely on Customer.io to power their messaging needs.




