Figma to HTML Email: Complete Design-to-Code Workflow & Best Practices

Introduction: Converting Figma to HTML Email

Converting a Figma design to responsive HTML email is fundamentally different from building a web page. Modern web standards rely on Flexbox and Grid, but production email must render predictably inside Word-driven Outlook, Gmail, and various mobile email apps.

The goal is to translate visual design intent into robust, client-safe HTML tables, inline styles, and bulletproof components.

Related guides: WCAG Email Accessibility Standards · Responsive HTML Email Development · Outlook Email Rendering Issues

The Designer-to-Code Mindset

Before coding, decompose the Figma composition into technical layers:

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?

Step 1: Inspecting the Figma File

Review the design frame specifications:

• Container width (commonly 600px to 660px)
• Mobile breakpoint mockups (320px–420px viewports)
• Padding, margins, and column gutters
• Font sizes, line heights, and weights
• Hidden layers and final copy status

Step 2: Identifying the Visual System

Extract reusable design tokens before coding individual modules:

Step 3: Preparing and Exporting Assets

Export only the assets needed for the email and use formats supported by your target inboxes. JPG is suitable for photographs, PNG for transparency and crisp graphics, and SVG should be tested carefully because support varies by client. Do not assume WebP or SVG will work everywhere without checking your audience's email-client matrix.

• Use descriptive, production-hosted absolute image URLs rather than local Figma export paths.
• Set explicit width attributes and display:block to reduce gaps around images.
• Keep important headlines, offer details and CTA labels as live HTML text whenever possible.
• Write useful alt text for informative images; use empty alt text for decorative images.
• Check file size, crop, transparency and mobile scaling before handoff.

Step 4: Translating Layout into Email Modules

Break the Figma frame into reusable modules instead of treating the design as one large image. For each module, record its desktop layout, mobile behavior, background, spacing, content and fallback behavior.

• Header: logo, optional navigation and safe-area spacing.
• Hero: live headline, supporting copy, image and primary CTA.
• Content rows: reusable text, image and two-column modules.
• Footer: preferences, unsubscribe, legal copy and contact details.

Before coding, note which visual effects are essential and which can be simplified for clients with limited CSS support. Consistent spacing tokens make later revisions easier.

Step 5: Building Responsive Email Table Structure

Construct a nested table skeleton using presentation roles:

<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td align="center" style="padding: 20px 0;">
      <!-- Main 600px Container Table -->
      <table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0" class="email-container">
        <!-- Module Rows -->
      </table>
    </td>
  </tr>
</table>

Step 6: Typography and Fallback Font Stacks

Always declare clean web-safe fallback fonts (Arial, Helvetica, sans-serif) to prevent layout shifts when custom brand fonts are blocked by Outlook or Gmail.

Step 7: Optimizing Email Graphics

Declare width attributes and inline CSS styles to prevent broken layouts during image loading:

<img src="hero.jpg" width="600" alt="Special product offer" style="display:block; width:100%; max-width:600px; height:auto; border:0;">

Step 8: Building Bulletproof Buttons

Rather than relying on modern CSS button tags, build cross-client bulletproof buttons that work in Outlook:

<table role="presentation" cellspacing="0" cellpadding="0" border="0">
  <tr>
    <td align="center" bgcolor="#111111" style="border-radius: 4px;">
      <a href="https://example.com" target="_blank" style="font-size: 16px; font-weight: bold; color: #ffffff; text-decoration: none; padding: 14px 24px; display: inline-block; border-radius: 4px;">Shop Now</a>
    </td>
  </tr>
</table>

Step 9: Responsive HTML Email Code & Stacking

Decide the mobile behavior from the design before writing CSS. A two-column desktop module may stack image-first, text-first or remain side-by-side depending on the content hierarchy. Use media queries where supported and a fluid-hybrid approach when the client matrix requires it.

• Check the email at narrow widths such as 320px, as well as common modern mobile widths.
• Confirm columns do not cause horizontal scrolling or clipped content.
• Check button width, touch area, text wrapping and spacing after stacking.
• Provide sensible fixed-width fallbacks for clients that ignore media queries.

Do not assume that a responsive web page technique will work identically in every email client.

Step 10: Outlook Rendering & MSO Conditionals

Use conditional MSO comments to ensure Outlook on Windows renders fixed widths and tables accurately:

<!--[if mso]>
<table role="presentation" width="600" align="center" cellpadding="0" cellspacing="0" border="0">
<tr><td>
<![endif]-->
<!-- Standard responsive container -->
<!--[if mso]>
</td></tr>
</table>
<![endif]-->

Step 11: Dark Mode Email Styling

Dark-mode behavior depends on the email client and operating system; some clients preserve authored colors, while others transform backgrounds and text. Treat dark mode as a separate test case rather than assuming a CSS rule guarantees the same result everywhere.

• Review body and module backgrounds, primary and secondary text, links and CTA contrast.
• Check transparent logos against both light and dark backgrounds.
• Use a suitable light/dark logo asset where needed, and verify the fallback when image swapping is unsupported.
• Confirm legal copy and footer links remain readable after color transformations.

Step 12: WCAG Email Accessibility

Ensure descriptive alt text, high-contrast links, and role="presentation" on all layout tables as covered in our WCAG email accessibility guide.

Step 13: Decoupling Content from Code

Separate reusable layout from campaign-specific content wherever the sending platform allows it. Use clearly named modules and editable content fields for headlines, body copy, image URLs, alt text and CTA destinations.

For each editable field, define a safe fallback and document whether it supports plain text, HTML or platform-specific personalization syntax. Keep conditional content readable when a variation is empty, and test each important audience branch before launch.

Step 14: Side-by-Side Design Comparison

Compare the coded email against the approved Figma frame at matching viewport sizes. Review the overall hierarchy first, then inspect details such as line breaks, image crop, spacing, borders, button dimensions and footer alignment.

1. Capture a screenshot of the approved design and the rendered email.
2. Compare the same module at the same width and zoom level.
3. Record each difference and classify it as a design mismatch, client limitation or intentional fallback.
4. Fix high-impact issues first, then rerun regression checks in affected clients.

The goal is to preserve the design's intent while accepting documented differences required for reliable email rendering.

Step 15: Cross-Client Rendering Tests

Run preview tests in Litmus and BrowserStack across desktop Outlook, webmail, and mobile apps following our HTML email testing workflow.

Step 16: Production Campaign Handoff

Prepare a handoff package that lets the campaign manager build, test and schedule the email without guessing about implementation details.

• Provide the approved HTML version and a record of the corresponding Figma frame/version.
• Confirm image URLs are absolute, publicly accessible and point to production assets.
• Document required personalization fields, fallbacks, audience conditions and tracking parameters.
• List known client-specific differences and the rendering tests completed.
• Include the final proof, open issues and named approver.

Use the email campaign QA checklist to complete the pre-send review. If HTML changes after approval, repeat the relevant regression tests before scheduling.

Common Mistakes to Avoid

1. Direct CSS copying from Figma: Flexbox, CSS Grid, and custom box-shadows break in older email clients.
2. Slicing entire sections as single images: Blocks screen readers, trips spam filters, and causes layout blurs.
3. Overlooking Outlook's rendering quirks: Leads to broken column widths and irregular padding.
4. Missing font fallbacks: Creates unwanted line breaks when custom web fonts fail.

Frequently Asked Questions

Conclusion

A structured Figma-to-HTML email workflow ensures your campaigns honor design intentions while maintaining bulletproof rendering and accessibility across all major inbox providers.