Thoughts on HTML Email Design, Segmentation and Best Practices

In a recent HTML overview presentation I led, an interesting question came up. While I was knee-deep in indicating the various challenges faced in HTML email design because of the many platforms that email can be read on, someone had essentially asked if we needed to bother ourselves with those difficulties anymore. Given that we have the email marketing tools to segment our mailing lists based on a number of criteria, could it be theoretically possible to eschew the many platform dependent limitations that HTML email often has? Couldn’t we just set up targets based on email client and send mailings that were tailored for that?

At first blush, I would have to say that this is a great idea. Why? Because designing for email is pretty annoying. As a web designer, you have to keep up with changes in browser technology, design conventions and updates to the very code we use to make our web creations. That’s just standard practice. However, despite the fact that we may be producing assets in 2013, when it comes to email, unfortunately, you find yourself having to code things as if it were 1997.

Thanks to the many different operating systems, web browsers, email clients (both applications in their own right as well as web mail clients) and, now, mobile devices, it’s a bear to design something – anything – in such a way that they render correctly and consistently across the aforementioned. Case in point: If you’re not careful, Gmail will introduce a line break before each of the images that make up your email design. Sometimes Yahoo mail observes line-spacing differently than other email clients do. If you don’t call them out specifically, elements will inherit alignment properties (i.e., centered, flushed right, flushed left, etc.) specified for the parent element in Hotmail and Internet Explorer. And then there’s Outlook and its specific quirks…

The only way to ensure uniformity in presentation across the aforementioned nightmare is to follow established best practices that more or less appease the aforementioned’s lowest common denominator. Sadly, that means writing out HTML the way you would before the ubiquity (and some would say, triumph) of CSS. So, that brings us way back to 1997. Maybe 2005. (Definitely not this decade, anyway.)

So, given that following best practice conventions means going backward several steps HTML-wise, why then is the idea of targeting based on platform not one I would recommend?

Well, first of all, it would be a lot of work. Assuming you have a list comprised of the addresses of recipients who use a variety of email clients, you would have to create a template for each of those platforms. Yes, each. This is made all the worse by the fact that should the messaging ever change in any one of the templates, it will have to be recreated in all the other versions of your communication. And even then, since different platforms support (or don’t support) different features, you’ll have to decide which platform (and, to some level, which recipient) will get which specially formatted content. That’s a lot of management that you probably don’t want to do.

But, hey, let’s say that somehow all your recipients magically use the same email client. That would eliminate all those headaches, right? Wrong. What if the email you painstakingly designed to work for that one particular email client gets forwarded? What then? There is no way to account for what system this new recipient will be using and, thusly, you will have no idea if your design will break when viewed. And what email marketer doesn’t want their materials forwarded to another person? What email marketer doesn’t want their list to grow?

In light of the ability to segment and theoretically send technologically tailored content to your recipients, it looks like we have to fall back on those good ole best practices. Coding HTML as if it were pre-dot com era may not be fun, but it makes things doable. And it is proven to work. As a result, it produces the widest reach.

%d bloggers like this: