Introduction

Turning a Figma design into an HTML email is not the same as turning a Figma design into a normal website.

In a website project, I can often use modern CSS layout techniques, flexible positioning and browser capabilities that are consistent across modern browsers. Email development is different. The final HTML may be rendered by Outlook, Gmail, Apple Mail or a mobile email application, each with its own limitations.

That means my job is not to copy every Figma property literally. My job is to understand what the designer intended and translate that intent into email-safe HTML and CSS.

My approach: I treat Figma as the visual source of truth, but I treat the email client matrix as the technical source of truth.

After more than 11 years of email development, this designer-to-code translation has become one of the most important parts of my workflow. The better I understand the design before coding, the fewer surprises I have during rendering and QA.

The Designer-to-Code Mindset

I do not start by immediately writing HTML after opening a Figma file.

First, I break the design into questions: 

What is the visual hierarchy?
        ↓
What are the reusable components?
        ↓
Which parts are live HTML text?
        ↓
Which parts are images?
        ↓
What happens on mobile?
        ↓
What needs Outlook fallback?
        ↓
What needs dark-mode support?
        ↓
What accessibility requirements apply?
        ↓
How will it be tested?

This prevents me from treating the Figma file as a screenshot that simply needs to be reproduced.

Important: A good email developer does not just reproduce pixels. The developer translates the design into a system that can survive different email clients.

Step 1: Review the Figma File Before Coding

My first step is always to inspect the complete Figma file.

I check:

  • Desktop frame width
  • Mobile frame width
  • Content width
  • Section spacing
  • Typography
  • Colors
  • Buttons
  • Images
  • Icons
  • Footer
  • Repeated components

I also look for hidden layers, unused design elements, inconsistent spacing and assets that may not be intended for production.

This initial inspection often reveals development questions before I write a single line of code.

Step 2: Identify the Design System

Before building individual sections, I identify the visual system behind the Figma design.

I usually extract:

Colors

Primary, secondary, background, text and CTA colors.

Typography

Font family, size, weight, line-height and hierarchy.

Spacing

Section padding, gaps, margins and component spacing.

Components

Buttons, cards, headers, content blocks and footers.

If the same button appears five times in the Figma file, I treat it as one reusable email component rather than five separate pieces of code.

Step 3: Prepare the Assets

Asset preparation is one of the easiest places to save time later.

I identify every production asset before starting the HTML:

  • Hero images
  • Product images
  • Logos
  • Icons
  • Social icons
  • Decorative graphics
  • Background images

I check dimensions, file type, transparency and whether the asset should remain an image or should instead be recreated using HTML text and CSS.

My rule: If the content is important text, I first ask whether it can be live HTML instead of embedding it inside an image.

Step 4: Translate the Figma Layout Into Email Components

Figma may show a visually complex composition, but I need to identify the underlying email structure.

For example, a design might look like: 

Hero
 ├── Image
 ├── Headline
 ├── Supporting copy
 └── CTA

Content
 ├── Image
 ├── Text
 └── CTA

Product grid
 ├── Product
 ├── Product
 └── Product

Footer

This component breakdown gives me a much clearer development plan.

I then decide which components require table-based layout, which can use responsive CSS and which need client-specific fallbacks.

Step 5: Build the Email Structure

Once I understand the design, I start building the email skeleton.

A typical structure looks conceptually like this: 

<body>

  <!-- Preheader -->

  <!-- Outer wrapper -->

    <!-- Main container -->

      <!-- Header -->

      <!-- Hero -->

      <!-- Content module -->

      <!-- Product module -->

      <!-- CTA -->

      <!-- Footer -->

    <!-- End main container -->

</body>

For production email, I frequently use tables for reliable structure and predictable alignment across clients. 

<table
  role="presentation"
  width="100%"
  cellpadding="0"
  cellspacing="0"
  border="0"
>

  <tr>
    <td align="center">

      <!-- Component content -->

    </td>
  </tr>

</table>

The exact markup depends on the component and supported clients, but the principle is to build a reliable structure first and style it second.

Step 6: Translate Typography Carefully

Typography is one of the places where a Figma design can create unrealistic expectations for email.

The exact font shown in Figma may not be available in every email client. I therefore identify the intended font and establish sensible fallbacks. 

Figma font
    ↓
Email-supported option
    ↓
Fallback font
    ↓
Final rendered check

I also translate:

  • Font size
  • Font weight
  • Line height
  • Letter spacing
  • Text alignment
  • Text color

I do not rely only on the numeric values from Figma. I check the rendered email because fallback fonts can change line wrapping and therefore change the height of the component.

Step 7: Handle Images Correctly

Figma designs often contain large hero graphics and carefully positioned visual assets. In email, I need to decide how each image should behave when the viewport changes.

I check:

  • Maximum display width
  • Actual image dimensions
  • Mobile scaling
  • Alt text
  • Image loading behavior
  • Transparent backgrounds
  • Dark-mode appearance

For example: 

<img
  src="https://example.com/images/hero.jpg"
  width="600"
  alt="September gift card offer"
  style="display:block;width:100%;max-width:600px;"
>

I also check whether the design relies on text embedded inside the image. If the message is important, I prefer live HTML text where the design allows it.

Step 8: Build Email-Safe Buttons

A Figma button may have rounded corners, gradients, shadows, specific padding and typography. Not every visual property translates equally well across email clients.

I first identify the important requirements:

  • Button text
  • Destination
  • Background color
  • Text color
  • Padding
  • Border radius
  • Minimum comfortable click area
  • Outlook fallback

A simple HTML version might look like: 

<a
  href="https://example.com/shop"
  style="display:inline-block;
         padding:14px 24px;
         background:#111111;
         color:#ffffff;
         text-decoration:none;
         font-weight:bold;"
>
  Shop now
</a>

If the campaign requires stronger Outlook compatibility, I add the appropriate client-specific fallback rather than compromising the entire component architecture.

Step 9: Plan Mobile Behavior Before Coding It

One of the biggest mistakes is treating the desktop Figma frame as the complete specification.

I look for the mobile design or, if it is not provided, discuss the expected mobile behavior before development.

For a two-column section: 

Desktop:

[ IMAGE ] [ TEXT ]

Mobile:

[ IMAGE ]
[ TEXT ]

I also check:

  • Mobile padding
  • Headline wrapping
  • Button width
  • Image scaling
  • Column stacking
  • Footer readability

My approach: I define the mobile behavior at the component level instead of trying to fix the complete email after desktop development is finished.

Step 10: Account for Outlook During Development

Figma does not show Outlook limitations. That is one of the biggest differences between design and email development.

Depending on the campaign, I look for components that may require Outlook-specific treatment:

  • Background images
  • Buttons
  • Fixed dimensions
  • Vertical alignment
  • Two-column layouts
  • Spacing
  • Rounded or advanced visual effects

When required, I use appropriate Outlook/VML fallbacks. 

<!--[if mso]>
  Outlook-specific fallback
<![endif]-->

My rule: I don't wait until the final QA stage to discover that a visually important Figma feature needs an Outlook fallback.

Step 11: Plan Dark Mode From the Beginning

If the campaign supports dark mode, I identify dark-mode requirements while converting the Figma design rather than adding them at the end.

I review:

  • Background colors
  • Text colors
  • CTA colors
  • Logo treatment
  • Transparent graphics
  • Footer colors
  • Contrast

A logo that looks perfect on a white Figma frame may become invisible when the email background changes.

Therefore, I think about light mode and dark mode as two versions of the same component.

Step 12: Build Accessibility Into the Translation

A Figma file can communicate visual hierarchy, but the HTML needs to communicate semantic and functional information too.

I check:

  • Image alternative text
  • Decorative images
  • Meaningful links
  • Heading hierarchy
  • Color contrast
  • Reading order
  • Table semantics
  • Mobile readability

I also use screen-reader testing, including NVDA, as part of my accessibility QA workflow.

Important: The Figma design is not the complete accessibility specification. The developer must translate the visual design into an experience that remains understandable when the visual presentation changes.

Step 13: Separate Content From Structure

During the Figma-to-code process, I identify which parts are fixed components and which parts are campaign content. 

Reusable component
        ↓
Headline
        ↓
Supporting copy
        ↓
Image
        ↓
CTA
        ↓
URL

The same component might be reused for several campaigns with different content.

Keeping that distinction clear makes the final HTML easier to maintain and makes future campaign updates faster.

Step 14: Compare the Figma Design With the Rendered Email

Once the first version is coded, I compare the actual rendered email against the approved Figma design.

I check:

  • Overall width
  • Section spacing
  • Typography
  • Image cropping
  • Button size
  • Alignment
  • Colors
  • Footer

But I do not blindly force every pixel to match if doing so would create a compatibility problem.

My principle: Match the design intent first, then optimize the implementation for reliable email rendering.

Step 15: Test With Litmus and BrowserStack

Once the email is visually close to the approved design, I move into broader rendering and device testing.

Litmus

I use email rendering previews to compare the campaign across supported email clients and identify client-specific differences.

BrowserStack

I use broader browser and device testing where appropriate to validate responsive behavior and the overall experience.

The exact testing matrix depends on the campaign's audience and delivery requirements. I do not assume that one screenshot represents every recipient environment. 

Figma
  ↓
HTML build
  ↓
Browser preview
  ↓
Email-client rendering
  ↓
Mobile/device testing
  ↓
Accessibility
  ↓
Dark mode
  ↓
Final QA

Step 16: Production Handoff

The Figma-to-HTML workflow does not end when the developer says the HTML is finished.

I want the production handoff to include:

  • Final approved Figma design
  • Final HTML
  • Production image URLs
  • Final copy
  • Validated links
  • Tracking requirements
  • Testing results
  • Known client limitations
  • Any campaign-specific instructions

This becomes particularly important when the campaign moves from design and development into a marketing platform or campaign management workflow.

My handoff rule: The next person should not have to guess which version of the design, HTML, images or links is the production-approved version.

Common Figma-to-HTML Email Mistakes

  1. Coding directly from a screenshot. A screenshot hides component relationships and responsive behavior.
  2. Trying to reproduce every Figma effect literally. Some visual effects need email-safe alternatives.
  3. Ignoring the mobile design. Desktop and mobile should be treated as connected specifications.
  4. Using images for important text. Live HTML text is often more flexible and accessible.
  5. Waiting until final QA to consider Outlook. High-risk components should be identified early.
  6. Ignoring dark mode. Light-mode approval does not guarantee dark-mode readability.
  7. Skipping accessibility during development. Accessibility is easier when built into components.
  8. Copying the same component multiple times. Reusable modules make future campaigns easier to maintain.
  9. Matching Figma at the expense of email compatibility. The goal is reliable visual intent, not fragile pixel imitation.
  10. Not comparing final rendering with the approved design. The coded email should still be reviewed against the source design.

My Figma-to-HTML Email Checklist

Figma Review

  • Desktop reviewed
  • Mobile reviewed
  • Components identified
  • Design system understood

Assets

  • Images exported
  • Dimensions checked
  • Alt text planned
  • Production paths confirmed

Development

  • Email-safe structure
  • Reusable components
  • Responsive behavior
  • Outlook fallbacks

Accessibility

  • Meaningful links
  • Alt text
  • Contrast
  • Reading order

Rendering

  • Outlook
  • Gmail
  • Apple Mail
  • Mobile clients

Final QA

  • Dark mode
  • Links
  • Visual comparison
  • Production handoff

FAQ

Can I convert a Figma email design directly into HTML?

You can use the Figma file as the visual specification, but I would not treat the conversion as a direct one-to-one export. Production email requires decisions about tables, client compatibility, responsive behavior, accessibility and fallbacks.

What should I check in Figma before starting email development?

I check frame sizes, content width, spacing, typography, colors, repeated components, assets, desktop/mobile behavior, buttons, footer and any visual effects that may need an email-safe alternative.

Should I use the exact font from Figma?

I use the intended font where the email environment supports it, but I always establish sensible fallbacks. The final rendered email is what matters because font substitution can change line wrapping and component height.

Should email developers use tables when converting Figma designs?

For many production emails, table-based layout remains a practical way to achieve reliable cross-client rendering. I use tables where they provide the compatibility needed, while keeping the structure readable and maintainable.

How do you handle Figma designs that use effects unsupported by email?

I first identify whether the effect is essential to the message. If it is decorative, I may use an email-safe approximation. If it is important, I look for a fallback that preserves the design intent without creating fragile client-specific code.

When should responsive behavior be decided?

Before coding. I prefer to understand how each component should behave on mobile before building the desktop version, because this reduces rework later.

Should accessibility be considered from the Figma stage?

Ideally yes. Designers and developers can identify contrast, hierarchy, meaningful content and interaction requirements early. The developer then carries those requirements into the HTML and QA process.

What is the biggest difference between Figma-to-web and Figma-to-email development?

Email has a much more fragmented rendering environment. The developer must translate the design into HTML and CSS that can survive different email clients rather than relying on a modern browser as the primary rendering environment.

Conclusion

A successful Figma-to-HTML email workflow starts before the first line of HTML is written.

I first understand the design, identify reusable components, prepare assets and decide how the layout should behave on mobile. Then I translate the visual system into email-safe HTML, account for Outlook, build accessibility and dark-mode considerations into the components and validate the result across the required clients and devices.

The goal is not to make the HTML look like a screenshot only in one environment. The goal is to preserve the designer's intent while producing an email that is reliable, responsive, accessible and maintainable.

My biggest Figma-to-email lesson: Good email development starts with understanding the design, not copying it. Once you understand the intent and component system, the code becomes much easier to build and maintain.

That is the approach I use to bridge the gap between design and production email development: understand the Figma file, translate the system, test the real rendering and refine the implementation until both the design intent and technical requirements are satisfied.

Continue Learning HTML Email Development

Explore more practical guides on responsive HTML email development, Outlook compatibility, dark mode, accessibility, QA and maintainable email systems.

Back to Blog Get In Touch

Get My Free HTML Email Developer Toolkit

Get my practical HTML email developer toolkit with useful resources, reusable techniques, QA guidance and production-ready email development tips.