Previous Table of Contents Next


3.1.6. SCOPING THE BLUE SKY TASK FLOWS

Users now mark each Blue Sky step with its desirability (e.g., high, medium, low). The other participants, the developer and system engineer in particular, mark each step with its feasibility (e.g., easy, medium, hard). Then the team draws a circle around the portion of the flow that is in scope for this multiday design session. In fortunate cases the highly desirable steps are also the most feasible, allowing the team to reallocate the project’s resources to yield the most benefit to users. The Blue Sky flows then are posted on the wall for reference.

Desk clerks might be more rushed while checking customers out than while checking them in, so higher priority might be marked on the single “Check Out” step than on the single “Check In” step.

3.1.7. REALISTIC AND DESIRABLE TASK FLOWS

The team now designs task flows that solve some of the problems of the Current flows, that have characteristics of the Blue Sky flows, but that are feasible given the software project’s resources. These flows must be more detailed than any of the flows produced so far, and like the other flows these must have triggers, process, results, and one noun and verb per index card. This is the set of flows that will be input to Part 2.

An example of a set of Realistic and Desirable flows is in Figure 2.2. There are three tasks that a desk clerk must do with the GUI about to be designed: make reservations, check in customers, and check out customers. Those three tasks have different triggers and results, so they are laid out as separate flows. But, the single GUI being designed will cover all three tasks.

3.1.8. SCOPING THE REALISTIC AND DESIRABLE TASK FLOWS

The team now gets another opportunity to change its mind about how much of the task set can be handled during this multiday session. If the scope needs to be smaller than what is shown in the Realistic and Desirable flows, the team draws a circle around the portion that can be dealt with. However, the team must include all the major data objects in the circled steps. Otherwise the GUI’s object framework will be difficult to extend later to accommodate the other data objects and so to accommodate the other task’s steps. If this circle differs from the scope circles on the previous flows (Big Picture, Current, and Blue Sky), the team must redraw the previous flows’ circles to match.

The final output of Part 1 is the set of Realistic and Desirable task flows, though the other task flows should be retained as context and as documentation of how the final flows were produced. The final set of flows must be detailed, well grounded, and well understood by the entire team because it is the input to the methodology’s Part 2 for extraction of the task objects.

3.2. PART 2: MAPPING TASK FLOWS TO TASK OBJECTS

This part is the center span of our bridge between user needs and GUI design. It maps the Realistic and Desirable task flows (i.e., user requirements) from Part 1 into somewhat abstract task objects — discrete units of information that users could manipulate to do the task. By “manipulate” we really mean only in the abstract, since these task objects are represented in Part 2 only as index cards. What users will actually manipulate in the GUI is determined by Part 3, which expresses each task object as a GUI object having a concrete representation such as a window. The task objects themselves are abstract enough that they could be expressed as any OO work environment’s artifacts. They could even be used to design a physical office by mapping them into office supplies such as real pieces of paper, file folders, and steel file cabinets. The precise destiny of the task objects is mentioned only briefly during Part 2 to orient the participants during their designing of the containment relations. Otherwise the participants work entirely in the abstract to keep focused on the pure information needed for the tasks.

Part 2 is done by all the participants, including the users, with the same pervasive techniques and orientations described above. Its explicit steps include discovering, designing, documenting, and usability testing the task objects; as was true of Part 1, this part is highly iterative and even somewhat messy. However, it does follow a strict sequence in that each of its substeps never begins until the previous substep has been done at least in a first pass. Our name for this entire Part 2 method is Task Object Design (TOD).

Figure 2.3 shows examples of task objects as they would appear at the end of Part 2. The figure also notes which steps within Part 2 produce the index cards and different stickies.


Figure 2.3  Task objects output by Part 2. Step 1 within Part 2 identifies the objects from the task flows, representing each object as an index Card (Hotel, Room, Customer, and Reservation). Steps 2 through 4 add stickies to represent characteristics of the objects. It helps to replace the task objects on the table in this vertically staggered way to reflect their containment relations — Hotel contains Room and Customer, Customer contains Reservation.


Previous Table of Contents Next