HTML Email Design Best Practices

Designing for HTML emails can seem drastically different than designing for websites. For instance, standard website conventions call for a 960px width, while the standard for HTML emails is only 600px. That’s over 1/3 narrower than a lot of designers are accustomed to. Sadly, the technology in a number of HTML email clients is years behind that of standards compliant web browsers. So not only will interactive JavaScript not work, but many common style attributes will be ignored. A few cases of things that are not supported would be rollover button states, common transitions or audio/video playback.

Dimensions

Best practices dictate that the acceptable width of your email template should be 600px not to exceed 650px. To ensure the recipient views the most relevant information, it should be put into the top 250px of the email. This is the general dimension of an email client’s preview panel and what is likely to be seen when the email is first opened.

The “header” of your emails should be kept to a minimum height – no taller than 120px. The taller the headline message, the further down the page your actual message will be displayed.

Images

Images are not a substitute for your content; they should be used to assist in conveying your message. If a user has disabled image downloads in their email client, how will the branding message be conveyed before the user even chooses to download the images that your layout may require?

There can be great value in using background color in an email over background images. Hexadecimal colors are supported by all email clients and are a web standard. If a solid color can be used in place of an image you will have a greater chance that your layout will be rendered on the user’s email client.

It is a common practice in development to break up large images into smaller ones to achieve multiple clickable areas in the header or body of an email. The same technique can be used for styled navigation or even repeatable borders. There are certain creative techniques that look great in design, but are not acceptable when it comes to email development:

  • Tiled background images or large background images. These are not supported in older email clients (especially Outlook), and your design will likely not hold true. If these are required, ensure that the client is aware that a solid color may be all that is displayed in place of the tiled/background image on older email clients.
  • Drop shadows, rounded corners or other dimensional effects. These are achievable through the use of images, but not through the HTML alone. These design choices can also greatly affect download times and overall campaign “weight” if the email blaster has set size standards.
  • Violator images. These should be kept to a minimum unless the overall width of the email can be narrowed to accommodate the over hanging images. If violators exceed the 650px maximum limit then they may be cut off in the email client’s preview pane.
  • Animated Gifs. Animated Gifs will work in some of the modern email clients, primarily those that are web browser based. However, for those that do not support the animation, the email client will likely only render the first frame and display it as a static image.
  • Transparent Images. Transparencies are not well supported and should be considered unacceptable. If a transparency is required, plan on the background color in the PSD image also being included in the final image.

Always include “alt” text for your images. If a recipient does not automatically allow images to download in their emails, the alt text is what they will see instead. The alt text should be used in a meaningful way. It should not only speak to what the image is, but also how it relates to your message. You should also supply color and font options for alt text as some email clients allow for the alt text to be styled.

Fonts

Web safe fonts should be used for all HTML emails. Stick with common fonts like Arial, Helvetica, Tahoma and Verdana for sans-serif families, or Times New Roman, Georgia and Garamond for serif families. Since users may open the email on any number of devices and email clients. Only use the default web safe fonts in emails unless you intend the text to be contained within a graphic. Custom font faces are not permitted. Only those users with the same custom font face installed on their machine/device would be able to properly render the custom font.

  • Custom kerning. Kerning is not widely supported in native email clients and should be avoided – unless the copy can be included as an image (which should be kept to a minimum – if images are disabled your message will be missed).
  • Font smoothing. Font-smoothing and other techniques applied to fonts in Photoshop and even web browsers will be ignored in many email clients so fonts may not appear as crisp or seem pixelated.
  • Text wrapping. Your design should take into account that text will not wrap around any other objects in the email. There is a work around for wrapping text around images, that a developer may or may not employ.

Fonts should be set at a minimum size of 12px for body copy and a maximum of 20px for headlines. A minimum of 12px allows for easy readability, while keeping headlines at 20px or below will keep your email from triggering any spam filters that look for large type.

Links

Links should be easily accessible regardless of the viewing medium or email client. Studies show that approximately 50% of recipients read their emails on a mobile device. To ensure proper accessibility, calls to action and other links should be designed with a height and width of at least 44px each.

Interactivity

JavaScript cannot be included in an HTML email. While a few email clients may accept the built-in interactivity, most will immediately see the email as a threat and send it to junk or spam folders. The only sort of interactivity that may be included is linking to content further down an email from a link at the top, for example a table of contents or link to contact information. The internal link scrolling down the email does not require JavaScript.

Forms

Do not include forms, such as: registration, surveys, etc. A limited number of email clients will allow for the functionality to be transferred to the web browser. This will lead to a broken experience for the user.

Videos

Videos in HTML emails are not allowed. Only one email client, as of this writing, supports video playback in emails. It is best to link to a video on a website using a thumbnail of the video within the email.

General

All HTML emails should be accompanied by a plain text version of the email. No images and no markup are to be allowed in the plain text version. The plain text version must be available to those recipients who refuse images in their emails. Also for those who view their emails on a mobile device set to only view text versions. Certain security settings will automatically file all emails without a text version as spam immediately, thus your message may never be received.

Follow CAN-SPAM rules. People have come to expect certain things in the footer of their emails. If the email is promotional (as opposed to transactional) they have come to expect a link to unsubscribe, or at the very least a contact email by which to accomplish that task. To fully comply with the CAN-SPAM Act, the sender must also include their physical mailing address in the footer of their emails.

For a more “accessible” approach that would be scaled across devices, it is preferred to limit designs to a single column. Sometimes branding and other situational items may dictate special scenarios. However, as a rule, maintain a single column, reserving two or three column content for the lowest portion of the email design. An example would be extraneous ISI information included within an email. Important information, but it can likely be laid out differently than the rest of the message.

More Information: Check out http://www.email-standards.org.