Previous Table of Contents Next


2.1.PARTICIPATORY ANALYSIS, DESIGN, AND ASSESSMENT (PANDA)

PANDA methods involve users and other stakeholders as active collaborators in analyzing, designing, and assessing. PANDA is a general term for a whole class of methods invented and used by people throughout the world. Several overviews, and detailed descriptions of some methods, are in Muller and Kuhn (1993). A catalog of a great many PANDA methods, among which ours are just a few, is Muller, Hallewell Haslwanter, and Dayton (in press). Our task analysis, design, and assessment method that is Part 1 of The Bridge is an advanced descendant of the CARD method described in Muller et al. (1995). Part 2, Task Object Design, is briefly mentioned in the catalog by Muller, Hallewell Haslwanter, and Dayton (in press). Part 3, our low-tech GUI designing- and paper prototyping-method, is an advanced descendant of the PICTIVE method described in Muller et al. (1995).

Every activity in the three-part Bridge involves, from start to finish at the small round table, a team of representatives of the major stakeholders in the software product’s usability: users, usability engineer, system engineer, developer, and perhaps others such as subject matter experts, trainers, documenters, and testers. You should substitute whatever titles you use for the people who have those responsibilities, but in this chapter here is what we mean by those titles:

  Users are real potential users of the software product. Users are not just people who think they know what users want (e.g., users’ managers, purchasing agents) nor people who were users once upon a time. If there are several classes of users, for instance experts and novices, each class should have a representative participating in the session. Users do act as designers during the session. Like all the other participants, they are more expert in some aspects of designing than in others, but the methodology facilitates users acting to some degree as designers during all phases of the session.
  Usability Engineers are the people primarily responsible for the usability of the software and for all the activities that directly contribute to usability. Other people also are involved, but the usability engineers have formal responsibility and so initiate, coordinate, and complete the activities:
  Gathering preliminary data about the user, task, and work environment populations and about the business needs that the worker-computer combination is supposed to meet
  Analyzing, documenting, and sometimes redesigning the users’ task flows
  Designing the GUI
  Prototyping the GUI
  Designing, executing, and analyzing usability tests on the prototype, then redesigning the GUI on the basis of those results
  Writing and maintaining the user requirements formal document that drives the GUI coding and testing
  Helping the testers evaluate the final software product’s conformance to the formal requirements document
  Helping the learning support people design the user support documentation, on-line help, and training

If there is room at the table for only one usability engineer, that person should be the one with the most knowledge and skill in the GUI style and the Bridge methodology. The other usability engineers may observe from an adjacent room. The project’s usability engineers probably should not be facilitators of that project’s sessions, because they have a stake in the project (e.g., a complex design will take more time to write up in the user requirements document). Even if the usability engineers really can act neutrally, the other participants may suspect them of bias and so not respect them as facilitators.
  System Engineers are the people responsible for the underlying system requirements, such as the exact natures and sources of the data that the underlying computer systems must provide to the GUI code layer. The system engineers write a formal system requirements document that, together with the user requirements document, drives the developers’ work. Naturally, the system engineers must work closely with the usability engineers to ensure that the user requirements are feasible for the underlying systems, and sometimes the system requirements document is combined with the user requirements document. Ideally, The Bridge is used right at the project’s start, before any system engineering requirements have been written. That allows the user needs to drive the software product’s deep functionality as well as its look and feel. However, even if the system requirements are already set, a system engineer must participate in the session to help the team cope with those constraints and to help invent workarounds. If there is room at the table for only one system engineer, that person should be the one most capable of estimating feasibilities and of committing system engineers to work.
  Developers are the people who write the code that provides the functionality that is specified in the GUI and system requirements documents. Sometimes there are separate developers for the GUI layer of code than for the underlying back-end system code; the GUI coders are the most relevant to the GUI design sessions, but the back-end developers also can make excellent contributions. The Bridge should be used at the project’s start, before any back end code, or contracts between the GUI and the back end, have been written. Even if the GUI is being laid on top of a legacy system, the GUI developers participating in the session can help the team by explaining those underlying constraints as soon as they become relevant to the GUI designing and by helping create GUI design workarounds. If there is room at the table for only one developer, that should be the GUI developer most capable of estimating feasibilities and of committing the developers to work.

All those participants work together at a single, small, round table, actively collaborating in every activity. Of course, each participant contributes the most from one area of expertise. Users, for example, are most expert in the task and work environments, so are most active in designing the task flows and in doing the usability testing. The usability engineer is the most active during designing of the GUI per se. However, all the participants are quite capable of contributing to some degree and from some perspective during every step of the methodology.


Previous Table of Contents Next