Email Design Workflow

After attending The Email Design Conference last week, it was interesting to see that pretty much every designer has a different workflow when it comes to designing emails.

Inspired by Brian, Fabio and Kevin who shared their email design processes, I thought I’d share my own. In particular, designing these transactional emails (as I rarely design promotional emails these days).

For this post I’m going to look specifically at front-end implementation of the emails.

The tools I use

• Sketch
• Sublime
• Grunt
• SCSS
• Handlebars
• GitHub
• Mailgun
• Litmus

Visual design

Using Sketch I’ll mock up how the email might look. At this point I’m experimenting with colors, layout and hierarchy. I’m not trying to achieve pixel perfect mockups. Emails never look the same across all clients, so I’m not going to waste time on pixel perfection.

For transactional emails I believe it’s important to be focused. Each use case is different, but by being focused I mean removing all the fluff. Recipients shouldn’t be distracted by fancy graphics, social media icons, and verbose copy if the goal of the email is to get them to click one button.

Coding HTML emails

I’ll start off with a boilerplate that I know works. I think Zurb does a great job with their boilerplates. I went a step further and created a very simple email template, which I’ve now integrated with a Grunt workflow (more on that in a bit).

My preference is to use SCSS for CSS (I can’t imagine not using SCSS now).

What is SCSS?

SCSS, or Sassy CSS, extends CSS and gives it extra powers. It enables you to write things like this:

$primary-color:blue;
$secondary-color:red;

.btn-primary{
     background-color:$primary-color;
     &:hover{
          background-color:$secondary-color;
     }
}

This is a very simple example using variables and nesting. There is so much more you can do with SCSS. It makes managing your styles a dream.

Templating and layouts

Chances are the header and footer of your emails aren’t going to change. Therefore some sort of templating comes in useful.

I use Handlebars and split my emails up into something like this.

+-- layouts
|   +-- default.hbs
+-- emails
|   +-- email1.hbs
|   +-- email2.hbs
|   +-- email3.hbs

Inlining CSS

Before sending out HTML emails, you should inline your CSS. There are a few options for how to accomplish this. I use Juice, which I have baked into my Grunt task. You can also use web inliners like Responsive Email CSS Inliner.

Other options include manually writing your CSS inline (ouch!), using one of the other online inliners available, or a lot of ESPs will handle this for you before sending out your email. It will look something like this:

<a href="http://www.mailgun.com" class="btn-primary" style="font-family: 'Helvetica Neue', 'Helvetica', Helvetica, Arial, sans-serif; box-sizing: border-box; font-size: 14px; color: #FFF; text-decoration: none; line-height: 2; font-weight: bold; text-align: center; cursor: pointer; display: inline-block; border-radius: 5px; text-transform: capitalize; background: #348eda; margin: 0; padding: 0; border-color: #348eda; border-style: solid; border-width: 10px 20px;">Confirm email address</a>

Using Grunt to run these tasks for you

Using Grunt I’m able to run a set of tasks using Javascript.

I’ve open-sourced my Grunt workflow here, which does the following.

1. Compiles your SCSS to CSS
2. Builds your HTML templates
3. Inlines your CSS
4. Shoots out a test email

The end result is HTML email templates with CSS inlined, along with a preview delivered to my inbox.

Testing emails in different clients, browsers, devices and OSs

First of all it’s a good idea to send yourself an email to your own client. I use Mailgun to shoot myself the email. Then I check it in Gmail and on my iPhone.

Secondly you want to see how it will look in all those other devices and clients that people are using. This is where Litmus kicks ass. Send your email to Litmus and they will show you the results in whatever clients you care about.

Back-end integration

At this point I have a solid HTML email template designed. Since these are transactional emails, typically triggered by user actions, the next step is integrating them into my code base.

Sending email

It’s a good idea to use a 3rd party email service (Mailgun is a good option) instead of managing your own email infrastructure. Then all you need to do is make an API call and they handle the delivery.

Code integration

This differs depending on what language and framework you’re using, and at this point you should be working closely with a developer.

For integrating into code (e.g. a Rails app), my preference is to copy across all the original files (SCSS, templates, layouts) and have the application handle the CSS compiling, templating and inlining (using Premailer-Rails). If using an ESP or third party service to do the sending, some of them handle the inlining of CSS, some don’t.

The best approach is to look at the documentation for the email service you decide on. They should have a library for your language of choice and good documentation on the subject.

What’s your email design process?

I’m very curious to learn how other designers are managing this. What text editor are you using to put together your emails? What’s your workflow when it comes to sharing emails with developers, or integrating them into your code base? Share your comments.