NOW AVAILABLE: Professional Email Design. Get the book →

Email at the Turning Point

| Email Industry

This post was adapted from a talk I gave for the e-Village Inspiration Sessions in the Netherlands. In it, I wax philosophic about the current state of email design and make a few predictions for the future. Hopefully they turn out to be true.

I’ve spent a lot of time thinking about email marketing and, more specifically, email design. Over the course of six or seven years, I’ve worked with email in a variety of capacities. I’ve helped clients as both a freelancer and an agency grunt. I’ve written two books on the subject. And for the past year or so, I’ve worked alongside the Litmus team, arguably the best in the business.

After all that time, it’s sometimes fun to look back at what’s happened over the years. More importantly, by looking back at my history (and the history of email marketing over the past decade), I think I can use that information and make a few predictions about the future.

What We Do in Email

At this point, it seems nonsensical for anyone to argue against the importance of email. Email marketing is consistently one of the most valuable digital channels and routinely provides amazing returns for companies willing to spend the time, effort, and money on email.

Aside from driving business goals, as email marketers, we do two extremely important things: inform people and build connections. Through the power of email, we help keep our subscribers up-to-date on what’s important to them. Through transactional emails, newsletters, product and service announcements, etc. we give people information that is useful and improves their lives. And, when we can provide that information in a delightful, surprising, entertaining, or just uncomplicated, thoughtful way, we build real connections with people. We are oftentimes the voice of a company, of a brand, and through us, those companies deepen connections with their users, subscribers, customers, and loyal fans.

Building Connections

I talk about building connections because it’s so important not only today, but in the future of email design as well. Too many companies focus solely on driving revenue, much to the detriment of their subscribers. Which is kind of crazy. I understand it from a business perspective, but honestly, by focusing more on informing and building relationships with people, those same companies would likely see those business goals absolutely crushed.

But how can we inform people more effectively? How can we build and deepen those connections? To understand that, let’s look at the history of email design…

The Past

The history of email marketing over the past ten years can roughly be broken up into three eras. It’s important to note that these eras have a lot of overlap. And these are just broad generalizations. There are a lot of edge-cases and weird developments in the email design world, but I think these three stages accurately describe how email has evolved.

Early Stage: The Desktop Days

The early days of email are defined by the desktop. For years, that’s the only way people accessed the internet. The email clients available to users directly influenced how marketers built emails. Clients like Lotus Notes and Outlook shaped how we coded our campaigns. Hell, they still do today. The lack of support for proper HTML and CSS forced designers to hack together emails. The one (arguably) good thing about the desktop days is that the environments in which emails were viewed were known. Designers could rely on screen sizes falling within a known range. As a result, email campaigns were fixed-width by nature. There was no need to fluid or responsive emails and, despite the problems with terrible rendering engines, an email designer’s job was largely easier than it sometimes is today.

Middle Stage: The Mobile Revolution

Email was forced to evolve shortly after the iPhone was introduced in 2007. While smartphones and internet-enabled devices existed prior to that, the iPhone’s huge screen and touch interaction created a new paradigm. People were now reading their emails away from their desks. And, as more device manufacturers entered the market, so did mobile email subscribers. No longer were designers worrying about a handful of desktop and webmail clients on 13-, 15-, and 17-inch screens. With the mobile revolution, we saw increasing fragmentation.

This fragmentation took two forms: the number of email clients themselves increased and the number of different screen sizes exploded. Email designers were forced to adapt. And adapt we did. We took cues from web designers and started using techniques like fluid and adaptive layouts in email. This alleviated some problems, but introduced others. It made the inconsistencies between email clients and rendering engines blindingly obvious. Fortunately, we saw the rise of not only reactionary design techniques, but reactionary tools, as well. Most notably, tools like Litmus allowed you to test your campaigns in all of this different clients and devices and services like Campaign Monitor and MailChimp released amazing templates that worked well across most clients.

Late Stage: Responsive Design

The latest stage in email’s evolution started around 2010, but hasn’t really picked up steam until the last two or so years. Again, taking cues from the web world, email designers have adapted the three tenets of responsive web design (fluid layouts, fluid images, and media queries) to work with HTML email. We’re now seeing some amazing campaigns that move beyond basic fluid tables and truly optimize their layouts for a variety of screen sizes. It’s opened up a world of opportunities for designers and companies that aren’t afraid to break new ground. More importantly, responsive emails have improved the experience of email for an increasingly mobile audience. This improved experience allows us to inform people more effectively and build deep connections. Which is what we should be trying to do all along.

But, as great as responsive design is, there are still a few problems that we can’t seem to shake as an industry.

  1. Dinosaurs. Not the Jurassic Park kind, though that would be cool. No, we still have a huge number of senders that haven’t moved beyond that first, desktop-focused era. These dinosaurs keep the average level of quality in email design really low. That de-facto, low quality level of design makes it hard for progressive designers to get company buy-in for pushing email design forward.
  2. Email Clients. Email clients, especially ones with shitty rendering engines, just stick around. And, with the rise of mobile devices, we’re seeing a few really, really bad clients gain marketshare (looking at you, Gmail). These clients make it hard for designers to focus on anything other than hacks, forcing them to design defensively.
  3. Tooling. Until recently, the tooling around email design hasn’t changed much at all. We’ve been stuck with sloppy, hack-filled code written in editors meant for the web. And for email marketers not familiar with coding, life has been even harder.

Stuck in the Past

The Turning Point

But, I truly believe that email is at a turning point today.

Pretty soon, we’re going to see a solution to most of these problems. As a result, we’re going to be transitioning from defensive design to exploring interesting, innovative approaches to email design. That’s the turning point: we’re going to be freed up from worrying about shitty email clients and hacks. Once that happens, we’ll be able to focus on content, interaction, experience, and building those deep connections with people.

Here’s how I think it will go down:

Email Will Become a Solved Problem

The biggest and oldest problem for email designers are the lack of standards which are a side effect of email clients and their rendering engines. No real standard exists for coding emails since no two email clients support the same HTML elements and CSS properties. That’s not likely to change anytime soon, but I predict that email will largely become a solved problem for senders.

This is due to two interesting developments.

First, more and more email designers are sharing their knowledge. With places like the Litmus Community and tons of brilliant folks talking about email design, we’ll see the refinement and adoption of techniques that will make email design easier than ever before. I’m not saying that people won’t need to know how to code or hack Outlook, I’m saying that the method of doing so will be well-documented and easy to implement. Once that happens, designers will be free to think about more important aspects of email design, like strategy and content.

Second, the tooling around email design is constantly improving. This past year, we’ve seen a number of companies tackle tools for email design. There are now code editors and visual design tools that make email design a lot easier. These tools aren’t without their problems, but they are constantly being improved and, over time, will go a long way towards making everyone’s lives easier. Coder and non-coder alike.

Gmail Will Get Better

As it stands today, Gmail is the worst email platform out there. At least as far as HTML email designers are concerned. A lack of support for CSS and media queries means that Gmail’s various apps and interfaces routinely break designs that work well everywhere else. While there are fixes for Gmail, they are involved and lead to volatile code that is harder to maintain over time.

Fortunately, there have been indications that the Gmail team is finally beginning to listen to our complaints. While I still don’t think they fully understand all of our concerns, they are finally putting in some effort and attempting to. I think that, within the next year, we’ll see better CSS support and media queries introduced in Gmail. They cite security concerns, but honestly, if Yahoo and AOL can figure this stuff out, Google doesn’t really have an excuse anymore.

We’ll See an Increased Focus on Content

Once all of the headaches involved with coding are alleviated, email marketers and designers will be able to focus on what’s really important in email: the content. We’re going to start to see more thoughtful, relevant, and valuable content in emails. One thing I’m really looking forward to seeing is better personalization that takes into account a subscriber’s history and context.

As we grow these relationships with subscribers, we’ll be able to tailor emails to an extent we haven’t seen before. While personalization exists to varying degrees today, we’ll start to see it really take shape when we can focus more on content. Looking at past interactions, preferences, where and when people open, what they did on your site after engaging with an email, etc. will push content to new heights. It should be interesting.

Apart from the use of advanced personalization and context, I think (and hope) we’ll see just plain better content. Better copy, better aesthetics, valuable information—pretty much everything that subscribers want, but not too many companies do well right now.

We’ll See the Rise of Email Experience Designers

Along with this increased focus on content, we’ll see a new role emerge in email marketing: the email experience designer. On the web and in software development, the role of a user experience designer is commonplace. These are the people that shape how users interact with and experience a software product. They think not only about content, but how people engage with that content. Then they design interactions and animations to facilitate that engagement.

While there are some amazing examples of interaction and animation in email, they are rare. I think that will start to change. We’ll eventually see people taking on the role of experience design in email. Crafting interactions and animations that not only display information, but surprise and delight users as well. That surprise and delight is working towards our ultimate goal: building deep connections with our readers.

So, when will this actually happen?

All of these predictions are great (especially if they come true, or else I’m left looking like an idiot), but when will they actually come to fruition?

I think we’ll see Gmail get it’s platform into shape in the next year. By 2016, we’ll all be a bit happier. The bad part is that Gmail likely won’t announce it on their blog or anything, so one of us will have to stumble on the update instead. I’m fine with that, as long as they fix their clients.

Once that happens, that whole ‘email as a solved problem’ prediction will naturally come about. I don’t think it will be as quick, but in the next 2-3 years we’ll see tools that truly take the pain out of email design and a body of knowledge about email design, problems, and solutions be widespread. You’ll have to be living under a rock (without internet access) to keep pumping out bad emails.

The focus on content and the rise of email experience designers may take a bit longer. We’ll see both in fits and starts but, like most things in email, we’ll still see a lot of companies just not really caring about either. They’ll stick to their old ways, regardless of what everyone else is doing—or what subscribers will start to expect and crave. Eventually though, it will happen for anyone that cares about email. I’m looking forward to that.

Building Connections

We Can Start Today

Ultimately, it’s all up to you (and me) to change things. We are finally seeing the knowledge and tools needed to make this future a reality. Once we can all move beyond that defensive design mentality, we can start focusing on content, experience, design, and delight. We can focus on building relationships instead of building emails that render fine in Lotus Notes. We can pay attention to our audiences instead of hacks. We can finally push things forward and deepen connections with real people in the most personal of digital spaces: the inbox.

I’m looking forward to the future. I can’t wait to see what you build.

Buy Professional Email Design Today

| Email Books Publishing

I’ll keep this short.

My new book, Professional Email Design, is now available to purchase. It’s over 130 pages of information on building HTML email campaigns. You can learn more or grab a copy by following the link below. Oh, and if you buy a copy, you’ll get free updates for life.

Get the book now

New Book Sample: Typography in Email

| Email Publishing Books

This is a sample from my new book, Professional Email Design, that launches on January 15th. Sign up for my email newsletter to receive information about the book and get notified when it’s available for purchase.

There’s an old article from the design studio Information Architects that makes a great point:

Web design is 95% typography.

As an offshoot of web design, the same is true about email. No matter what your message, you need to be able to communicate it clearly using type on screen. Clear type is only half the battle, though. We want to make email a delightful experience for our subscribers, so making that type beautiful and enjoyable to read is our ultimate goal.

This chapter takes a look at how to apply styles to your text, how to make those styles work well across email clients, using web fonts in email, and avoiding any major bugs.

Applying Styles to Text: Part 1

I mentioned earlier in the book that some designers insist on using semantic elements in their HTML. They mark up headlines using h1, h2, h3, etc. tags. Paragraphs are naturally wrapped in p tags. Unless accessibility is absolutely necessary, I typically recommend avoiding this method. Every rendering engine has its own way of styling those elements and, if you want your email to look similar everywhere, you will necessarily have to override those default styles. The semantic way leads to writing a lot more code and, usually, the required step of running that code through an inliner.


An inliner is a tool that takes CSS written in either an external stylesheet or in the head of an HTML document and moves that CSS inline on individual HTML elements. There are a ton of inliners out there, and most work well. However, I prefer to hand-code inline styles so that I can a) keep the code clean and b) know and understand every piece of my email template. Also, I don’t trust the robots. If you are interested in using an inliner, the tools section of the appendix has suggestions on a few.


So, if not on heading or paragraph tags, where do we apply styles? Let me introduce you to arguably the best email designer in the world: Kevin Mandeville. Kevin is the email designer at Litmus and consistently blows people away with what he does in the inbox (think stuff like CSS animations, SVG, Video backgrounds, product tours IN THE INBOX). He also has a saying that every professional email designer should have tattooed on their forehead.

<td> or GTFO.

If you ask him, he’ll say the GTFO stands for get to fixing Outlook. But we all know what it really means…

Essentially, <td> or GTFO means that nearly all of our styles should be applied to table cells. We’ve seen this applied when talking about structural padding and alignment in the last chapter, now we’ll look at how table cells are used to style content. They’re our bread and butter, so get used to applying everything there. Following that logic, all of our text will exist directly within a table cell.


<td>This is some text that we want styled.</td>

So, any styles we want that text to have are slapped right on the table cell.


<td style="PUT YOUR STYLES HERE">This is...</td>

This approach will be applied to all of our text with the exceptions of:

Basic Styles

To cover our bases, if a table cell contains text, it should always have the following styles defined:

Even if you are using normally weighted text or the same font family as other copy, you can’t rely on table cells inheriting styles from a parent. Let’s look at an unstyled block of text:


<td>The next time you email your subscribers, stop and think before telling your boss that you sent out the latest blast. Instead, show her that you value your subscribers as people by saying you sent the latest message to your audience. You sent a campaign. You sent the next part in an ongoing conversation.</td>

Let’s say we want to make the text lighter, use a sans-serif, increase the size a bit, and add some line-height to make the reading experience more comfortable. We can accomplish this with the properties listed above:


<td style="color: #666666; font-family: Arial, sans-serif; font-size: 18px; font-weight: normal; line-height: 22px;">The next time you email your subscribers, stop and think before telling your boss that you sent out the latest blast. Instead, show her that you value your subscribers as people by saying you sent the latest message to your audience. You sent a campaign. You sent the next part in an ongoing conversation.</td>

That’s better, huh? You could just copy and paste that formula into all of your emails, but then you wouldn’t learn anything, would you? Let’s take a look at each of those properties and see which kinds of values should be used.

Color

The color property controls the color of the text inside an HTML element. It accepts a variety of values, including:

Like most other things, these all work on the web but not in every email client. The safest way to declare colors in HTML email is by using the six-character hexadecimal value. Therefore, anytime a color is declared in this book, it will take the form:


color: #ffffff;

Some email clients, typically ones which use the Webkit rendering engine, can handle the other methods, too. If you know your audience is largely opening emails in Webkit-based email clients (Apple Mail, iOS Mail), then you can use something like RGBa, which is useful for adding transparency to text.

Font Stacks

The font-family property controls what typefaces are used to display text. If left undefined, operating systems and email clients will default to system fonts (e.g. Times New Roman, Arial, Georgia, or Lucida Grande) that come installed on most systems. You should absolutely define a font stack–an explicitly stated preferred ranking of fonts–for your text.

A font stack allows you to declare back up fonts for when a preferred font isn’t installed on a computer or, in the case of web fonts, is unable to be downloaded. When declaring your font stack in the font-family property, you put your preferred font first, followed by increasingly generic backup options:


font-family: Futura, 'Trebuchet MS', Arial, sans-serif;

In this instance, if Futura is installed, text will be displayed using that font. In Futura’s absence, it will then fall back to Trebuchet MS first, Arial second, and whatever sans-serif font is installed as a last resort.

You will notice that Trebuchet MS is surrounded by quotes. This is because it consists of two separated words. Many fonts have complex names and, if they include spaces, will need to be wrapped in single quotes. This handles any email clients that can’t properly parse spaces in the font-family property.

We’ll revisit the font stacks when we start talking about web fonts. Until then, keep this in mind:

Font stacks allow us great control over the most important aspect of our campaigns. You should never allow the system or an email client to make design decisions for you. Always declare a decent font stack, even if it’s a simple one.

Font Sizes

On the web, there are a number of ways to declare font sizes. You can use keywords like large or xx-small, fixed values like px, or relative values like ems and rems. Since we’re working towards always building responsive emails, you would be right in thinking that relative units like em and rem would be ideal. However, a lot of email clients don’t understand font sizing unless declared using pixels.

Therefore, all of our font sizes will use the px value:


font-size: 18px;

You can make that font size as big or little as you want, but you should keep a few things in mind.

First, some mobile devices (looking at you, iPhone) automatically resize text that is smaller than 14px in an effort to make it easier to read on smaller screens. Anything below 14px will be resized to 14px. So, if you’re using small text for something like a disclaimer, you will need to account for this in your code or risk your design being broken.

This can be accomplished by using the text-size-adjust CSS property, prefixed for the appropriate rendering engine. Webkit on iOS is the main perpetrator, but Windows Mobile does something similar. As an example, we can target both. You can do this in one of two places:

As a style reset in the head of our document:


<head>
  <style type=“text/css”>
    body, table, td, a {
      -webkit-text-size-adjust: 100%;
      -ms-text-size-adjust: 100%;
    }
  </style>
</head>

Or inline on an element in case the head is stripped out of the document:


<td style="-webkit-text-size-adjust: 100%; -ms-text-size-adjust: 100%;">CONTENT</td>

Secondly, you should use a comfortable font size for all readers. A good baseline is to have text around 16-18px. This is big enough for most readers to easily read, while not being so big it only allows you to fit 20 characters on a line.

Finally, don’t make your text too big. While you want your headlines to stand out from your body copy, don’t make them absurdly massive. Use other tools like font-weight and color to create hierarchy, in tandem with font-size.

When we look at making our emails responsive, we’ll come back to font-size and see how we can change the size of our type on different devices.

Font Weights

The font-weight property allows you to specify how heavy a font should appear. The weight refers to how thin or thick the lines that make up letters are. A great typeface will have a lot of different weights available. Other typefaces will only have one or two.

A font’s weight can be declared using either a keyword (e.g. normal, bold, bolder) or a numerical value (e.g. 100, 200… 900). In most cases, you will likely only use the normal or bold keyword. However, if you are using a typeface with a lot of variations, say Proxima Nova, you may want to rely on numerical values for font weights, since it allows greater flexibility of design and access to all of the available weights.

Let’s say we have a large headline set in a thin variation followed by some smaller body copy that needs to be set in a medium weight. You can mark that up like so:


<tr>
  <td style="color: #222222; font-family: ‘Proxima Nova’, Arial, sans-serif; font-size: 32px; font-weight: 100; line-height: 30px;">Blastphemy</td>
</tr>
<tr>
  <td style="color: #666666; font-family: ‘Proxima Nova’, Arial, sans-serif; font-size: 18px; font-weight: 400; line-height: 22px;">The next time you email your subscribers, stop and think before telling your boss that you sent out the latest blast. Instead, show her that you value your subscribers as people by saying you sent the latest message to your audience. You sent a campaign. You sent the next part in an ongoing conversation.</td>
</tr>

The typical design will likely call for a bold headline and normally weighted text. This is where you can simply use keywords:


<tr>
  <td style="color: #222222; font-family: Arial, sans-serif; font-size: 32px; font-weight: bold; line-height: 30px;">Blastphemy</td>
</tr>
<tr>
  <td style="color: #666666; font-family: Arial, sans-serif; font-size: 18px; font-weight: normal; line-height: 22px;">The next time you email your subscribers, stop and think before telling your boss that you sent out the latest blast. Instead, show her that you value your subscribers as people by saying you sent the latest message to your audience. You sent a campaign. You sent the next part in an ongoing conversation.</td>
</tr>

Both approaches are perfectly valid, it all comes down to how specific you need to be with weights and whether you want to keep track of a bunch of number values or a few keywords.

Line Heights

The line-height property allows you to specify the amount of space between lines of text. Again, you can specify values a few ways, including a unitless number, fixed values like px, and relative units like ems and %.

On the web, it is common practice to declare line-heights using a unitless number to avoid inheritence issues and unpredictable results. Unfortunately, not all email clients understand unitless numbers. So, your safest bet is to use a pixel value when setting the line-height property, like so:


<td style="line-height: 20px;"></td>

The space between lines has a very real correlation to how easily we can read text. If text has too little space between lines, it feels cramped and uncomfortable to read. If there is too much space, lines start to feel disjointed.

The line-height of a block of text works in tandem with the font-size of that text, as well as the width of the block of text itself. Typically speaking, smaller text should have larger line-heights, while larger text can afford to have smaller line-heights. My general rule of thumb is to have the line-height four pixels larger than the font-size for most normal text. For headings, that will drop to either equal that value or even be two or four pixels smaller than the font-size value. However, you should always test out different line-heights in your designs to see what feels comfortable to read.

Font Styles

While not mentioned above as an absolutely necessary style to apply, another useful CSS tool is the font-style property. This property allows you to specify one of three variations of a font: normal, italic, or oblique.

Without declaring a font-style, text will be displayed using the normal value. Both italic and oblique are a means to a similar end in that they will slant a typeface. Italic fonts typically use a properly designed, italic variation that is included in a typeface. Oblique fonts rely on skewing the regular version of a typeface to create slanted fonts.

You will likely only ever use the italic value to make your text you know… italic. This can be useful to provide emphasis on a word or phrase, or to set a particular section apart from the surrounding text, for example, in a photo caption or a disclaimer.

Want to read more? Professional Email Design will be available for purchase starting January 15th.

Stay in the Loop | A weekly missive about the web, email, or whatever catches my fancy.