Previous Table of Contents Next


The Bridge facilitates everyone contributing to all the activities. One way is by educating every participant in the other participants’ areas of expertise. That education is done mostly informally, sprinkled throughout the analysis, design, and testing activities as the topics naturally arise. Another way is getting participants to support each other by using their particular expertises to fill in the information missing from the other participants’ ideas. For example, a user might compensate for the usability engineer’s lack of task knowledge by designing a window — by writing some field names on a photocopied empty window. The user might then complain that there is so much information in that window that the pieces needed at any one time are hard to find. The usability engineer might instantly respond, filling in the users’ missing GUI design knowledge by suggesting segmenting the window’s contents into notebook pages. This symbiosis is no different than the usability engineer relying on the developer andsystem engineer for new ideas about how the underlying technology can help.

Getting even one representative of each of the stakeholder groups sometimes would lead to more than the five or six session participants that we allow. In that case, only the stakeholders most critical to the GUI per se sit at the table — three users, one usability engineer, one system engineer, and one GUI developer. The other stakeholders are allowed to silently observe, preferably from another room. There are other techniques for handling too many stakeholders for a single session, such as having successive design sessions with overlapping membership, and running two tables at once with synchronization of the tables after each substep of the methodology. With techniques such as those, The Bridge has been used successfully in projects having more than 30 distinct user populations, and in projects having over 100 staff (developers, system engineers, usability engineers, etc.). Such advanced techniques are beyond the scope of this chapter.

The presence of representatives from all the stakeholder groups at the same table allows rapid iterations of designing and testing, via two mechanisms of increased efficiency:

  Iterations are speeded. Time is not spent creating a design, writing it up, and sending it to the developers and system engineers for review, only to have the developers and system engineers reject it as infeasible. Instead, a developer and system engineer are sitting right there at the table, commenting on feasibility as soon as the design ideas pop up. Similarly, usability engineers do not waste time detailing, documenting, creating a computerized prototype, and arranging and running formal usability tests, only to have users reject the fundamental design. Instead, users are sitting right there at the table, giving feedback the instant the design ideas arise.
  Iterations are eliminated. Rapid feedback on ideas generated by other people is not the main benefit or point of participatory methods. “Participation” means active collaboration of all the stakeholders in generating the ideas. The initial ideas are better than they would have been if the stakeholders were working isolated from each other, so the initial iterations of creating really bad designs and testing them are just skipped.

PANDA improves the effectiveness of design as well as its efficiency. The ideas generated by the team collaborating in real time often are far superior to the ideas that could have been generated by the same people working isolated from each other for any amount of time, even if they were communicating with each other asynchronously or through narrow bandwidth media (Muller et al., 1993).

The great efficiency and effectiveness of the PANDA approach cannot be attained merely by throwing this bunch of people together into a room. Standard-style meetings do not encourage true collaboration. These stakeholders can actively collaborate best in a fluid atmosphere that is barely on the organized side of chaos — a “whitewater” model of analysis, design, and assessment.


Previous Table of Contents Next