Body copy

The main copy is for those readers who want to know more — those who haven't lost interest, and those that haven't clicked the initial call-to-action already. The person who gets this far likely wants detail and reassurance. Since we have a fair amount of detail here, this is often the place to use bullets with bold headings so that it can be taken in by readers who are scanning. The main copy should therefore include:

• a detailed description of the offer features. If the offer is for a holiday, what is on offer? If the offer is for a seminar, what are the topics and what is the track-record of the speakers?

• a detailed description of the offer benefits. In the case of the seminar, what benefits will those attending the seminar receive? You can combine features and benefits by adding 'which means that ...' after each feature.

• clear instructions about what to do next to receive the offer
• a description of how the process for fulfilling the offer works.

As in a direct mail piece, the main body of the e-mail typically details the features and benefits of the offer in order to encourage a response. With e-mail, you shouldn't use too much detail — the best place for detail is arguably the web site, and you can encourage clickthrough to find out more. A common approach is to use a bulleted list in the main body to describe features and benefits. Some e-mails seem to take this too far, though, with the e-mail becoming little more than a series of such lists. Although most would agree that 'brief is best' when it comes to e-mail, we do need to make the body copy long enough to create engagement, set the tone and explain the offer — and bullets alone are often not the best way to do this.

The body should also Explain and Instruct. It should explain because you may have developed a great offer and method of redemption, but it may be too complex for the embattled e-mail recipient as they wade through hundreds of e-mails. Explain clearly how the offer works. Instruct is related to Explain — most of us seem conditioned to follow instructions, as they make our lives easier — so the main body copy can instruct the recipient what to do next to receive the offer.

The close

The main aim of the final part of the text should be to achieve action, so the close should always include a link to execute the action. The section on achieving the call-to-action (see below) explains the best form for this. The reader will often have had to scroll down to get to this point, and it may be worth briefly repeating what has been said so far — in particular, the offer.

Sign-off

The sign-off can be personal or impersonal. Personal — from a named person — is best if the recipient knows an individual in your organization, such as an account manager or a customer service representative. Alternatively, if the company has a well-known figurehead the e-mail could be from this person, but many may think that this is false familiarity unless the copy is written to avoid this. An impersonal sign-off is often more appropriate for rented lists.

The postscript

The postscript is a device, often used in direct mail, which is known to capture attention and will encourage action. The PS is not seen that often in e-mails, perhaps because e-mail is seen as more of a conversational communication and the PS adds an element of formality, or perhaps because it is too overt a sign of selling. My view is that it can be used to good effect, since our eyes are drawn to the PS — so it is a good mechanism for getting a key message across to the reader.

Mandatory inclusions

These are what must be included to be legally compliant. Currently, this implies an unsubscribe mechanism, a privacy statement and a contact point (name and company address) that the recipient can contact if required. It is also good practice to include a 'statement of origination' - a short piece of text explaining why the recipient has received the e-mail — because some recipients may have forgotten signing up to your e-communications and will consider your e-mail to be spam unless you include this.

The unsubscribe is simply an instruction. It should be reasonably prominent and straightforward if you believe in permission marketing. The instruction will usually take the form of typing Unsubscribe into the subject line of the reply, or clicking on a link. You don't have to be formal here; Kangol uses this 'cool' approach for the unsubscribe to their newsletter:

PS think your life is so complete you don't need to hear from us again? Click here and kiss the cool times goodbye.

A privacy statement or link must be included, but since it is not desirable to have a full privacy statement in the e-mail body, this is usually a link back to the privacy statement on the web site. Related to the privacy statement is the 'statement of origination', which explains who has sent the e-mail and why.

To wrap up this section on structure, let's look at an example that puts it all together. It is kept succinct, and has a clear headline and header image plus a clear call-to-action at the beginning. It then uses bullets and panels to indicate other stories. The only thing it is really missing is a close, which would help make it more personal.

Communication with Coders

In contrast to the wireframe being overly defined for the clients when discussing overall structure of the site in Project A, we found that compositional elements of pages were not defined in sufficient detail to communicate with the software development team responsible for implementation. The development teams' approach was to identify logical units within each page so that common software classes and routines could be identified early on. This entailed marking up the prototypes with regions regarded as logical units, and numbering them. Clearly this added another level of detail to the wireframe which we had not initially envisioned when designing it. Since the wireframe was developed in HTML using layers it was not technically possible to annotate the prototype itself, so paper copies of the pages were used and marked up. As development progressed, and the prototype was refined due to client requests and an improved understanding of the user requirements, it became increasingly difficult to maintain a link between the regions marked on the paper copies and the evolving prototype.

Given the lack of fidelity in the prototype required by the software coders, use cases were written to specify the user-system interaction in more detail. Use cases are a software development representation that describes the "dialogue" between a user and system in a task context. For example, in the task context of "Write an e-mail", the dialogue could be: (1) The user creates a new message; (2) The system displays an empty message window; (3) The user gets a recipient from the address book; (4) The system checks the validity of the address, and so on. These use cases were specified by use-case writers and then taken by a test team who developed test plans to better support the implementation effort. These additional specifications referred directly to particular parts of the wireframe — for example, the use cases detailed particular user-system interactions, while the test plans relied on both the wireframes and use cases. Maintaining the consistency between these multiple representations became more difficult as more and more people came to rely on the wireframe.

In terms of our dimensions, our prototype did not allow for sufficient detail in its description when the target audience was the software development team. Moreover, the unchanging paper copies became further out of synch with the evolving prototype as development progressed thus imposing an overhead on the communication between the HCI and development teams. Essentially the development team needed a view of the prototype that was at a greater level of detail than our own.

The same problem occurred again in Project B where the prototype was used as a means of communication between the HCI team and the software coders. As in Project A the prototype was not detailed enough to meet the needs of the coders. Therefore we adopted use cases to further detail the requirements on the functionality. Initially HCI was responsible for specifying the use cases. However, at a later stage the system developers took on this responsibility to make sure the use cases were detailed enough to support them in their work. The use cases together with the wire frame were used to drive the development process and to identify issues that needed to be resolved.

Sub Category and Product Detail Pages of Six Functional Parts

Online stores use the following six basic component webpages in their store design:

• Home page
• Category pages
• Sub-category pages
• Product detail pages
• Informational content pages
• Checkout page

Sub-category Pages—"The Shelf"

Because most online stores carry hundreds or thousands of products, it is important to break up the information into manageable chunks. Products are displayed on a shelf—whether it is physical shelving in a brick-and-mortar store, a catalog page, a TV infomercial, or an e-commerce website product page. The product shelf is any web page on which a product is merchandised and sold. It can be a category page featuring many products, or it can be a specific product page with a single product.

In this example, there are many varieties of all-in-one printers. The subcategory page helps to narrow down the offering. A thorough understanding of customer needs is necessary to structure these pages. Depending on product complexities, informational content can provide customers with "why to buy" information that helps them select the right product to meet their needs. Emerging online tools—such as the shopping wizard—can help narrow choices.

Product Detail Pages—"The Package or SKU"

Because customers can't pick up virtual merchandise and read labels, the product detail page represents the product or behaves like the product package. It must clearly communicate what the product is and what the customer will receive as a result of its purchase. Anytime a page offers a product for sale, it must provide the following information for each of the products offered:

• What it is—the description, picture, uses
• Relevant and complete compatibility, sizing, color, or other information
• What's contained in the package—what the customer will receive
• Other items needed for immediate operation (batteries, cables, assembly, UL specifications)
• Spare or complementary items (extra batteries, film, or a carrying case)
• "Care and feeding" of the product (special polish, cleaning instructions)
• The price and any hidden charges (extra shipping or handling)
• The manufacturer's or designer's name
• Sample content (for example, sample book pages)

The customer must know clearly what the product is and what it looks like. And for customers who know exactly what they are looking for, accurate descriptions and specific product numbers or models must be included so they may easily recognize the correct product. Our research across more than 25 major elcommerce websites identified incomplete or inadequate information. In many cases, the web stores did not provide complete compatibility information.

Shoppers will not purchase from a site that cannot confirm their choice or be specific about what the product is that they are purchasing.

Product detail pages let customers know what they're getting and what else they may need or want. In this example, product features—the "speeds and feeds"—are listed. This includes products they may need to purchase in order to use the product. It also features other products the customer may want. Good clothing stores recommend coordinated accessories to give customers ideas to complete ensembles for a variety of social occasions.

The product detail page also needs to let people know how to buy the product. As simple as that sounds, customers who participated in website evaluation research had difficulty adding a product to the shopping cart. This function varies from website to website. Button labels can also vary. Some say "add to cart," "buy," or "add." The buttons also have different locations on these sites. Some are next to the products and some are far enough away to disassociate them from the product.

Also, some websites force customers to go to the shopping cart or checkout page every time they add an item to the shopping cart. This then forces them to start over or go back and forth if they are shopping for multiple items. It adds an unnecessary extra step.

Make it easy for the customer to know what they're getting and how to get it. Customers will leave tedious websites.