Initial Design 1

The first version of this initial design sketch is based on the concept of slimming down and minimizing the number of clicks and screens a user has to go through to accomplish the goal of sending out a personalized mass mailing. (See Figure 1)

The key four steps seen as being necessary to complete this goal were seen as writing or selecting the document, personalizing the document, previewing the document and editing individual documents, and finally, printing the document. This could be done by having a main screen with each of these four tasks labeled on it. Clicking on any one of the tasks would allow for doing that task. In theory, the steps could be performed out of order, thus allowing for greater user mobility within the application. However, a natural order (the respective listing of tasks as above) would be implied.

For a given interaction, the user could click on each of the tasks and move through the screens (just 4 other than the main one) in the natural order. So, the user would first select the first option, then would write or select a document on one screen, click a button to move on, personalize some content on the next screen, click another button to go forward, preview and edit any individual documents on another screen, click another button to go ahead, and ultimately be presented with a print dialog. This eliminates unnecessary steps that some of the implementations have and also creates a constant interface for the user to get comfortable with.

After sitting back and evaluating this design, a more elegant solution presented itself. (See Figure 2) To continue with the themes of simplicity, slimming down, and constancy, the whole architecture of the first design was further reduced and integrated into a word processing environment, rather than being a separate entity or program. When already in the context of word processing (where things like saving, printing, and writing are taken for granted) only two features really need be apparent: personalizing, and previewing/editing individual documents. Incorporating these two tasks as buttons with optional explanations greatly enhances the simplicity of the design, and frees up a lot of screen real estate. Not using a wizard gives the user a constant interface, and one that should be fairly self-explanatory. This is a large step towards just integrating mail merge functions into the task bar of a word processor itself.

Admittedly, neither of these designs addresses the back end or prepratory data gathering step that is most associated with performing a mail merge, nor do they explain exactly how a personalization or individual edit should be done. However, those aspects were not the focus of this design. Rather, it centers on the user interaction with the basic menu or navigation of going through the process of a mail merge, hopes to make that design solution more elegant, and acknowledges that the details of the tasks can be worked out later, in a more refined design that incorporates different views and optimizations.