Previous Table of Contents Next


3. EXPLICIT STEPS

Having described some of the pervasive, easily undervalued parts of The Bridge methodology, we turn to the explicit steps. The Task Object Design step is the center span of the bridge from user needs to GUI, but you can’t have a useful bridge without entrance and exit spans as well.

  Part 1: Expressing User Requirements as Task Flows
  Goal: Translate user needs for the task into requirements that reflect the task flows and that can be input to the next step.
  Activities: Analyzing, documenting, redesigning, and usability testing task flows.
  Output: Scripts of what users will do with the new GUI. The format is an index card for each step, sticky arrows between cards, and those materials taped as flows onto pieces of flip chart paper.
  Part 2: Mapping Task Flows to Task Objects
  Goal: Map the user requirements output by Part 1 into task objects — discrete units of information that users manipulate to do the task — with specified behaviors and containment relations.
  Activities: Task Object Design — discovering, designing, documenting, and usability testing task objects.
  Output: Each task object shown as an index card, with the object attributes, actions, and containments described on attached stickies.
  Part 3: Mapping Task Objects to GUI Objects
  Goal: Design a GUI guaranteed to be usable for executing the task.
  Activities: Designing, documenting, paper prototyping, and usability testing the GUI fundamentals by translating task objects from Part 2 into GUI objects represented by GUI elements such as windows.
  Output: Paper prototype, usability tested for goodness in doing the task flows that were output from Part 1. Includes the fundamentals of the GUI — window definitions and window commands — but not the fine details.

Throughout the following descriptions of the three parts we will illustrate with the coherent example of a GUI for hotel desk clerks to make reservations, check in customers, and check out customers. Do not be confused by the incompleteness of the example as it is described here; this chapter shows only the pieces needed to illustrate key points. Figure 2.1 shows examples of the outputs of the three parts of the methodology; in reality this GUI would have more task flows, more steps in the task flows, more task objects, and more windows. All the figures in this chapter diagram materials that are mostly hand lettered and drawn by the session participants.

3.1. PART 1: EXPRESSING USER REQUIREMENTS AS TASK FLOWS

The goal of Part 1 is to produce an explicit representation of a desirable but feasible way for doing the users’ tasks, to be input to Part 2. The input to Part 1 is the participants’ (especially the users’) knowledge of how users do their work now and of users’ needs and desires. The activities in this step are varied — analyzing, documenting, redesigning, and usability testing. The output is a set of task flows showing each task step as an index card. Removable sticky notes are used as arrows to show the flows among steps. See Figure 2.2 for partial examples of the output task flows for a hotel desk clerk’s work with a hotel GUI. Each card has one noun and one verb, which Part 2 will use by taking each noun as an object and each verb as the action on that object. The task flows never reference computer screens, windows, or other superficial representations of the information that users manipulate to do their jobs. Instead the flows show only the information abstractions behind the representations. For example, if users say they “go to the Customers screen”, the facilitators insist that they write on an index card something more generic such as “view all of the Hotel’s Customers”.


Figure 2.2  Realistic and Desirable task flows output by Part 1. This example is for a hotel desk clerk's work. Each rectangle is an index card, the other items are removable of flip chart paper. The writing and drawing are done with felt-tipped pens by all the participants. A clerk's job using the GUI includes all three tasks — making reservations, checking in customers, and checking out customers.

The pervasive techniques and orientations we described earlier are very important. The task flows are produced by the small team of participants, including users, sitting at the small round table. All the participants create the physical artifacts of the task flows as a natural part of doing the task designing because the index cards, removable notes, and felt-tipped pens are the medium in which the team works. The task flow designing process follows the below steps in strict order only in the sense that no step is started until its predecessor step is completed at least roughly; there are always iterations, clarifications, and modifications. Following are brief descriptions of the steps within Part 1.

3.1.1. BIG PICTURE

The team (including real users, as in every step of every part of The Bridge) puts together a very high-level set of current work flows on a single piece of flip chart paper, using an index card for each step and stickies for arrows between steps. These flows might have only one or two cards to represent the entire job that these users are supposed to do with this GUI. The rest of the flows show the steps that are the triggers to these users’ work and the steps that are done with the output of these users’ work. The scope of this GUI design session is shown on the Big Picture by circling the portion of this high level set of flows that is to be done by these users with this about-to-be-designed GUI. The Big Picture is posted on the wall to act as a scope map for the entire multiday session. If the session drifts to an out-of-scope topic, the corresponding index card’s position outside the scope circle is a public reminder and indisputable evidence that the topic must be abandoned or the scope redefined.

Figure 2.2 does not show a Big Picture, but the format shown there is the same — hand-lettered index cards with hand-drawn sticky arrows. A Big Picture for the hotel desk clerk GUI might include a single index card for each of the three tasks that are the target of this GUI — “Make Reservation”, “Check In”, and “Check Out” — with that set of three cards circled as being in scope. Index cards outside the scope circle might include “List the Rooms Needing Maintenance” and “List the Customers With Outstanding Bills”.


Previous Table of Contents Next