...
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).
...
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.