Understanding The Challenges (And Frustrations) of HTML Email Design

If you open up a content management system to build web pages, it’s a pretty simple process. Modern web browsers support HTML, CSS, and JavaScript to a strict set of web standards. And, they’re really just a handful of browsers that designers need to worry about. There are exceptions, of course… and some simple workarounds or functions specific to those browsers.

Because of the overall standards, it’s really easy to develop page builders in content management systems. Browsers comply with HTML5, CSS, and JavaScript… and developers can build incredibly robust solutions to build web pages that are responsive to devices and consistent across browsers. Two decades ago, virtually every web designer was using desktop software to develop web pages. Now, it’s pretty uncommon for a web designer to develop a web page – more often than not, they’re developing templates and using editors in content systems to fill in the content. Website editors are fantastic.

But email editors are woefully behind. Here’s why…

Designing HTML Emails Is Far More Complex Than For A Website

If your company wants a beautiful HTML email designed, the process is exponentially more complex than building out a web page for a number of reasons:

• No Standards – There is NO strict adherence to any web standards by email clients that display HTML email. In fact, virtually every email client and every version of every email client acts differently. Some will honor CSS, external fonts, and modern HTML. Others honor some inline styling, will only display a collection of fonts, and ignore everything but table-driven structures. It’s actually quite ridiculous at this point that no one is working on this issue. As a result, designing templates that render across clients and devices consistently has become big business and can be quite expensive.
• Email Client Security – Just this week, Apple Mail updated to block all images in HTML emails by default that are not embedded in the email. You either give permission to load them an email at a time, or have to enable the settings to disable this setting. Along with email client security settings, there are also corporate settings.
• IT Security – Your IT team may deploy strict rulesets on what objects can actually be rendered in an email. If your images, for example, come from a specific domain that’s not whitelisted in a corporate firewall, images simply won’t show up in your email. At times, we’ve had to develop emails and host all the images on the corporation’s server so that their own employees could see the images.
• Email Service Providers – To make matters worse, the email builders that email service providers (ESPs) actually introduce problems rather than constrain them. While they promote their editor is What You See Is What You Get (WYSIWYG), the opposite is often true with email design. You’ll preview the email in their platform, then the email recipient sees all kinds of design problems. Companies often unknowningly opt for a feature-rich editor instead of a locked-down editor thinking that one has more features than the other. The opposite is true… if you want emails that render consistently across all email clients, the simpler the better because less can go wrong.
• Email Client Rendering – There are hundreds of email clients, each rendering HTML differently across desktop, apps, mobile, and webmail clients. While your nifty text editor on your email service provider may have a setting to put a heading in your email… the padding, margins, line-height, and font-size may differ on every single email client. As a result, you have to dumb down the HTML and code every single element differently (see the example below) – and often write in exceptions that are email client specific – to get an email to render consistently. There’s no simple block types, you have to do table-driven layouts that are the equivalent of building for the web thirty years ago. It’s why any new layout requires both development and cross-email client and device testing. What you see in your inbox may be totally different what I see in my inbox. It’s why rendering tools like Email On Acid or Litmus are a must to ensure your new designs work across all email clients. Here’s a short list of popular email clients and their rendering engines:
  • Apple Mail, Outlook for Mac, Android Mail and iOS Mail use WebKit.
  • Outlook 2000, 2002 and 2003 use Internet Explorer.
  • Outlook 2007, 2010 and 2013 use Microsoft Word (yes, Word!).
  • Webmail clients use their browser’s respective engine (for example, Safari uses WebKit and Chrome uses Blink).

An Example of HTML for Web Vs. Email

If you want an example that illustrates the complexity of designing in email versus the web, here’s a perfect example from Mailbakery’s article 19 Big Differences Between Email and Web HTML:

<table width="100%" border="0" cellspacing="0" cellpadding="0">
   <tr>
      <td align="left">
         <table border="0" cellspacing="0" cellpadding="0" bgcolor="#43756e">
            <tr>
               <td class="text-button"  style="padding: 5px 20px; color:#ffffff; font-family: 'Oswald', Arial, sans-serif; font-size:14px; line-height:20px; text-align:center; text-transform:uppercase;">
                  <a href="#" target="_blank" class="link-white" style="color:#ffffff; text-decoration:none"><span class="link-white" style="color:#ffffff; text-decoration:none">Find Out More</a>
               </td>
            </tr>
         </table>
      </td>
   </tr>
</table>

<div class="center">
   <a href="#" class="button">Find Out More</a>
</div>

How to Avoid Email Design Issues

Email design issues can be avoided by following a decent process:

1. Template Design – Build out a template with different layouts and content blocks that encompass every style that you’d ever want to produce in your email designs. When we implement a client, we always push them to design an email for the future – not just the next email campaign that’s sent out. That way, we can fully design, develop, test, and implement the necessary workarounds before they ever send out that first email.
2. Template Testing – Understanding the email clients that your subscribers are utilizing and ensuring that your HTML email is fully tested across mobile and desktop is critical before deploying any template. We can design an email literally from a photoshop layout… but slicing and dicing it into table-driven, cross-email client is essential to deploying email designs that are optimal and consistent.
3. Internal Testing – Once your template is designed and tested, it should be sent to an internal seed list within the organization to review and approve. You may even want to start with a very limited subset of individuals to first ensure there aren’t firewall or security issues associated with rendering the email internally. If this is building out an instance on a new email service provider, you may even find some filtering or blocking issues associated with even getting your email to the inbox.
4. Template Versioning – Don’t change your layouts or designs without working on a new version of your template that can be designed, properly tested, and deployed. Many businesses love one-off designs for every campaign… but that requires every email be designed, developed, and deployed for each campaign. This adds a ton of time to the email marketing process internal. And, you risk not understanding what elements in your email are performing well over what elements are not. Consistency isn’t just a way to make the process easier, it’s also important to the behavior of your subscribers.
5. Email Service Provider Exceptions – Virtually every email service provider has a means of working around the issues that their email builder introduces. We can often add raw CSS to an account – or even have a content block that has to be included in every email – in order for the company to utilize the built-in email editor and not have it break the design of your email. Of course, that may require some training and process control to deploy those steps to ensure they’re complied with. Or – you may literally just want to develop your email design in a solution that is proven to work across clients and devices, then paste it back into your email service provider.

Email Design Platforms

Because email service platforms have done a poor job at building out and maintaining cross-client and cross-device consistently rendered builders, a number of great platforms have come to market. One that we’ve used extensively is Stripo.

Stripo is not just an email builder, they also have a library of over 900 templates that can be easily imported. Once you design the email, you can the email to 60+ ESPs, and email clients, including Intuit Mailchimp, HubSpot, Campaign Monitor, AWeber, eSputnik, Outlook, and Gmail. Best of all Stripo templates come with the email rendering tests included so you can ensure they’ve been tested and work consistently across over 40 email clients.

Login To The Stripo Editor Demo

Disclosure: Martech Zone is linking to my marketing consulting firm who designs and deploys cross-client emails for leading brands in virtually any email service provider. I’m also an affiliate of Stripo and I’m using my link in this article.