April 30, 2001

Tips for practical newsletter design

Summary: good newsletters, both HTML and plain text, explain themselves clearly and are focused, well-written information sources.

There are lots of newsletters on the internet: email newsletters are very common, and web page newsletters are gaining popularity. However, a lot of newsletters (particularly email newsletters) have serious problems:

Remember, an online newsletter of any kind is most likely going to be viewed on a computer screen. That means poor quality, and little space. Users don't want to strain their eyes, nor their brains, so they need to be able to scan newsletters and pick up on the important stuff right away. I simply delete many of the newsletters I receive even if they would be valuable, because I can't get a good idea of what's in the newsletter right away.

The two basic newsletters: HTML and plain text

HTML newsletters are very common on the web, and increasingly are taking the place of plain text newsletters in email. They tend to have a few graphics, hyperlinks, and more complicated layouts than those of plain text newsletters.

Plain text newsletters don't have any links, nor any complex layout mechanisms. They rely on good writing and organization to be meaningful.

Bad things in HTML newsletters

I get a lot of very big HTML newsletters. They slow down my email program, and tend to have a lot of junk in them. Spammers, take note: if you want your spam to be even minimally valuable, pay attention to this article. Here are some things to avoid in HTML newsletters:

Long articles

Newsletter authors will have to use their judgement when it comes to article length. Long articles, more than a few hundred words, are basically useless. They will push other content out of the visible display area, and are hard to scan.

Multicolumn layouts

Just as in web pages, multicolumn layouts are hard to folllow, and take a long time to render in some email programs. One column is sufficient: it's a newsletter, not a newspaper.

Unrelated links

Unrelated, or out-of-context, links have no place in HTML newsletters. I frequently receive email newsletters that have line after line of links, trying to expose me to everything under the sun. Users have no need for that: a newsletter is not an internet portal. Newsletter authors are better off inserting a context-sensitive link and gently guiding users to a website that incrementally exposes the reader to more and more relevant information.

Gratuitous images

Again, newsletter authors will have to use their judgement in deciding which images are useful and which aren't. A small logo might be fine, in addition to a relevant graph or pertinent photo. But only one or two images is fine. Images take a long time to load, especially in some email programs.

Good things in HTML newsletters

HTML newsletters are more effective than plain text newsletters, and than paper newsletters. The interactivity afforded by hypertext is invaluable and lets newsletter authors trim their works and make them scannable. Here are some things to do in HTML newsletters:

Keep writing simple and to-the-point

This guideline is fairly straightforward, but it is important nonetheless. Like all online writing, newsletters should be simple and to-the-point. Consider how many emails or other snippets of text the user is likely to read in one day or one session, and remember that they are going to want substance, quickly. If filler seems necessary, then there probably isn't enough content to make a newsletter worthwhile.

Use links extensively

Links are great: provide short summaries of articles, and link to longer and more complete versions. Provide the links in context, and use them as they would be used in a typical web page, rather than in a big bunch at the beginning or end of the newsletter.

Use short human-generated summaries and tables of contents

The first thing in an HTML newsletter should be a descriptive title, followed by an easy to use, hopefully hyperlinked table of contents. Make sure that the links are either clearly external (will launch a browser), or that they lead to anchors in the newsletter. Use the former if the newsletter doesn't actually contain the articles, and the latter if the newsletter does contain articles.

Make sure that if the newsletter contains a bunch of abstracts of longer articles found elsewhere that the summaries are written by humans rather than generated by a computer (à la search engine summary report) or just appropriated from the first paragraph or sentence of the article. The summary should be as meaningful as possible.

Use bulleted lists

Lists, instead of paragraphs of text, make the newsletter scannable. Explain main points following a short (one or two sentence) summary by using a short bulleted list. The table of contents could also be a bulleted list.

Use hierarchical elements

HTML offers H, or heading, tags, which let the newsletter author specify a document hierarchy. For both accessibility and visual reasons, use the hierarchy. H1 tags should be for the newsletter title, and higher number H tags for subitems of all kinds. Take advantage of what HTML offers in terms of document hierarchy. For example, this page has a hierarchy specified with H tags that makes it easier to scan and more accessible.

Bad things in plain text newsletters

Plain text newsletters are quite different beasts than HTML newsletters. They don't have as many useful intrinsic properties; authors must be very craty in order to make them scannable and useful. A lot of plain text newsletters, including one I get from my hosting provider, are way too long and complicated to be of any practical use. Avoid the following pitfalls in plain text newsletters:

Long articles

Again, long articles are a no-no in newsletters, particularly in plain text newsletters. There is usually no easy way to tell when one article ends and another begins, and plain text newsletters are often viewed at very small font sizes, making them hard to read anyway. The shorter, the better.

Forcing users to go to another medium

There must be a reason to choose plain text newsletters over HTML newsletters; don't send a plain text newsletter that has no content other than a bunch of URLs, phone numbers, or mailing addresses. Send a newsletter with content, and don't force users to skip to another medium to get the real content. Plain text might not be perfect, but since you've got the user's attention, take advantage of it. Making the user copy and paste a URL just breaks his flow.

Prose

For the same reasons that articles in plain text newsletters should be short, the articles should also be written in point form and be cleverly structured: conclusion, main points, important notices or background info, and for more info click... (URL). Using drawn out language will make the newsletter harder to scan and understand.

Good things in plain text newsletters

Plain text newsletters can be positively accented with by following a few guidelines:

Use spacing, capitalization, and symbols to emphasize document hierarchy

Plain text newsletters don't have the style and structure facilities afforded by HTML, so the author is restricted to spacing, capitalization, and symbols for emphasis. Headers might be all caps, preceded by a > symbol, and so on. Stars or dashes can be used as separators. Try not to run text together as if it each article and the table of contents were combined into one long document.

Tell users what's in the newsletter straight away

Because it's harder to scan plain text newsletters (due to the lack of variation in font size, layout, etc.), the user must be explicitly told what's in the newsletter right away. If the newsletter is being emailed, use a good subject line. In other words, use the subject line to describe what's in the email, not just to say that it's issue XXX of the SuchAndSuch newsletter. Additionally, use a dashed/bulleted list at the very top of the newsletter to emphasize what follows in the document.

Include only two or three subjects per newsletter

Again, because plain text newsletters are harder to scan and navigate, they should be simpler on the whole than HTML newsletters. Only include two or three items, subjects, or articles in a plain text newsletter. If there is more to say, break it up into additional newsletters. It's better to send two issues than a double issue, because the double issue will be harder to deal with in many ways.

Conclusions

None of the above guidelines are necessarily going to be always useful, especially as different newsletter media are developed. In the future, newsletters may be a Flash movie that can accomplish everything in one place and with relatively little bandwidth usage. For instance, it's not practical to include five full length articles in a newsletter now, but it may be in future interactive versions of the same newsletter.

More important than guidelines about how to format newsletters is what should be in the newsletters. Newsletter authors must be able to justify the newsletter according to user goals. Don't send a newsletter if the user is going to go out and get the information anyway; send the newsletter if the information is critical and unlikely to be self-discovered by the user. Talk to users, model their use of the information in the newsletter, and an appropriate format will become more evident.

Adam Baker is a user experience designer who's worked at Google, Apple, BlackBerry, and Marketcircle, and mentored startups in Vancouver.