Previous Table of Contents Next


2.5. GRADUALLY INCREASING INVESTMENT

This technique is related to the techniques of whitewater, breadth-and-context-first, and low-tech materials. The team designs first at a high level, then tests that high level design. Time, effort, and ego are invested in the next lower level of detail only when the team has reasonably high confidence in the quality of the high-level design. There are many layers of detail, from task flows through task objects to GUI windows. The participants do not invest in the GUI fundamentals or even in the task objects until they have designed and tested the task flows that the GUI will be used to execute. Then they do not invest in designing the GUI until they have designed and tested the task objects that the GUI must represent. Then they do not invest in designing the details of the GUI windows until they have usability tested whether the identities of the windows are good for doing the task flows; why spend time designing the menus for a window when there is a risk that you are going to eliminate that window?

2.6. BREADTH AND CONTEXT FIRST

Both the explicit steps of the methodology and the facilitators encourage participants to understand the context of any issue before making decisions about it, and to work breadth first. These techniques are important for keeping the session on the organized side of chaos and for keeping the session moving rapidly toward its goal. Note that chaos is not quite the same as muddle and that the latter must be avoided at all costs — participants should never be seriously confused. The high speed of the session makes excursions out of scope costly, since the team can get very far into territory that is irrelevant or contrary to the goals of the project. The short time available for the session makes premature work on details dangerous, because that work could consume a substantial part of the session’s time, and could be pointless if later, higher-level work reveals as irrelevant the entire area that was detailed. A more important danger of spending time on details before context, and depth before breadth, is thatthe motivation of the participants could suffer. That danger is especially great in one of these sessions, because of the session’s tenuous organization and high time pressure; participants can easily become disoriented, frustrated, and dispirited. Skilled facilitators are essential for skirting that danger.

2.7. TASK ORIENTATION

The methodology produces a GUI that helps users do their work, instead of one that the users like only in the abstract. The fact that our methodology produces an object-oriented GUI does not mean that the methodology and resulting GUI support the task only tangentially. The focus of the team is exclusively on the tasks for at least the first full day of the session and on the task objects for at least another half day. During most of that initial day and a half, mentions or pictures of any GUI elements (e.g., windows, screens, lists, icons) are prohibited. Only during Part 3 are the GUI objects designed and they are designed to support the users’ tasks. Indeed, the GUI objects are direct representations of the task objects, and the task objects are extracted directly from the task flows. Even when the session finally turns to the details of the GUI per se, the task flows are constantly on the walls for reference and refinement. Vigilance for task relevance is kept by usability testing very frequently, during not only designing of the GUI per se, but also during designing of the task flows and task objects.

2.8. CONSISTENT, OBJECT-ORIENTED GUI STYLE

The last two parts of the three-part methodology — the task objects designing and the GUI designing — are object-oriented (i.e., data-centered). “Object-oriented” means that the GUI reflects the users’ focus on the discrete units of data — data objects — with which they do their tasks. The data objects are based on the users’ desires rather than on the underlying computer system’s organization. In our methodology, those user data objects are called “task objects”, and they are discovered/designed by the users and the rest of the team extracting them from the users’ task flows. The GUI concretely represents each task object as a GUI object — as a window when the object is open, and as an icon, row in a list, graphic element, or other compact representation when the object is closed.

OO GUIs provide a consistent and relatively small set of rules for users to follow in creating, viewing, manipulating, and destroying GUI objects within and across software products. OO GUIs provide a graphical environment that lets users

  visually see the relationships among GUI objects (e.g., the containment of a customer within a hotel is reflected as a “Tom Dayton” row in a list within the “Big Al’s Swank Joint” window);
  change those relationships naturally and directly, by direct manipulation (e.g., move a customer from one room to another by dragging the “Tom Dayton” icon from the “Room 101” window into the “Room 106” window);
  change the way the GUI object’s contents are displayed (e.g., change the “Big Al’s Swank Joint” window’s appearance from a list of customers and rooms to a floor plan of the hotel).

Consistency of GUI style, that is, of rules for the user viewing and manipulating the GUI, is important to users regardless of the GUI’s other style attributes (Dayton, McFarland, and White, 1994; McFarland and Dayton, 1995). Consistency within the single GUI being designed in this Bridge session allows users to do many tasks once they have learned to do any task. Consistency of this GUI with industry-wide style standards allows users to utilize their knowledge of other software products in their use of this product and vice versa. Consistency of GUI style also is important to our methodology, because the participants in our sessions need learn only a small set of GUI style rules for designing and testing the entire GUI.


Previous Table of Contents Next