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.

Develop a Highly Usable VR System - and Do It Yesterday!"

The project had identified a number of key areas which needed specialist attention. These were to:

• Produce a definitive statement of requirements on the DISCOVER system from the training organization. This involved understanding the methods used in current training, which ranged from state-of-the-art physical simulators costing tens of millions of pounds, to simple role playing, and their methods of assessment.
• Adopt a suitable pedagogic model for the training environment.
• Understand how we were to validate the DISCOVER system with the appropriate validating bodies. The project had ambitions to sell the system across the world to a number of shipping and oil companies and thus required a suitable seal of approval.
• Produce for the software designers a detailed description of the virtual environments to be modelled and a list of the objects and their behaviours therein.
• Specify a collaborative virtual environment with a strong emphasis on fidelity and usability.

Match the system to current and proposed training scenarios. And we had three months to complete this in the first instance!

Phase 1: Just What Should a VirtualTraining System Do?

Some requirements work had been carried out before our entry to the project, but this had simply taken the form of the collection of high level statements of intent from the training companies and lists of competencies (or skills) to be trained. This provided our first political advantage: working closely with managers and training personnel in the user companies in itself convinced these project partners that their needs were being seriously considered. Thus our activities tended to be viewed in a constructive and receptive way. We will not provide a detailed description of the techniques we used, since they are familiar ones, but we employed a combination of interviews with trainees, trainers, their managers, observation and video- recording of training sessions and the collection of relevant documentation. All this took place at user sites. Again, goodwill was generated simply by the amount of effort very clearly being devoted to the user-centred work.

The results of this fieldwork fed into a large group of requirements relating to the way in which CVE based training could best be used in its particular intended context. Fortunately, although CVE design is a young field, there isan emerging body of literature which addresses generic usability issues for single users (e.g. Stanney et al., 1998; Sutcliffe et al., 2000) and in the collaborative context, the guidelines provided by the COVEN project (Normand et al., 1999). Thus we were able to supplement our own primary findings with secondary material from the literature and produce a large body of user-related requirements material in a relatively short time.

The Use of the MoSCoW Method

At this stage we had a large set of requirements in clear need of prioritization. In keeping with the user-centred philosophy which we had started to foster, this would be done in conjunction with the user companies. The MoSCoW technique from the Dynamic Systems Development Method - DSDM, (Stapleton, 1997) afforded a means of doing this which would be readily understandable to users and familiar to the developer partners in the project. DSDM prioritizes requirements using the MoSCoW rules.

The uppercase letters of the acronym (the o's are only there to make for a memorable acronym) stand for: Must have for requirements that are fundamental o the system. Without them the system will be unworkable and useless. The Must have category defines the minimum usable subset. Should have for important requirements for which there is a work-around in the short term but the system will be useful and usable without them. Could have for requirements that can more easily be left out of the current development. Want to have but won't have this time round for those valuable requirements that can wait till later development takes place. A small sample of the prioritised requirements follows below A substantial subset of the higher priority lists related to usability and other non-functional concerns.

• lMust: The ability for trainers to increase stress in a safe, controlled manner for the trainees.
• Should: Provide a more satisfying professional role for trainers than classroom teaching.
• Could:Courses formally validated by the appropriate standards bodies.
• Want：Measures of trainingtransfer.

By now, therefore, we had an substantial body of organized and prioritized requirements which formed the main body of the requirements and evaluation deliverables to the funding body. These reports passed their review, user-related concerns were accepted as the main force driving the design of the software and the project moved forward.