Previous | Table of Contents | Next |
There are very good reasons then for documenting the design process. However, to be really useful as tools for communication and reasoning, the representations used need to be tailored to the context they are going to be used in. Different representations have different properties. First, they capture different aspects of what they are used to describe. For example, representing an organization in terms of a reporting hierarchy would make explicit different aspects of organizational structure than a sociogram recording who communicates with whom. Let us say that by making some additional assumptions it is possible to infer one representation from the other. Even if this is the case, so that one representation implicitly contains the information in the other, it is still the case that one representation may be most useful for one purpose and the other for another. We say that each representation makes explicit different kinds of information. Second, different representations have different cognitive properties (Green, 1989). For example, diagrammatic representations are generally more difficult to create and change than textual representations but if well designed may be easier to read. Third, different representations require different skills and effort from the people using them. Many of the techniques devised by academics for software engineers, for example, require such a large investment in training and effort during use that they unlikely to be justified in terms of the payback they produce (Bellotti, 1988; Monk, Curry, and Wright, 1994).
2.2. THE NEED FOR LIGHTWEIGHT TECHNIQUES
Software design methodologies prescribe a set of representations that have to be produced and methods for deriving those representations. These formally defined methods tend to be used when the design team is large, i.e., 20 or more people, and may serve a management function. Very large projects, e.g., military command and control systems or off-the-shelf word processors, can only be coordinated through the application of well-articulated and strictly adhered-to procedures. This chapter, however, is not concerned with large projects. Rather, it is hoped to offer something to the smaller low-profile design projects that make up so much of the everyday work of software developers. These projects may only involve teams of two or three people working for a few months or even weeks. The developers we have in mind probably work for software houses or within user organizations. In the latter case they might be part of a management information service or computer department. Much of the software they use is bought in and most of their work is to use the options provided to customize it for different subgroups within the organization. For example, a particular department may request a Windows interface onto the company database for some very specific data entry task that is then implemented using Excel or Visual Basic.
The main difficulty faced by the small design team, in comparison with a large project, is that the resources they have for recruiting people with special skills or for learning new skills are very limited. Any technique they may apply must be lightweight in the sense that it can be easily picked up and easily applied. If a project has a total effort of a few man-weeks then the process of understanding the users needs can only be a few man-days and the effort required to learn techniques for doing this must be even less. Nielsen (1993) draws an analogy with shopping to illustrate this requirement for lightweight techniques. He describes his techniques as discount techniques: techniques that cost less than their deluxe versions but nevertheless do the job, cost being measured in terms of how much effort it takes to learn and then use them.
The techniques described here fit Nielsens requirements for discount techniques. They are lightweight procedures that can be learned in a day or so and only take man-days to apply. One of the reasons that this is possible is that they assume that there is a well-specified and accessible user population doing some well-defined tasks. The developers in one of these small projects can be very clear about who their users are and the work to be supported. Potentially, it should be easy for the developers to talk to these users and observe how they work. Compare this situation with that faced by the designers of a word processor, for example. Their users will all have very different skills and expectations, for example, some may be scientists others secretaries. The work to be supported will also vary a great deal, potentially, from typing a memo to producing a book. As will be explained, being able to specify a small user population and a small set of tasks to support makes it easier to guarantee task fit, the most important attribute of a usable system.
The representations described below were originally developed in a collaborative research project. The partners were Data Logic, a software house and System Concepts, a human factors consultancy and the human computer interaction research group at the University of York. The work most relevant to this chapter is described in (Curry et al., 1993). As a part of this project the techniques developed were applied in a case study of a warehouse handling food products for a large group of stores in the UK. This study will be used as an example in the sections that follow. The techniques have also been taught to, and used by, several generations of computer science students at York University and to this extent they are well tried and tested.
The body of this chapter is divided into four sections, each of which describes a different representation that may be used to think about some aspect of the users needs. In each case there is an introduction to the purpose of the representation, an example of what it looks like, and some instructions on how to produce it. Finally there is a section on how to use these representations when bridging the gap. The representations described are: (1) a rich picture to capture top level concerns; (2) a work objective decomposition (WOD) that serves a similar purpose to a hierarchical task analysis (HTA) but is easier to produce and use; (3) a user exceptions list of possible interruptions and mistakes, and (4) fictional scenarios of use generated from the WOD and user exceptions list.
Previous | Table of Contents | Next |