Design Evolution
Initial Sketches
Our team decided to have each member design an interface that would best accomplish a mail merge. Each member had also conducted a comparative analysis on an existing implementation of mail merge. When we regrouped, our individual designs generally reflected the best practices of the implementation we analyzed, but they also combined the user's concept model of the interaction. The most important idea from this phase was to keep the merge in Word with a drastically redesigned sidebar.
Paper Prototype
We initially planned to create two paper prototypes in order to figure out which would be best to pursue in the interactive prototypes. However, fleshing out the design of the first one took long enough that we decided to concentrate on the depth of a single design rather than broadly covering two designs. During this phase, we came up with the concept of a data collection, which is one of our major changes to the way mail merge is done currently. Although we later discovered how intimidating this screen was, we worked hard to try to make it intuitive to users and to give the power user (Violet) enough flexibility to make her mail merges much easier.
This phase is also where we came up with the structure of the sidebar, which changed little throughout the project. Generally, users would prepare the data, write the letter, insert the fields, preview & edit, and finally print their merge. We modeled our sidebar to give a top-to-bottom flow of this most common interaction, but we also tried hard to allow users to skip around to do the tasks in the order that makes the most sense to them.
When interviewing with this prototype, we also learned that the power user could benefit if inserting conditional fields were intuitive. We designed an appropriate interaction for this that ended up being well-received by the users all the way through to our final prototype.
First Interactive Prototype
Most of the changes that we needed to make after testing our paper prototype involved the data collection screen. The user saw our Excel-like grid and logically assumed Excel-like functionality for that grid, which we did not plan to implement. Thus, we decided to have our grid look different by making it more colorful, however, this change was not implemented in this phase's version of the prototype. We had only included an undo and redo button, but after testing, we decided that other barebones-functions were necessary: cut, copy, paste, remove field, and remove record were all added . The goal was that the user could rearrange data here in the way that made the most sense for the mail merge without actually modifying the parent database. We also got rid of the "Remove Current" button under "Associated Documents" since it was redundant with the other remove button in place. As a compromise, the current document would be the default selection in the list box.
Aside from the changes in the data page, we changed the main interface. We added under the "Data Collection" section in the sidebar a "Type of Merge" section with buttons for choosing the type of merge : a letter, an email, labels, or envelopes, with the default as letter. We also exchanged the "Preview and Edit" and "Document Output Sorted by" rows in the output section because this made more sense after interviewing. Additionally, for linking multiple databases, we included lines between fields that are being linked, as in Microsoft Access, with which many users are already familiar.
Heuristic Evaluation
Much of our first interactive prototype was non-functional because of the scale of our project; unfortunately, our team's heuristic evaluation suffered as a result. We did, however, discover that much of our terminology was confusing. In fact, coming up with the right words has been a challenge throughout our project. It has been especially difficult to balance the vocabulary of someone unfamiliar with mail merge with the vocabulary of someone in our user group. Since we are designing for the power user, we figured that a new user would "catch on" after playing with the interface.
Final Prototype
The most important change with our final prototype was with the data collection screen. After interviewing with our previous prototype, we found that each user had a problem figuring out what to do on this screen. Thus, we were able to move the entire top half into other areas of the prototype where they made more sense. This allowed the user to concentrate on a single idea with this screen, rather than being overwhelmed with two entirely new concepts plus the area for adding a database to the data collection, which is the primary use of the screen. More information about the final prototype can be found here.
Most Useful Evaluation Technique
Without question, the paper prototype stage benefitted our team the most. Mocking up a paper window takes much less time than coding one up. This speed at which we could inplement our new ideas helped us quickly determine which ones were the best to carry forward into the more time-intensive prototyping. We were also able to alter it between interviews to account for problems we did not forsee. In summary, the paper prototyping phase was where we carried out the most design work.