Previous Table of Contents Next


2.2. WHITEWATER APPROACH

In contrast to the “waterfall” and “spiral” models of software design and development, our “whitewater” approach encourages very rapid iteration of analyzing, designing, and testing. All those activities occur within the same participatory session. An entire cycle for a piece of the GUI design might take only 2 minutes — a 30-second analysis of a subtask, yielding a design modification that is added to the paper prototype in 60 seconds, which is usability tested for 30 seconds before the user discovers a problem, sparking another 2-minute cycle of analysis, redesign, and testing.

The team rarely spends much time thinking about or discussing design alternatives in abstract. Usually it is more efficient to get concrete immediately, by usability testing the alternatives after quickly representing them in the low-tech materials. Iterations can take as little as a few seconds, because of the speed of using the low-tech materials and the instant availability of users and other stakeholders right there at the table. This principle applies not just to designing of the GUI per se, but also to designing of the task flows and task objects. A related principle is that the team must keep moving. When the participants spend much time discussing any point, when silence descends on the room, or when there is too little writing and drawing, the team immediately moves to the next activity. If the team’s best guess from that earlier step turns out to be wrong, the team can discard that solution and return to the activity in which it made the guess. This flexibility is made possible by the team’s low investment in any idea that has not yet been tested — low investment of time, labor, materials, and ego.

We call our approach “whitewater” because the activity as a whole moves rapidly toward its goal in a messy way due to the high total energy. There is churning, surging, boiling, and even some convulsing and eddying, but if those things are kept just enough under control, the activity as a whole makes much more rapid progress than it would if enough control were imposed to keep the activity smooth.

Two ingredients are needed for whitewater: a medium that not just allows, but encourages, a headlong pursuit, and strong but loose guidance to keep that energy pointed toward the goal. The guidance is provided by two elements: the explicit steps of the methodology and the session facilitators. (Facilitators are different from participants; the facilitator role will be described later.) The medium is provided by those same facilitators, by the composition of the participant group, by the low-tech materials, and by the gathering of participants about a small round table.

2.3. ROOM SETUP

Only five or six people participate in any session. Any more than that interferes with the group acting as a team, due to the emergence of side conversations, the difficulty of everyone reaching the center of the table, and so on. Other, less-relevant stakeholders may observe from another room. The two facilitators do not count as participants, since they do not sit at the table and are not the center of the session. The participants are all seated at a single round table that is small enough to give the group a feeling of intimacy, but large enough to give everyone adequate personal space. The table is two arms’ distance from the walls on which flip-chart paper can be attached, but the room is spacious enough for the facilitators to easily walk around. The chairs should be armless, to allow people to sit close to each other and to encourage people to sit close enough to the table to rest their arms on the table rather than lounging back away from the table and so becoming socially disengaged. Most importantis that the table be small enough for all participants to easily reach the center while staying seated, since all the activities are done by all the participants manipulating low-tech materials in the communal center of the table.

2.4. LOW-TECH MATERIALS

The task flows are documented with index cards for the steps and with removable sticky notes (“stickies”) for the flow arrows. (The foundation of that method is CARD, an early version of which is described in Muller et al., 1995.) Stickies are also used for labeling problems and solutions on the flows. The task objects are documented with index cards and stickies. The GUI design is documented with photocopies of empty windows and menus and with stickies for everything else. (The foundation of that method is PICTIVE, an early version of which is also described in Muller et al., 1995.)

Low-tech materials have many benefits (Virzi, 1989). They provide an “equal opportunity work surface”, as Muller says, because users who have little experience with computers can express themselves with those materials just as readily as the computer-savvy participants can. If instead we used computerized tools for flow charting or GUI prototyping during the session, the less computer-savvy users would be inhibited and would have their ideas documented only as the interpretations of whomever was controlling the computerized tools. Low-tech materials are usable with little investment of time, effort, or money, thereby supporting the technique of gradually increasing investment (see the next section). Participants are encouraged to create only low-fidelity prototypes, to quicken iteration by reducing participants’ investments in the intermediate ideas. Eventually the design should be expressed in a high-fidelity, computerized, running prototype. But that should not be done until after the low-tech prototype has been thoroughly tested, redesigned, reimplemented, and retested, during the participatory session and probably after as well. Investing the considerably greater resources needed for a high-tech prototype makes little sense until the risk of throwing away and replacing that expensive prototype has been made very small.


Previous Table of Contents Next