Figma Components vs. Coded Email Modules: Where Should the System Live?

Short answer: the system should live in code, and Figma should mirror it. The coded email modules are the source of truth for what actually ships. The Figma components are the place where you think, explore and communicate. When the two disagree, the code wins, and the Figma file gets fixed.

I'm a marketing designer, so I did not always believe this. I've handed developers beautifully organized Figma libraries, and I've handed them rough specs for modules that already existed in production. The second kind of handoff went better. Here is why, and how to set it up so your designers and developers stop fighting over which file is right.

Why email is different from product UI

In a web app, a Figma component and its coded twin can be close to identical. Email breaks that. The thing your subscriber sees depends on the email client, the dark mode behavior, image blocking, and how the layout collapses on a narrow screen. A Figma frame can't show you any of that.

So a Figma component in email is always a drawing of an intention. The coded module is the version that has survived real rendering. If you treat the drawing as the system, you will keep designing things that look right in Figma and then need to be quietly altered during build. Those alterations rarely make it back into the file, and that is where drift starts.

What the coded module does better

• It encodes the constraints. Fallback fonts, button padding that survives clients, and image behavior are decisions that already live in the module. A designer can't accidentally break them.
• It is what the campaign team actually uses. People assembling an email pull modules, not Figma frames. The system they touch every week should be the real one.
• It can be tested. You can check a module across clients once and trust it everywhere it appears. A Figma component can't be tested for rendering.
• It makes consistency cheap. If the header is one module, fixing it is one change, not a hunt through every past layout.

This is the thinking behind the ixigo Mailer Design System. Over the course of that project, email click-through rate went from 4.2% to 18%. A system wasn't the only factor in that number, since content and offers matter too, but having reliable, reusable modules meant the team could spend its energy on what the email said instead of rebuilding how it was put together.

What Figma components are still for

None of this means skipping Figma. It does a few jobs that code can't do well.

• Exploration. Trying five hero treatments is faster on a canvas than in HTML.
• Review. Stakeholders can comment on a Figma frame. They can't comment on a template in an email platform.
• Documentation. Usage notes, do and don't examples, and spacing rules are easier to read next to a visual.
• Composition. Designers can mock up a full email from the components before anything is built, which keeps ideas cheap to change.

The rule I follow: Figma is where a module is proposed and explained. Code is where it is defined.

The handoff contract that keeps them in sync

Both versions of the system only stay honest if there's an explicit agreement between design and development. Mine is short.

1. One name, two places. Every module has the same name in Figma and in code, so nobody has to translate.
2. One-to-one mapping. A Figma component should correspond to exactly one coded module. If a module has variants, mirror the variants with the same names.
3. Constraints written down, not implied. Character limits, image ratios and what happens on mobile go in the component description.
4. Code changes flow back. If a developer adjusts a module during build, the Figma component is updated the same day. This is the step most teams skip.
5. A named owner for drift. Someone, usually the designer, checks the two against each other on a regular schedule.

Here is what naming looks like in practice. This is an illustration of the convention, not a copy of any specific file:

The point is that a campaign manager, a designer and a developer can all say the same module name and mean the same thing.

When Figma-first is fine

There are cases where I'd let Figma lead. If you have no email system at all, drawing the modules first is a sensible way to agree on a visual direction. If a team sends only a few emails a year, a coded module library may be more than they need. And early on, designing in Figma helps you find which modules are worth building.

But treat that as a starting stage. Once emails are going out regularly, move the definition into code and let Figma follow.

Where to start this week

Open your last five sent emails and list the repeated blocks: header, hero, product card, footer, button. Check whether each has a coded module and a matching Figma component with the same name. Wherever one is missing or different, decide which is correct, usually the coded one, and fix the other. That small audit shows you where your system actually lives today, and where it is only pretending to.