Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

How To Improve Your Email Workflow With Modular Design

Whether you’re in a Fortune 500 company or part a two-person team launching your first web app, email is one of the most important tools for reaching your customer base. But with the ever-growing number1 of emails to send2, getting them all out the door can seem a little overwhelming. By putting in place a solid email design workflow, you’ll be able to regularly ship engaging and mobile-friendly emails with ease.

Complexity Meets Adaptation Link

In addition to the increasing number of emails, the need for personalization and high quality and the introduction of responsive design have turned what was once a simple process of writing HTML and CSS in your favorite text editor into something seemingly more complex. A number of customizable templates3, editors4, tools5 and even full-fledged email frameworks6 have popped up to deal with this newfound complexity.

Further Reading on SmashingMag: Link

All of these new tools have their advantages, and many can be combined11 into a workflow that best fits you and your team. But even with a great set of new tools at your disposal, how do you structure your workflow to allow for continual iteration and quick turnaround?

Enter Modular Design Link

Modular design is the method of creating a system of self-contained components that can be stacked, rearranged and used or not used, case by case. The goal is to be able to easily change or adapt individual design patterns without altering the system as a whole. Adopting modular design and reusable patterns into your email design workflow can improve the quality and consistency of what you send, while speeding up your daily output.

Setting up a modular email design workflow involves three basic steps:

  1. Create the design system.
  2. Set up a reusable framework.
  3. Test and iterate on what you send.

Let’s look in depth at how we can accomplish each step in the process.

1. Create A Design System Link

The easiest way to streamline iteration is to break down each of your common design use cases into a system of self-contained components, each one a LEGO block, made up of content and media, that you can snap together into numerous configurations. Doing this will enable you to build a nearly infinite number of emails with ease.

Think of your designs as Lego blocks, made up of content & media.12

Think of your designs as LEGO blocks, made up of content and media. (View large version13)

Anticipate Use Cases Link

When designing your modular email system, the first step is to anticipate your use cases. Ask yourself what type of emails you typically send. Are they mostly transactional? Promotional? Informational? While all emails will likely have the same basic elements, such as a header and footer, a transactional email might need shipment information, ordering details, payment details, a contact section, and product upsells or similar products.

A newsletter might have simpler needs, such as introductory copy, a featured story, a hero image and secondary stories. Defining the content needs of the emails that you send will enable you to anticipate the common use cases that you’ll need to plan for along the way.

Design A Pattern Library Link

Once you determine common use cases, you can start to design individual components according to your needs. Whether you use Photoshop or jump right into the browser, remember to keep each component as self-contained as possible. Designing several variations of each use case might also be helpful.

Having several options for a “featured story” component, for instance, allows for flexibility and keeps things from getting stagnant over time. The patterns in your library will eventually become partials within your framework, easily referred to and called upon when needed.

Turn your use cases into modular patterns14

Turn your use cases into modular patterns. (View large version15)

Keep Your Pattern Library Up To Date Link

As new use cases arise, use your existing patterns as necessary. However, unexpected use cases will probably arise; one benefit of the modular system is that you need to design only a single component to address this situation. As you create and add patterns, make sure to keep the entire design system up to date and organized. Leaving components scattered or out of sync will make the system difficult to use. The easiest way to keep everything in sync is to turn your system into a framework.

2. Set Up A Framework Link

From here, incorporating your design patterns into an out-of-the-box templating system or framework is possible. And if you’re not interested in navigating the chaotic world of Outlook or Gmail, with all of their quirks, or if you need to get something out the door with minimal configuration, then options like Zurb’s Ink3316 will do a lot of the heavy lifting for you.

But if you send a decent volume of email, then creating your own custom framework could lead to huge gains. By creating your own framework, you can add in time-saving custom helpers, keep the markup light and easy to work with, and even hook directly into your email service provider. Not to mention that you can create more customized layouts to complement all-in-one solutions. The long-term gains in quality and efficiency from setting up your own framework can be huge.

Build on Top of a Static Website Generator Link

Adding features and tools such as Sass, YAML data and localization to your framework could also be beneficial. The easiest way to do this is by integrating your framework with a static website generator. The building blocks that are common to email and the web will enable you to repurpose almost any website generator for your email workflow.

Middleman17 is a great option and one that I’ve found ticks all of the major boxes:

  • The structure of projects as layouts, partials and pages perfectly fits our mental model of modular email.
  • Sass18 is already integrated. Sass is an amazing addition to any responsive email workflow. Common workarounds such as the one for Yahoo Mail’s attribute selector19 become an afterthought through the clever use of selector inheritance. Sass also provides powerful features such as variables, mixins and CSS minification to cut down on file size.
  • YAML data and front matter allow you to fully separate content from design and loop through data for easy prototyping.
  • If you’re sending to a large and diverse audience in multiple languages, then localization can dynamically generate that diverse set of data relatively painlessly.
  • A myriad of hooks enable us to easily create custom helpers for email platform-specific needs.
  • Middleman is Ruby-based, making it easily extensible.

Set Up A Boilerplate Link

Once you’ve chosen a static website generator that meets your needs, then it’s time to set up your base boilerplate. A boilerplate includes such things as a reset file, the CSS or Sass structure, an optional custom grid system and a base template.

Base Layout Template

A basic template will serve as your base layout structure and will allow global elements to be shared across all emails. Preheaders, headers and footers will usually stay consistent across emails. If this is the case with your designs, then you can safely build these into your layout’s template. The safer approach is either to build out and include these elements as partials or, if these elements will likely move or change in particular emails, to wrap the markup in conditional statements.

Your base email template should include at least the following:

    HTML5 is the friendliest for designing responsive emails. Remember that certain clients will either strip out or change your DOCTYPE.
  • head
    A lot is important to include here: meta tags for proper character encoding, title tags for anyone viewing the standalone version of your email in a browser, reset styles, embedded media query styles, any styles to be inlined and the viewport meta tag to set the viewport’s width.
  • body
    In addition to the standard body tag, wrap your entire email in a 100%-width table and cell structure, as shown below. The table with the body class will act as the body, thereby overcoming the drawback of certain clients removing the body tag.
  • yield
    This is from where all of your modules for individual emails will be pulled.
<!DOCTYPE html>
<html lang="en">

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta name="viewport" content="width=device-width">
  <title><%= %></title>

  <%= inline_stylesheet 'template/inline' %>
  <%= stylesheet_link_tag 'template/mq' %>

  <table class="body">
      <td class="header" >
        [Header content]
      <td class="main" >
        <%= yield %>
      <td class="footer" >
        [Footer content]

Partials Based on Modules

Keep the markup of your individual design patterns inside of partials, to keep the design system truly modular. This will allow the markup for each module to be self-contained. Taking a modular approach with both your designs and your markup becomes truly powerful. Once it’s built, you should be able to move each design pattern around to different areas of the template without breaking the module, the template or any other modules surrounding it. When you’re setting up the framework, build out each module that you’ve planned for in this way.

Taking the use case from our last example, the modular markup for a featured story would look like this:

<table class="featured-story">
    <td class="col">
      <img src="#" alt="" />
    <td class="col">
          <td class="title">
            [Story Title]
          <td class="abstract">
            [Story Abstract]
          <td class="cta">
            <a href="#">CTA</a>

Sass Structure

Following OOCSS or SMACSS20 will maintain the modularity of your Sass. In general, keep your styles as modular as possible, just like your designs and markup.

One caveat when writing CSS or Sass in an email framework is that all media query-based styles must begin with an attribute selector (such as td[class=example]{}) in order to avoid rendering issues in Yahoo Mail21. An easy workaround is Sass’ ability to nest styles. Nesting all media queries in a single attribute-based selector will prevent them from being applied to each individual style. Writing your Sass in this way will increase both readability and speed while maintaining visual consistency across clients.

Following this method, the basic media queries for optimizing the template and content area above for mobile would be this:

td[class=body] {
  @media only screen and (max-width: 600px) {
    .col { 
      display: block; 
      width: 100%; 
    .title { 
      font-size: 22px !important; 
    .abstract { 
      font-size: 16px !important; 
    .cta a { 
      display: block;
      width: 100%;

Put It All Together Link

With a base framework and modular design patterns in place, it’s now time to snap all of the LEGO blocks together. Create a page for each email that you’re building for your framework. This page should be wrapped with your base template and should call any modular patterns that you need.

Thinking in a modular way will enable you to build emails like LEGO blocks.22

Thinking in a modular way will enable you to build emails like LEGO blocks. (View large version23)
title: Example Email
layout: template

<%= partial "featured-story" %>
<%= partial "responsive-image" %>
<%= partial "social-callout" %>

Automate Common Tasks Link

One of the greatest efficiencies you can gain in your workflow is to automate frequent tasks. This typically means inlining CSS, optimizing images, sending tests, and integrating templates and modules with your email service provider. Most common tasks can be easily integrated with Rake tasks, Ruby Gems and/or Grunt.

CSS Inlining

The safest method is to inline styles whenever possible because certain email clients strip out styles from the head of documents. If you’re used to the common web workflow of writing styles in a separate sheet, then getting used to this will be hard. It can become a hindrance to modularity, and if you’re trying to use Sass to style, then this obviously becomes impossible to do manually.

Luckily, we have several options to automatically inline styles at build time. If you’re using a Ruby-based tempting engine, then the best option is to include the Premailer Gem24 in your project. Premailer automatically runs through your style sheet and inlines styles while preserving any existing styles when called. This is a huge time-saver, and it keeps markup manageable.


There are several ways to test how your email looks. The first stage in my process is to design and check the rendering in Chrome. Once the designs are completed, it’s time to jump into a more automated tool to check rendering across the board. Litmus25 is a web application, like BrowserStack26 but focused on delivering screenshots of your email across a wide variety of clients.

You can send your emails to Litmus in a variety of ways, but if you’re using Grunt in the framework, then the easiest way is by using Grunt-Litmus27. Grunt-Litmus automates the process of getting tests to your account and lets you check rendering in clients of your choice.

module.exports = {
  test: {
    src: ['email.html'],
    options: {
      clients: ['android22', 'android4'...]
      username: "username",
      password: "password",
      url: ""            

Testing on real devices is another common approach, especially vital with things like CSS animation and embedded video. If you have a device lab set up with a common email address, an easy way to trigger an email delivery directly from your framework is to use the Ruby Mail Gem.

Hook Into Your Email Service Provider

If you’re using an email platform that provides access (such as ExactTarget28 or MailChimp29), then you can set up your project to hook directly into the API and push your template along with individual modules into the system on command. Doing this allows you to build locally in the framework, keeping everything modular and under source control, and still push to your email service provider quickly and easily as you iterate. How you hook into your provider will obviously vary by platform, but definitely keep this in mind when setting up a modular framework.

3. Iterate On Your Designs Link

The periodical nature of email lends itself well to design iteration. If you’re sending emails daily or weekly, then you have ample room to A/B test your design decisions. No matter what workflow options you adopt, make sure to track important email metrics30 and use available data to improve your core design, remembering that a better experience is usually more important than any single data point.

The periodical nature of email makes for easy testing and iteration.31

The periodical nature of email makes for easy testing and iteration. (View large version32)

Don’t reinvent the wheel every time you send an email; rather, make continual incremental changes as warranted by your metrics. The benefits of a modular design workflow should make these incremental changes fairly painless as you swap components in and out. The important thing is not to let your designs stagnate.

Conclusion Link

Incorporating a modular approach and a custom framework into your email workflow can lead to increased productivity and make it easier for you to iterate on your designs. You will have to make an initial investment of time to get everything up and running, but if you send a decent volume of email and can afford the initial investment, then the result will improve your designs, the customer experience and your engagement rates, leading to happier customers and increased revenue.

(al, , il, ml)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37

↑ Back to top Tweet itShare on Facebook

Brian is a Kansas City-based UI Designer who is passionate about design, UX, collaborative workflows, and craft beer. In addition to his 9-5 on as UI Team Lead at DEG, Brian is the creator of Responsive Email Patterns, curator of Responsive Email Resources, a key developer of MiddleMail and serves as a moderator at Litmus Community.

  1. 1

    Great article! Looking forward for more tips & tricks for #RED (Responsive Email Design) – This tricky little fellow :)

  2. 3

    Just curious why you would use SASS in an email? It seems better suited to large websites that need lots of variables and big CSS files, not just a simple email blast.

    • 4

      Deric Mendez

      August 5, 2014 7:30 pm

      I’d say his “td[class=body]” example was more than enough reason to leverage SASS, especially for scalable emails with media query overrides.

      Aside from that, it’s more/less a tool to help your day-to-day workflow if needed. I’ve worked with email campaigns that have been much bigger than just “simple email blasts”. If you can use SASS in tandem with a tool like Premailer, this could allow you to write more modular HTML/CSS that’s much easier to comprehend and update rather than sifting around your html and inline styles.

      However, If you’re pumping out simple email campaigns then stick with plain-ol-CSS. At the end of the day, it’s up to the developer to decide if a specific tool is right for the job.

    • 5

      Brian Graves

      August 5, 2014 7:38 pm

      I’d agree with Deric that choosing whether or not to include Sass in your project is partially dependent on the size and scope. If you’re just creating a one off email it’s probably not necessary. More dynamic email programs that include localization, segmentation, etc can scale in complexity fairly quickly though. Sometimes design patterns for these become more similar in size to that of a website. Sass definitely comes in handy in these cases.

  3. 6


    Thanks for the thorough and inspiring perspective on the need and solution for email template generation and management.

    I’m going to take the time to check out static site generation (Middleman/Jekyll, Yaml, etc.) for email templating, but I wish someone could pull this all together for me as a hosted/managed solution.

    (I previously had my hopes raised, then dashed, by the ‘template builders’ offered by some of the envato responsive email template vendors, which sadly don’t go anywhere near far enough!)

    I’ve created and maintained templates not unlike this for Linux/UNIX server-based solutions, albeit with database injection, and the power/efficiency is fantastic, but it is also quite hardcore and soul-less for even a fairly capable end-user, especially when not using Linux/UNIX/Mac day-to-day.

    You probably know these, but, while looking around, I came across a couple other interesting variations on this theme from ( — integration of WYSIHTML5 looks like a cool move) and (

    Does something like have legs as a Middleman substitute? (Sounds simpler, and I’m guessing only a subset of mainstream static site generator capabilities needed for email template management and generation.)

  4. 7

    I saw tables in every mail template. I’m wondering why?

    • 8

      Hi Dragan,
      this is because modern box layouts as they have been best practice for websites don’t render correctly in many email clients.
      As sad as it may sound, if you want your email to look halfway the same in all mail clients (including online clients like Gmail), you still have to create a table based layout.

      Here’s a guide by Campaign Monitor that might help you (I haven’t read it completely, but their help section did prove to be helpful in the past):

    • 9

      Brian Graves

      August 5, 2014 7:29 pm

      As Max pointed out, due to the lack of standards among email clients, tables and inline styles are sadly still the required norm. The two biggest offenders are Outlook which is still using Microsoft Word as it’s rendering engine and Gmail which strips out embedded styles.

      • 10

        Not “Still using Microsoft Word” it used to use IE back in Outlook 2003.

        It changed to word in 2007 as it believed that users expected to be able to create emails the same way they create and operate their word documents.

        As an email marketer, I don’t really find this article that helpful, as due to the compatitibly issues most emails are actually quite complicated to the point where having a set framework just isn’t going to cut it.

        You often end up with tables nested in tables nested in tables nested in more tables, all nested in a background table. That just doesn’t lend itself to flexible deisgn.

        Within content blocks you setup tables to display bullets (to work around some weird rendering quirks), TD are used spacing and all sorts.

        What I tend to do once I’ve got a style sorted is to create a number of slight template variations to cover off the most common eventuallities. This is quite different form adopting a flexible/modular approach.

  5. 11

    great article useful information to everyone

  6. 12

    Adrian Thomas

    August 5, 2014 1:34 pm

    Great intro to HTML email design! If building HTML emails isn’t your core business though, you could also look into a tool like our app Mail Designer Pro to help build your templates. You can export the raw HTML (including all the nasty Outlook hacks, Gmail workarounds etc.) and use that to create the mails for your preferred workflow tool.

    As Max pointed out, building HTML emails require a lot of techniques and client-specific optimizations – so it’s not for everyone :)

  7. 13

    Zedaki Jones

    August 5, 2014 5:20 pm

    You have written a very nice article that is very helpful but it does not consider one of the most common use cases.

    How well does the email degrade into plain text without images?

    A *lot* of corporate networks will restrict images in email and if the message is unsolicited (like most promotional email is) then planning for how an HTML message degrades into plain text is quite important.

    • 14

      Brian Graves

      August 5, 2014 7:26 pm

      Considering how your message degrades when images aren’t available is definitely important. There’s a few things that can be done. One is making sure to use as much real text as possible and two is to use clear alt text on your images. These two items are important for people receiving your emails in HTML format but with images off. The other important consideration is including a plain text version for those who are only able to receive text only emails. The two different versions (HTML and Text Only) are both delivered in the same message and split out by email client using the messages MIME type.

      • 15

        I would add also that is a must to keep the text as live text and not embed into images.

  8. 16

    As far as plain text is concerned, I’ve built premailer into my workflow to not only convert inline CSS, but also because the app provides the cleanest plain text version of my content. It also does some cool stuff like calling attention to h1 tags with asterisks and providing URLs in parentheses for all your links.

    Great tut, thanks for sharing!

  9. 17

    I just want to share a PDF filling out tool I’ve discovered, just in case you need it. PDFFiller, Inc allowed me to upload word and power point document to be converted to PDF. It Lets me fill out the PDF forms neatly and after I am done, I can save, print, eFax , share or Send the forms to be signed by third parties.
    I was able to get also the form i need through


↑ Back to top