Previous Table of Contents Next


5.1.7. The Result

The mood of the design team after the workshop was a feeling of urgency mixed with weariness regarding the application being developed. We still managed to muster up enough enthusiasm to “publish” the results of the workshop. All material from the workshop was put on a wall in the hallway back at the office. We arranged a walk-through of the user environment diagrams for other developers, relevant management, and knowledgeable customer representatives. We felt it was important to continually communicate the status of the project, and it was an excellent opportunity to get buy-in and reactions from managers before the design. It was also important to quickly establish a common view of the outcome of the workshop, which could serve as a baseline for future discussions.

5.2. USER INTERFACE DESIGN

After the conceptual design has been completed and all relevant parts of the system have been structured as focus areas, we begin the prototype design. The structure described in the conceptual model is implementation independent, but during the prototype design we commit the design to the style, features, and limitations of the target platform. During the transformation we work extensively with low-fidelity paper prototypes. The visual design of the user interface is still of little concern. The first priority is to decide how the objects and services of one or several focus areas should be represented as user interface components. The structure and realization of the interface are gradually refined during the prototype design. The work of prototype design is highly iterative. We work our way through the user environment diagram, transforming focus areas into user interface elements.

When the paper prototype is judged to be adequate, the work proceeds by sketching the layout of “screen windows”, using a prototyping tool. Parallel to this work, the structure and contents of the enabling information is outlined in a step-by-step process, using prototypes. We run usability tests on both the paper prototypes and the computer prototypes that are produced later. The prototype design work is completed when the usability requirements have been fulfilled or the planned number of iterations has been reached. The result of this activity is documented in a design specification, of which the prototype is a part.

Usually the design work is organized as a second workshop in a design room, but most of the work on the initial TSS 2000 paper prototype was actually conducted in the hallway outside the room of one of the designers. This approach of taking the work out in the open had several advantages:

  Unlimited workspace. All UEDs and activity graphs were placed on the same wall. The opposite wall was used for alternative screen layouts. It was easy to browse the UED, turn around, and turn the focus area into screen elements.
  High visibility. It was easy to show that we had made progress.
  Instant feedback. It was very easy for outsiders to comment on the work and the data.
  Quick test runs. The structure of the user interface could be verified instantly using the scenarios or the activity graphs.

Posting results in the hallway also proved to have drawbacks. When there was a need for closed discussion, all material had to be moved from the hallway into a conference room. When the meeting was finished, all the material had to be returned to the hallway. After a time the material was simply kept in rolls and piles between meetings.

5.2.1. Opening Screen — Main Window

One of the first and most important tasks of the prototype design is to find an effective way to introduce the users to the system. The main window is usually the first thing the users come in contact with, and it is a window that will continue to be the basis for their work. We basically look at three different aspects when designing the main window of the application:

  Vital tasks — those that are vital for the user to perform well, even under heavy stress. Example: A network supervisor continually monitors the traffic in a network. If something goes wrong (e.g., someone cuts off a cable), it is important that the user be able to asses the situation quickly and reroute the traffic.
  Frequent tasks — those tasks that users spend a majority of their time performing need to be done effectively, and the system should offer alternative ways of performing them. Example: Directory inquiries, or any similar data query application, need to offer good support for the limited number of tasks that the users perform during each call.
  Navigational aid — the users need to understand quickly and easily what the application is capable of doing and how they should go about accomplishing the tasks. Example: Information kiosks, which need to be easy to learn and use without instructions.

It is desirable to design a user interface that supports all these aspects well. In most cases this is not possible, and the characteristics of the users and their work tasks should be used to determine how to optimize the user interface for the most important aspects.

In the main window of TSS 2000, we focused on providing navigational aid by introducing the central concept or metaphor of a “test case”. The system was to be used by several categories of users. All of them had a number of important (but not vital) tasks to perform, and none of the tasks were highly repetitive. With good navigational aid, each category of users would find it easy to find and work with their section of the application. We also wanted to offer good support for the frequently performed tasks, but these tasks were better suited to their own windows, depending on the different categories of users and their work.


Previous Table of Contents Next