Skip to page content or Skip to Accesskey List.


Main Page Content

Email Interface Design 101

Rated 3.93 (Ratings: 3)

Want more?


peter van dijck

Member info

User since: 22 Oct 1999

Articles written: 23

Note: this article is not about web based interfaces to email, like Yahoo email

or Hotmail. It's about using email as an interface to websites or web services.

Mailing list managers have long used a command based email interface

to manage the mailing list. Link based email interfaces (unsubscribe

links) are common in email newsletters and mailing list, and job websites also

typically offer email interfaces using links. Online vendors use HTML based

emails with forms to sell products.

Email as an interface to websites hasn't been explored much by the interaction

design community. And yet email has some key advantages: it's fast and asynchronous

(you can fill in the interface, and the next time you connect to the Internet

send the email), and allows for requested interaction.

Here is a screenshot of an email interface from

example of email interface

Advantages and Disadvantages of Email Interfaces

Email interfaces have some key advantages over web interfaces:

  1. Asynchronous interaction

    You don't have to be online while giving

    the commands. A significant advantage for many people who have limited Internet

    access. [1]

  2. Requested interaction
    Software systems can request interaction by

    sending you an email.

  3. Speed

    You can send commands from your email application, which will

    often be faster than opening a website.

A main advantage of email interfaces, asynchronicity, is also its main disadvantage,

in that there is no immediate feedback. Feedback from the system can

take over 10 minutes because of email delays on the Internet. This means that

email interfaces are mainly useful for one step interactions: you get

some input and you decide on an action. You shouldn't use email interfaces when:

  1. Immediate feedback to the user is required upon action.
    Email delivery

    can experience delays of 10 minutes or longer.

  2. Tasks require multiple steps in a short time interval.

    You don't

    want the person using this interface to have to wait for the next email to


The asynchronocity of the interaction also means that UNDO becomes even more

important, since no immediate feedback is available.

Requested interaction is a unique advantage of email compared to web based

interfaces, but not limited to requesting action through email interfaces: requests

can be sent use a web interface as well.

Speed of the email interface is mainly accomplished by not having to leave

your email program: starting up a browser and connecting to a website can take

up to 15 seconds, a time delay in which the task might already have been completed

using an email interface. The time gains are small, but add up for often repeated


Input and Output in Email Interfaces

The main consideration to make once you've decided to use an email interface

is how to deal with input and output, commands and feedback. Here's what we

have to play with when building an email interface:

  • The email address

    Addresses can contain information, like

  • Additional headers

    You can make up headers with email, but you can't

    easily edit these headers in most email programs.

  • The body of the text.

    Which can be text only or HTML

  • Attachments.


    email Fax interface (screenshot)

    for example treats any attachment as a document to be faxed by the service.

These technical constraints limit the things we can do with email. Given these

constraints, and looking around on the web, here are the three basic styles

of email interface interaction:

  1. Command line style

    The subject and body of the email contain text

    commands like "subscribe" or "start-content".

    Command line style interaction requires the user to learn to use certain

    commands, and introduces possible errors: commands can be misspelled, wrong

    commands can be given. Command line style interfaces are emailed back to the

    server, allowing for asynchronous interaction. Because of their learning

    curve, command line style email interfaces are useful mainly for power users.

    A special case of command line interaction is when the user is requested to

    reply to an email that already contains the relevant commands - mailing list

    software often uses this to confirm subscriptions.

  2. Link based style

    The email contains links like "Delete this

    entry:" that can execute commands.

    Link based style interaction is easy (just click the link) and error

    free, but requires the user to be online while using it, thus loosing one of

    the key benefits of email interfaces: asynchronicity. They retain the speed

    advantage, which is why these are also widely used for simple interactions like

    subscribing or unsubscribing.

  3. HTML based style

    HTML forms, posted to a webpage. Browser opens

    after posting.

    HTML based style interaction allows for a rich interaction environment,

    providing all the HTML widgets (dropdowns, checkboxes, ...) people are used

    to using. However, it requires people to be online, thus again loosing a main

    advantage of email interfaces, and it still retains all of the disadvantages

    of email interaction.


Could an HTML form that is sent to someone be replied to,

keeping the form intact? The form is filled in and emailed (not POSTed)

to the server.

Would it be possible to make the form values be transmitted

to the server via a reply-to? This would provide the rich interaction possibilities

of HTML and yet allow for asynchronous interaction at the same time.


There are a few conventions that have already evolved for email interfaces:

  • Explain the user where the email comes from and what to do next if they

    aren't used to the interaction. A good example is the "This is an automatic

    email, no reply is necessary".
  • Have subject lines that are easily filterable, preferably contained within

    square brackets. Having a subject line include something like [feedback]

    makes it easier for people to manage their incoming email.
  • Avoid too many email being sent, rather compile them into one big email

    if possible. Nobody likes receiving heaps of email.

Examples of Email Interfaces

Jeff Lash offers some more examples:

Long ago it used to be common for people to provide information via

auto responders "For our price list, send an email to".

It was used for situations where they didn't want to provide data online for

all to see but wanted it to be available to people who wanted it. Just last

week I saw a personal site that had a "Want my resume? Send an email to" link, but I forget the name of the person/site. [...]

Microsoft Outlook lets you send invitations and questions through email.

At work we use the Approve/Deny a lot for any changes to the IT infrastructure.

I send out a request to people who need to approve it, and they just click the

appropriate button in the email. You can do voting and create custom buttons,

and whoever sends the email out can track responses. Of course this is a MS

extension to email.


Email interfaces can be powerful tools that support repetitive one step tasks,

and offer some unique productivity advantages for people with limited time and

Internet connectivity.

The design of email interfaces has typically been left to developers with little

time and resources to spend on this. It is high time the interaction design

community took up the unglamorous task of designing quality email interactions.

Article history: This article originally appeared on

[1] Of course, not all email interfaces have this property. Asynchronous interaction

is possible with websites as well, but in practice it's too scary to fill in

a form while not connected. Unique ids time out, the server gets confused,

and too often you get an error message when connecting back and submitting the

form, which means you can start from scratch.

Peter Van Dijck is an Information Architect with an interest in localization, accessibility, content management systems and metadata.
  • Weblog
  • Portfolio
  • Accessibility and localization
  • The access keys for this page are: ALT (Control on a Mac) plus: is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.