The hype around social media, mobile apps, and other technologies, along with the declining number of people using email for communication leads many to view email as outdated. Considering the critical role email plays in society, is this wise?

Imagine if email stopped working tomorrow. How would you register for a new site? or buy something on Amazon? or reclaim a forgotten password? or apply for a new job? You might be able to do some of these things using text, but most people don’t like giving out phone numbers. Many things today depend on having a working email account.

Consider email ROI. Some marketing companies claim email offers impressive returns on investment. Some find these claims hard to believe. Yet even if only a small fraction of what these marketers claim is possible, then viewing email as outdated could be a big mistake.

An Email Developer Perspective
After determining that nearly 20% of our company’s website traffic was coming from email, I was asked to transfer from web development to our company’s primary email department. Having worked for many years as a front end web developer, I had heard the email department operated on a much smaller budget. Although email and web development share some similarities, there are important differences and frankly, I was not happy about moving to email. But being a good corporate soldier, I made the best of it and dug in.

Some of my research on email was encouraging, such as the potential ROI and the distinct advantages email has over other mediums. Email is among the least expensive ways to target large and very specific audiences with very specific content. It is easily shared, archived and searchable. Results can be constantly tracked and analyzed enabling modification. It can be a one-way, multi-way, one to one, or one to many communication. Email offers many advantages that no other medium offers.

I had to keep reminding myself of these things as I dealt with the challenges of email. They are legion. As I dug deeper into understanding them, it was clear that: 1) doing email correctly was not easy and 2) we were not doing email correctly.

In the previous year, the email department that I was now a part of (a Scrum team of about 5 plus an offsite product owner) had previously been tasked with converting over 20 email campaigns into “mobile friendly” templates. None had been converted successfully.

After researching email development best practices, and reviewing the current process, I made some recommendations. Thankfully, the team was willing to comply (at least initially) and we converted all the emails in about 3 months. We focused on three main issues:

  • Understanding the unique challenges of email development
  • Having a consistent and reliable development process
  • Agreeing to reasonable business requirements

Understanding the Unique Challenges of Email Development
As many people do, the team was assuming the basic rules of web development also applied to email. They do not. For example, consider the browser wars of the 90’s. Back then, a web page in Mozilla often looked very different in IE (same with Opera, etc.). There was a need to standardize. This lead to organizations like W3C and WaSP. Eventually the major browsers did standardize and today, when we view web pages in most popular web browsers, the presentation is fairly consistent.

Not so with email. There was never such an outcry to standardize email clients. As a result, many (HTML) emails in Outlook today often display differently than in Gmail, or Yahoo Mail, or the dozens of other applications that display email. Email clients handle CSS differently, and many don’t handle JavaScript at all. If you develop email templates using web development rules, they are going to break in some email clients.

The key to explaining this to the team was getting them all in the same room at the same time and show them how one of our email templates displayed differently in 3 or 4 popular email clients.

Consistent and Reliable Development Process
While we were all together with the above in mind, we needed to agree on a process. The Foundation Zurb email framework was proposed for responsive design since it seemed to be among the most advanced for email. All frameworks have limitations so it was important to get agreement on which framework (and which limitations) we would use.

Because email clients are inconsistent and there are dozens of them, a short list of which clients to develop and test for was needed. We reviewed a usage analytics chart which helped us establish a list and agreed to develop and test for 14 specific email clients. We would review the analytics annually and update the list if necessary. To test our short list, we needed a tool. Several online tools were considered. We decided on the Litmus tool which offers a free trial, but if you are serious about email, you’ll likely need the paid version. Litmus also worked with one of the data vendors we were using. We received budget approval for the tool.

Another essential step – CSS in-lining, where CSS instructions (p {width: 100%;)) are inserted into template tags:

< p style="100%" >

Online tools are available to do this fairly quickly, but it does add significant time to the overall process. Not doing this step increases the chances of a broken display in some email clients. We also received budget approval for this tool.

Other important steps were added to the process, like regularly sending test emails to individuals, but the most important step by far was agreeing on a signoff point in the process where change requests would no longer be accepted, and for this we needed cooperation from the business end.

Agreeing To Reasonable Business Requirements
Many team members said the primary reason for the lack of success in achieving the goal in the previous year was the number of change requests.

By reviewing a diagram of the overall process (PowerPoint) with the team, we were able to show how much rework was needed when changes came at the end of the process. We agreed that, ideally all changes should occur early in the design phase, but we also recognized how much clearer the quality of an email was when you actually open it in an email client. So we agreed that after sending a test email (through the new tool) for final approval there would be an opportunity to make final changes. If changes were made at this point, at least we could avoid repeated tagging and other steps toward the end of the process. We also agreed on a limit of 3 rounds of changes after sending the test email (if 3+ were needed, perhaps we’re in the wrong business).

With the new process in place, not only were we able to make all 20+ templates responsive in about 3 months, but we streamlined the process, reduced email turnaround time and significantly reduced the number of broken email display complaints we received. We were now in a better position to focus on targeting email content to specific audiences, which is a topic for a later discussion.

Although there are many advantages to developing for the web, the two years spent developing with the email department has given me a much greater respect for this unique communication medium.