Email lists are an e-marketers dream: mailing lists provide a highly targeted way of reaching people; email doesn't require you to wait until the customer remembers to go visit your site.
Mailing lists allow you to
extend the footprint of your website
. In the literal sense (get space in the user's inbox and not just in the browser). And in the more interesting metaphorical sense: More services become possible when you can reach out to users and provide them with time-dependent information.
remember the push fiasco
: it is not the goal to lay claim to ever-increasing amounts of the users time; prompt them just enough to be useful but not so much that the email becomes a burden. Users will unsubscribe faster than you can say "information overload."
Some companies send out very long emails that constitute complete newsletters. I prefer
keeping the email very short
, restricting it to headlines and summaries with links to more extensive content on the website. Two reasons:
Users are incredibly stressed when processing their inboxes: they have to get to the urgent messages from their boss, customers, spouse, etc., so they typically don't have time to read much. The rule for Web content is keep it short. The rule for email content is keep it
You want the email to link back to your website since that's where you can provide a much richer user experience in those cases where the user does want more depth than can be provided in an email.
Mailing List Commands
Traditional listservs used a user interface technique from the 1950s: batch processing. Users would send the server a list of commands in the body of the email message, much as they used to submit a batch of punched cards to the mainframe priests.
Bad usability. No interaction. Plenty of cause for errors.
If everything went well, the user would receive instructions in the use of the mailing list system. Do users read instructions? Worse, do users
instructions until the day they need them? No, that's why all these old list systems are flooded with mail asking "how do I get off?"
It is better to make the email system itself serve as the user interface: provide a special email address for each of the main commands: subscribe, unsubscribe, post discussion group message, etc. Keep the list short and there is a chance that users will understand it.
Any more complicated commands should be relegated to a web-based interface. Hopefully even the most advanced mailing list system will be simple enough to be explained on a Web form with a few buttons and type-in fields.
before getting your email newsletter. Many sites try to do so by having a user registration form that contains a little box for "I want to receive valuable marketing promotions" that is checked by default. This is
Sure, some users will overlook the box and will not uncheck it. That does not mean that they will welcome your newsletter. On the contrary, they will detest your company for sending them spam. Even worse, those users who do notice the little box will
lose trust in your site
because they will feel that the site is trying to trick them.
Much better to
leave the box unchecked
and only collect those users who are eager to get your material.
The most trust-destroying design I have seen was employed by Boo.com: they had the standard little checkbox, but the fine print said to check the box if you did
want to get their mailings. As we all know, users don't read instructions very closely, so the average user would simply leave the box unchecked, believing that he or she had avoided the newsletter. When the mailings started arriving anyway, users might be very upset about the presumed violation of their instructions. Luckily Boo died because of its many sins against usability, so this "opposite design" did not hurt very many people.
To increase the number of users who subscribe, don't just talk about "valuable offers". Instead, provide explicit information about:
what type of information and offers the mailing list will contain
how frequently it is published (people are more likely to subscribe if the frequency matches their needs - consider offering multiple newsletters with different publication frequencies to serve different market segments)
how to see a sample newsletter
subscribing - people are more likely to sign up if they know what they will get
In an e-commerce checkout process the goal of the design is to close the sale as quickly as possible. Don't provide any distractions in the form of newsletter information. It is best to postpone any mention of the newsletter until the confirmation page that is shown at the end of the process. Once you have separated the customers from their money, you can start promoting other things. Less cynically stated: the best way of promoting customer loyalty on the Web is to simply close the order and ship the product. It is so difficult to buy anything on the Web that those sites that actually deliver something people want to buy will have their loyalty for a long time. All other marketing tricks pale in importance relative to fulfillment.
Discussion groups should support digests, where the user receives an entire day's messages in one chunk. This format should be the default for new users to avoid overloading them with messages and scaring them away.
It is nice to provide a feature for getting each posting as an individual message for those users who want to follow the discussions in real time.
Discussion groups should preferably be moderated to prevent spam from making it onto the list and to enforce a minimal set of standards for good list behavior. Unfortunately, moderation is a good deal of work: a rent-a-moderator service might be a good business idea, locating the moderators in low-salary countries.
It goes without saying that email should only be sent to people who have opted-in to the mailing list. But even if you are an ethical mailing list operator, you will sometimes be accused of spam:
mis-type their own email address
when asking to be added to mailing lists. If they happen to type a legal address, then the owner of that address will be placed on the mailing list by mistake. The main two ways of avoiding this both have usability problems:
Do not use a Web form for subscribing. Instead use a
that causes the user to send an email to the mailing list service. Two problems: First, mailto links violate the basic assumption on the Web that clicking a link will cause a new page to be displayed. Instead they surprise and annoy the user by dumping them into a different application. Second, the
-address inserted by the email program may not be the one where the user wants to receive the mailings.
Send the user a
and don't activate the subscription unless you receive a positive reply. Extra steps are obviously an annoyance and some users will not understand the instructions in the confirmation message: make sure to usability-test this text thoroughly. Yes, plain text can be a user interface.
and their old email address is taken over by the new employee. This person never asked for the mail but will keep getting it.
Well-meaning users will
add an internal distribution list
as a subscriber because they think that everybody in a certain department ought to get the messages. Some of these people will inevitably be annoyed about getting mail they didn't ask for. Unfortunately there is no way to protect against this problem since you cannot tell which email addresses refer to individual users and which are distribution lists.
My preferred solution to the last two problems is to have the
footer of each message state the email address
to which the messages are sent. This allows recipients to understand
they are getting the mail and helps them unsubscribe the appropriate address.
To avoid complaints about spamming users, provide an easy way to unsubscribe and
explain how in the footer of every single email message
Some people may say that doing so would encourage users to get off the list and thus lose customers. But somebody who is getting tired of your emails is not likely to be much of a customer anyway. And the more you annoy that person, the less they will like you. Make it easy to get off, and maybe they will get back on some other time.
Most important, if you have any belief in the concept of
, you should recognize that you only have users' "permission" as long as they
want to hear from you. Permission does not mean
"I once conned the user into giving out his/her email address, so now I can do as I please."
My preferred unsubscription design is to create a dedicated email address for each user: if any email is sent to that address, the user is removed from the mailing list. This personalized unsubscribe email should be listed at the bottom of every single mailing list message.
When users unsubscribe, they should get an
that confirms that they have been removed from the list. This message should include the instructions for how to subscribe:
Maybe the user simply wants to move the subscription to a new address. Make sure you don't lose them in the process.
Maybe the user wants to unsubscribe temporarily while working under a heavy deadline or other pressure.
Maybe the user will regret not getting your valuable information and will decide to resume the subscription at some later time.
Subscription Info in Footer
Each message footer should contain instructions on how to subscribe. If your newsletter is good, recipients will often forward it to other users, and they need to know how to get their own subscription.
Case Study: Alertbox Announcement List
The Alertbox has about
, of which only
notification mailing list
. Most people get so much email that they are very protective of their inboxes. Thus, 86% of the readers prefer simply to check out the columns at their own pace rather than getting an email the minute a new article is available.
A few months ago, I changed mailing list provider for the Alertbox announcement list, so it serves as a good example of the impact of usability on subscription growth:
new subscribers per week
new subscribers per week
Improved usability increased subscriptions by 128%
. This big effect should come as no particular surprise: it is quite common for usability to double the use of a web feature.
The old list server was particularly bad and I only used it because it was (a) free and (b) maintained by somebody else. It used the old-time batch processing command model where users had to type exact commands in the body of the email messages. Even worse, the confirmation messages for
subscriptions were sent from the address
. Yikes: way to spook your users. And to activate their subscription, users had to reply to this message and edit the subject line to indicate their approval. Many failed to do so.
The Alertbox announcement list is now hosted at
, an ASP that specializes in high-end mailing lists. I have been very happy with their service. The usability of the interface for list administrators (i.e., me) could be much better, but the UI for subscribers is good.
One benefit of using a professional mailing list service is
speed of delivery
. SparkLIST typically delivers my 28,000 emails in a few minutes whereas it took a full day for my previous provider to work its way through the mailing list. Many subscribers rightly complained that they had asked for the email to get notified
Response time requirements
for email are quite different than those for Web pages. As mentioned many times,
Web pages need to download in less than 10 seconds
to satisfy basic human factors requirements (and 1 second for optimal usability). Email does not involve navigation and users don't sit and wait for individual messages. Thus, most email can easily take several minutes or as much as an hour to be delivered without any usability problems.
Delays of more than an hour may cause users to feel left out of a discussion group. Or they may feel that the news is old when it reaches them. The more a list depends on news, the faster it must be.
The one exception is email that is sent as the direct result of a user action. For example,
confirmation messages should be sent with a delay of no more than one minute
or users will start to worry that the system is down or that they have made an error.
Future of Mailing Lists
Hopefully, mailing lists won't have much of a future. In the long term, we need to
remove everything from email that is not in the nature of personal correspondence
. Users are suffocating under overflowing inboxes that combine many disparate types of information.
The services currently provided by mailing lists should be shown in a
communications control panel
that would monitor all the things the user is interested in on the Internet. Areas that are hot or have news would be highlighted, and an agent in the user's computer would prioritize the possible sources of information and show the most important ones with the most real estate. For sure, the communications control panel would collapse threads of discussions into a single object and visualize its activity in a more useful manner than hundreds of scattered lines in your inbox.
Share :Twitter | LinkedIn | Google+ | Email