Word's Mail Merge

Problem Description

I've spent a lot of time trying to teach people to use the Mail Merge feature in Microsoft Word, and they inevitably get confused during the process.

Common problems include:

HCI Analysis

While the mail merge process is fairly straightforward (it is essentially a "knowledge" task in Bloom's (1956) taxonomy), in Word it is littered with extraneous detail. When a user selects "Mail Merge" from the menu system, they are faced with the following dialog box:

Since the only option available is to create a main document, (and the dialog box tells the user to click the Create button), the user clicks the "Create" button, which gives a choice of creating form letters, printing envelopes, or creating a catalog. If the user intends to create a form letter, they next see this dialog box:

The "Active Window" button should be pressed at this point, since it is extremely rare for a user to begin work on one document while deciding to create a form letter out of another (blank) document.

The above two steps were things the computer should have known how to do, by following Cooper's (1995) principle of "Do, don't ask." Bothering the user to do them decreases efficiency and adds to the perceived complexity of the task.

Next, the user must select a source for the data that will be merged into the main document:

If the user selects "Create Data Source...", they are faced with a dialog box for saving a file, but not told what file they are saving. The process ignores the principle asserted by Cooper (1995) that "Disks and files make users crazy." The designer's intention is that the user provide a filename for the new data source being created, but the system provides no explanation of this. This violates Suchman's (1989) assertion that systems should be self-explanatory.

After creating the data source, Word simply erases the dialog box, and takes the user back to the main document with no clear indication of what to do. Once again, Suchman (1989) has been ignored. If the user has a good memory (or a helpful instructor), they will notice that their main document now contains an extra toolbar with buttons for placing merge fields into the document. The toolbar is difficult to see if the user isn't expecting it, due to Word's already cluttered interface. Norman (1988) argues that a good interface should allow users to quickly see all possible actions.

When the user has finished placing merge fields in the document, it is necessary to return to the Mail Merge dialog box (using the menu system or an inconspicuous button on the toolbar) to actually complete the merge, as shown below. Another of Cooper's (1995) principles has been violated here: "Build function controls into the window where they are used."

Withing Microsoft Office, the suite of programs that contains Word, it is standard to use a "Wizard" to step the user through any complex process. While Wizards typically have their own design flaws, they are a standard that users become accustomed to. The Mail Merge process breaks with this standard and uses a modal dialog box that the user must return to throughout the course of the process. Breaking with the standard violates Apple's (1992) principle of consistency.

Recommendation

Changing the Mail Merge dialog box into a Wizard would alleviate the users' feelings of being lost. More explanation needs to be given at some steps, particularly when choosing a filename for a new data source.

At many steps in the process, it is simple for the program to determine what the user wants. When the user is working on a document with paper size 8 1/2" by 11", they aren't going to use mail merge to create envelopes. Telling the user to press a button is just silly. When the program knows that a particular selection should be made or button should be pressed, it should do that step automatically.

Outside the dialog box, users would be helped by highlighting the changes that are made to Word's interface. This could be done by making the new items a slightly lighter shade, so that they are more visible.

References

Apple Computer (1992) Macintosh Human Interface Guidlines. Addison Wesley. [Chapter 1]

Bloom, B. and Krathwohl, D. (1956). Taxonomy of Educational Objectives: The Classification of Educational Goals, by a committee of college and university examiners, Handbook I: Cognitive Domain. New York: Longmans, Green.

Cooper, A. (1995) About Face: The Essentials of User Interface Design. IDG Books Worldwide.

Norman, D. (1988) The Psychology of Everyday Things. New York: Basic Books [Chapter 2]

Suchman, L. (1989) Plans and Situated Actions. New York: Cambridge University Press. [Chapter 2]


rscherle@cs.indiana.edu
Last modified: Fri Mar 26 13:05:52 EST 1999