Page History

...

Design

The overall design of our interface (as shown in screenshots below) was meant to be a clean, simple application for an enterprise audience. We spent a great deal of time researching enterprise design patterns, and found that using grays and one highlighting color (red in our case) made for a professional looking application. High level navigation between interfaces was done using a horizontal tab system, familiar to many corporate sites. Each tab is generally self-contained in terms of functionality, however the underlying database on trips is shared across tabs. As the user navigated, we wanted to maintain state in each tab independently because some users may be using multiple interfaces at once (i.e. a manager who is approving trips for subordinates while planning a trip themselves).

...

During user evaluation, we were primarily interested in the user's reactions during the test, and we were looking for critical incidents.

Reflection

Overall, our team was happy with the results of our project. It did not change a lot from the initial planning stages.

GR1 - Project Proposal and Analysis

We think that this part of the design process was probably the most critical to our eventual success. Factors that worked well for us were:

• Task Analysis: Limiting the scope of the project so that we could accomplish what we needed to do in three months.
• User Analysis: spending a lot of time finding real representative samples of our user population to interview in depth. This really set the design criteria and guided decisions for the rest of the project. We referred back to the notes gathered from the interviews quite a bit over the following months.

Parts that probably could have been done better:

• Domain Analysis: We could have done a better job thinking about multiplicities. For instance, we missed the entity "legs of journey" which would have maybe caused us to devote a little more room to this in the final design.

GR2 - Designs

We split up and each group member came in with two options for each task. That way, we had a total of 6 designs for each task. The design meeting was thus spent discussing the pros and cons of each design. In the end, the final design that emerged from this process was a blend of designs that incorporated aspects from all three people. In general, one design "won" for each task, but we found that small embellishments were blended in from other designs for support.

GR3 - Paper Prototyping

This step was critical in improving the usability of our interface. In particular, the Create Trip and Analyze Trip interfaces underwent major redesigns as a result of this process and became a lot more efficient, learnable, and visually appealing. We had some difficulties in terms of the process of the user test itself - we found that our briefing was far too detailed to get really good feedback from users. In the end, we found that the briefing/task list should be a balance between guidance and freedom, and that a bad briefing/task list could severely compromise the effectiveness of the test.

GR4 - Computer Prototyping

During our computer prototyping some things went well and others eventually caused the project to suffer.

Things that went well were:

• Focusing a lot on the colors, fonts, and general layout. This ended up creating an appealing, generally learnable interface for people to use.
• Focusing on navigation and visibility of mode and state. 

Things that caused headaches:

• Not researching the usability of the Google Calendar and Maps API at all because we weren't focused on the back-end. This led to implementation problems.
• Lack of sufficient attention to multiplicities. This caused our interface to feel shallow and unresponsive to extreme, but still reasonable, conditions (such as 10 legs in a driving trip).

GR5 - Implementation

In the end, we incorporated most of the "major" design flaws exposed during the heuristic evaluation. We did find some irrational attachment to the design in the group after the initial prototype stage, especially to the one-line interface in Create Trip.

We never got to the map and calendar portion of Create Trip, in either the prototype stage or implemeentation which probably would have revealed a whole new set of usability problems. In essence, by putting out an incomplete prototype, we were unable to get feedback on all the "moving parts" of our interface. We can easily see this being a tension during an iterative design process, where some aspects are tested when they are half-baked and you just hope that you don't have to scrap the whole design if feedback comes back negative.

We could have done better in terms of version control amongst group members, but this was somewhat mitigated by our modular design. Each member essentially handled one tab. Overall design decisions were made easier by our early focus on the user interviews.

GR6 - User Testing

The "final" user testing was somewhat difficult due to the fact that the interface was not completely implemented according to our original design. However, we did find that giving the application to "real" people to use revealed flaws that were not discovered during heuristic evaluation of experts (for instance the usability of the slider). On the other hand, we learned from our paper prototyping how to better brief the users, which led to better feedback.

Summary

Overall, we found the iterative design process to be very useful and effective. Involving the user at the very beginning was extremely helpful. The paper prototyping was also a great tool - we would not have been able to redesign the interface to the extent that we did had we jumped straight into coding. We found tension between the computer "prototyping" and "implementation". Inevitably, those elements that are left shallow in the prototype stage are the ones that typically have usability problems in the end. At the same time, spending too much time on certain aspects of the prototype led to reluctance to change. If we were managing a group developing applications in the future, that would be the area we would focus on in terms of project leadership.