Design Project Summary
Okay, let’s try this again.
The design project is over, the presentations have been given and the prototype has been bastardized. I was going to post daily summaries of the design project, but upon reconsideration, I have much better things to do with my time and I’m sure you do as well. So instead of daily summaries, I’m going to summarize it all in one go, using my group’s design summary as a basis for discussion. There’s going to be some repeats from the day one summary, but for the readers’ sake I thought it best to have it all in one place. Before I get started, I would like to acknowledge the rest of my team: Sarah Brierley, Sarah Parker and Amrita Lall. Thanks for all your ideas, hard work and laughs over those two weeks.
Research
We needed to understand the aspects of the system in order to analyze existing tasks and identify user needs. We gained this understanding through researching home bars on the web, researching liquor requirements in bar and cocktail manuals, interviews with bars located near hotels (we didn’t have any target users immediately available), and email/telephone interviews with friends who would be in the target market for our home bar system.
Following our user research, we wanted to have a preliminary idea of the different concepts that should be included in the interface in order to guide our design discussions. To accomplish this, we mapped the user concepts that need to be included in the interface through whiteboard and paper drawings.
Finally, we needed a representation of the users and their scenarios in order to guide our future design work. Specifically, we needed to understand the real user motivations and goals for a home bar system. We created personas and scenarios for four key types of users: the party animal, the married couple, the upper crust and the urban socialite.
Task Analysis & Screen Specifications
We began our task analysis to define primary tasks for input to the design stage, helping to ensure that the interface design is derived from user tasks. Our aim was to define the most common tasks across all four of our personas. We used the scenarios written for our respective personas to find the generic tasks and a few other common tasks. Each of these tasks was then fleshed out by using an operational sequence diagram.
Next, we had to decide how users will navigate the system. This provided a framework for defining how the prototype interface may look. The main tasks we previously defined (search, orders, events) were used to describe a framework for interface design and functionality. As part of this process, we used some common tasks and a few edge cases to test our decisions.
We struggled with understanding what constitutes a functional specification over and above our OSDs and Task Analysis. Eventually, we decided that we should strive to understand the entities that we needed to represent in the interface and start to define how the user would navigate through the tasks defined in our task analysis. This was accomplished by creating an Entity Relationship Diagram of our system.
In order to define the input/output levels performed by either the user or the system, we first had to define to requirements for each screen. Illustrating a rough visual representation as to how the screens would look formed the basis of our development of the input/output levels for each screen. We wanted to show how each of the components inter-relates and how the interaction styles work. The ERD formed the basis for this, but only on a low level. High level was achieved by defining and specifying the interactions styles such as navigation, search/browse, how user places an order, etc.
Finally, we realised that some of the navigational features/elements that had been defined during the previous day would need to be altered, as we encountered problems with the existing form.
Prototyping
We began designing the specified screens in PowerPoint based on the whiteboard drawings. We revised the global navigation of our design, replacing “home,” “back” and “forward” with “drink,” “event” “order” and “set-up” buttons which link to all the options in the top level of the navigation hierarchy. This allowed users to get to each of these sections from all screens. The main trade-off is that some links on low level screens took users into another main section of the application, which could be slightly confusing depending on the context.
We printed all the screens currently designed, laid them out, and reviewed them by walking through key scenarios. Next, we checked consistency and navigation links. We fixed several real-estate and layout issues. We also removed the “add to order” screen as we decided it was so similar to the order screen and was unnecessary overcomplicated. The screen designs were iterated and printed.
Testing & Evaluation
The new printed screen designs of the paper prototype were then used in two pilot tests. One with a team member to practice facilitating and to check all test tasks and screens available worked together. A number of initial findings were fed back into the screen design and test designs.
The screens designs were debugged further, incorporating the findings from the pilot tests. Changes and justifications were noted on the slides. The screens were now ready for coding over the weekend. Test scripts were formalised, reviewed and iterated. By the next week, we planned to conduct formal user trials of a working prototype.
The following Monday, Amrita and Sarah Parker tested the system with three different participants, all members of our class. Amrita took notes while Sarah Parker facilitated the test. We received a lot of really fantastic feedback during testing that completly changed the way we thought about the design of the Bar Manager system.
Design Iterations
After summarizing the usability issues that arose during testing, we realized that our system had major navigation problems that we had to resolve. This led us to brainstorm for alternatives to the current Bar Manager navigation. One idea that had been mentioned previously during user testing was basing the navigation around user tasks (“I want to make a drink,” “I want to know what I have”). We all agreed that this would likely improve the usability of the system. So we began to list and prioritize the key user tasks involved.
These user tasks formed the basis for our new navigation and site map, which Sarah Brierley produced. We continued work on the new design which evolved over the next several days.
It was a crazy two weeks, but after it all, I think we were satisfied with our final design. The biggest problem we encountered during the design was navigation. The functionality was there, but getting around our first design - actually using the system - proved to be a bitch. From my perspective, the main reasons for this were lack of user research and generally poor task analysis. We could have done more of these if we actually had real users and more time, but we had neither. So we did what we could and made the most of what we had. And really, isn’t that what design is all about?
- 8 Apr 04
- interaction design, ms hci, process, project
