We initially came up with an interaction flow that was focused on a sequential, step-by-step flow through the decision process of customizing a guide. The flow could be truncated, allowing the user to skip detailed editing as needed.

While this approach has was valuable for personas who need the ability to edit content in detail, it was less than ideal for the business traveler, who is concerned with the length of time spent customizing a guide. To minimize the number of steps this user would have to take, we came up with a different interaction flow, in which the TraveLite system would make a "first cut" of the content based on the specified preferences of the user. This way, s/he could opt-out of the detailed refinements if s/he so chose. Furthermore, these preferences could be saved as "profiles" and applied later, speeding the guide building process in the future. To view these initial design sketches, please visit our IS213 writeup.

Some design issues we faced include:

• constraining the questions used to create profiles to be sufficiently generic to apply across destinations, while still being helpful in making a cut of the content;
• deciding which style of interactions is appropriate for the various attributes, and fitting in multiple attributes wihtout overloading the user;
• determining whether people are likely to puchase more than one guide at a time, which requires a full shopping cart feature;
• whether to allow people to purchase guides and postpone downoad to later, possibly through an email link to the download, or making it available from the "My Guides" page

Testing

The first TraveLite prototype was constructed in paper. We wanted to evaluate this low-fidelity paper-based version prior to implementing a prototype in HTML. We tested the interface using three representative users. Testing was relatively informal, using a think-aloud protocol. The intent of this stage of the design process was (1) to locate major problems with the interaction flow, nomenclature, and structure of the content as it was presented and (2) to see if users generally "got" TraveLite.

The initial paper prototype was first piloted with an outside tester, as well as "tested" by the team members using the draft scenarios, and then iterated a second time in paper. As a result of these pilot tests, so many changes were necessary that it became easier to mockup the content of the screens on the computer as well, rather than erasing and rewriting by hand. The second complete iteration of the low-fi prototype was generated on the computer, using word processor and spreadsheet applications. The computer-generated content was then cut up and pasted onto the web browser window mockup to produce the various prototype screens of the "computer". See the complete writeup for a complete description of methods.

Results from testing

We divided the results of the first round of testing into five major areas. The first area consists of specific interaction details which can relatively easily be fixed in the next iteration of the system. We refer to these problems as Minor details in our Critical Incident Log. The other four areas point to serious problems in the underlying task flow and required the team to address deeper issues in the system. For this reason, incidents that have been classed as Minor details will be addressed only after the other four areas are addressed in the redesign, simply because the functionality may change so radically that they will not be an issue in the next iteration.

Perhaps the most obvious of the system's problems was a result of organizational ambiguity about what exactly (in terms of a product) TraveLite seeks to offer its customers and how and what exactly it plans to charge for that product. This is a classic usability blunder - to reveal underlying organizational issues with an unclear interface. The problems that were a result of this were classed as Pricing Model problems. To solve these issues, the TraveLite team revisited its needs assessment research and documented a decision about the pricing model behind the system.

The pricing model we decided upon is one where a user buys a guide for a particular price and can then create as many guides as they want from this content. This matches the users conceptual model around current print guides - but adds the ability to recycle the same content in myriad ways and in various formats. The current plan is to allow access to a guide's content for one year, though this time period can change as the pricing model develops. This new pricing model more closely matches the goals of users and makes the entire system much clearer.

The second major theme was that of confusion between all the content that is available for a particular destination and the part of that content that is included in a particular guide. We coded these incidents as Content Context problems. To address this issue, the redesign of TraveLite will have a simpler filtering mechanism that shows all content available and specific guide content in close proximity to one another.

A related theme was confusion about where a user was in the process of creating a guide. We called these issues Process Context problems. To address these issues, we plan to introduce a contextual map showing where the user is in the process of creating a guide.

An overarching theme which, in some respects, affects the entire interface, was that of exposing the user to entirely too much detail at once. All three users felt somewhat overwhelmed by the choices they were making and the level of detail to which they could go to customize their guides. One user did not want to choose content at a low level of detail at all. The other two users appreciated the ability to so closely tailor their content, but thought that the way the interaction was structured was too confusing.

All three users were unconvinced that the Profiles functionality offered enough value to justify the confusion they engendered. So our first solution to this problem is to eliminate entirely the Profiles functionality in the next iteration. It may be added back in a later version if it is requested by users.

The second solution is to rather dramatically limit the functionality regarding filtering content. For instance, users will no longer be able to run disjoint queries over the data to add content to their guides. This functionality will more likely be useful at the local version of the guide (on the user's PDA). We will allow filtering over the most popular metadata (as determined by our card sorting exercises) but users will not be able to refine their searches at the level of granularity provided in the first prototype.

This first evaluation phase revealed major problems with the flow of the system. Because of this, we felt that the next stage of our process should be to redo our task flow and design a new interaction based on what we learned in this phase.