Designing for HTML email

One of the things I do for my job at C3 is design our HTML e-newsletters and action alerts. Until this job, I could count on one hand the number of HTML emails I ever designed or sent out. I’m learning with each one that it presents some unique challenges.

Sure, there are services that do a lot of the heavy lifting for you, such as Campaign Monitor, Constant Contact or MailChimp. In particular, I have to shout out to MailChimp for a really great blog on the subject and some downloadable templates and guides that say a lot of what I’ve had to figure out for myself.

We use GetActive. While there are some default templates for email in the application, we’re really on our own for customization. Luckily, GetActive makes it very easy to pour your own HTML into a wrapper for emails.

I used to be of the mind that HTML email was evil. Plain text or die was my mantra. My thinking has evolved on this issue. I’ve found that for my own mail-reading, I actually prefer HTML email for everything except for general correspondence. If it’s just “Hey, Judi, how about we have that meeting on Tuesday afternoon” give it to me in plain text, please. But e-newsletters are really hard to follow in plain text. Too much text without color, images or styling to break up the space.

It seems I’m not alone. We give our subscribers the option of getting the plain text version of our emails. When I send out an action alert or newsletter, the software auto-selects which version to send. Looking at the stats of the last large email we sent out a few weeks ago, less than 1% went out as plain text.

I’m learning that designing for email is a whole new game as compared to designing for the web. Same language, different rules. Here’s some lessons I’m learning along the way:

First and foremost, the standards game is different. Tables are okay in email. Almost preferred. You’re not worrying about search engines. You’re not worried about accessibility (if like us you automatically deliver a plain text version when the email client can’t read the HTML). The only advantage I can think of to keeping to web standards rules in email is in file size. However, I’ve learned the hard way that web-based email clients (such as Gmail) do a terrible job with CSS unless it’s within the body of the email or inline in each line because everything in your <head> tag is stripped out.

Sure, there are the purists who will jump through hoops to get complete web standards in email. But I simply can’t see the point. I’ve started taking email ads and newsletters that I like and I forward them to multiple email accounts so I can view them in different clients. Sure enough, the ones that work the best across multiple clients are the ones that use tables and all those nasty font tags we shun like the plague on a website. I’m not quite ready to go there, but you have to think very differently about CSS when designing for email as compared to a website. Still want to use CSS in email? Here’s an idea of what will and will not work in different web-based clients as of a year ago.

As far as structure, I shoot for around 600 pixels wide of content when I have to set a fixed width, which fits nicely in most standard preview panes. But don’t forget that AOL only gives about 200 pixels in its preview window. Hate the email client choice, not the constituent. Make it so they can read what you’re sending them.

Don’t go crazy. Think about the file size. Don’t nest tables if you can get away without nesting. And you’ll learn very quickly that all links in email must be absolute (start with http://) No document-relative links allowed.

Don’t put a colored or textured background on the page/email. Especially dark colors. You want people to forward your email. You beg them to do it in the text. And then they do and they want to add a personal note after they hit the “forward” button and your blue background makes that note impossible to read. Set the bulk of your email in a table where you apply your colors (nest the email in a larger 98% table that has the background color you want) and keep the page background itself uncolored or very, very light. Some clients strip this color out completely anyway.

Keep images to a minimum and for goodness sakes, never put essential text in an image. Assume that everyone reading email will not see a single image by default. They see something like this:

You have to be sure that the text you care about is there in straight HTML, it’s at the upper left hand side of the email and that it won’t rely on a background image for legibility. So no white text on a dark background image.

Keep it simple. This is the one that I struggle with the most with the people I work with. What seems to be a very short paragraph in Word takes up a lot of room in the tight space that email gives you. When in doubt, make it shorter. When in doubt, make the type larger. People don’t study their email newsletters, they glance at it. The reader has to understand in a fraction of a second who you are and what you expect for them to do.

Further reading: This page is up-to-date and contains a lot of the information I talk about above (wish I had read it months ago instead of having to learn on my own…oh well). It also links to other good articles.

Advertisements