PD: structure in the toolbox

knowledge Concrete experienoe Relevant structures on users' present work C o n c r e t e experience with users' present work (2) (1) Visions and design proposals Concrete experience with the new system (5) (6) Overview of (4) technological options Concrete experience with technological options (3) The number ing 1 to 6 in Table 1 does not reflect a time sequence, (i.e., we are not proposing a new waterfall model). The number ing is done for the purpose of convenient reference. Various methods propose different sequencing when dealing with the six areas. Normally we would expect some degree of iteration. However, a discussion of methods is beyond the scope of this article. The six areas of knowledge comprise a classification of system development tools and techniques. The following subsections discuss, each area in more detail. The reader may wish to look ahead at Table 2 to see examples of tools and techniques in each area. Concrete Experience with Users' Present Work Developers need this area of knowledge [19]. They must have' some feeling for the users' work in order to be able to unders tand and to produce structured descriptions o1" representations of this work (area 2). They cannot rely on users' talking about their work, and they cannot rely on a requirement specification. Developers must experience users in action. I f developers have no concrete experience with what is going on in the user organization and if they have no idea of the cultural potentials for change, they cannot judge the relevance of a structured description of the work. User representation in the design team does not overrule this statement. The resuhs of dealing with this area of knowledge may come in terms of experiencing differences in working styles, normal and stress situations, exceptions, power relations, and so forth. Results may also be the formation of a common language among users and developers. Figure 1. Three d o m a i n s of d iscourse in t he des ign process Figure 2. Two levels of know ledge Relevant Structures on Users' Present Work A relevant structure defines a common and rigorous language in which users and developers can communicate. A structure is a model of the present situation in the user organization. The model is used to identify desired changes and to evaluate consequences of proposed designs. We refer to structures in the plural, as we cannot expect to capture the richness of the users' work in a single structure. Which structures are relevant depends on the situation. Information flow is a structure offered by many methods. It is relevant when we want to automate existing data processing. A control model is a relevant structure when we want to discuss management information systems. A model showing the variety and interrelationship of tasks carried out by individuals or a group dur ing a typical working day is relevant when we want to discuss requirements for a new communicat ion system. Concrete Experience with Technological Options If we want users to play an active role in system development we must provide them with technological options. This is done to stimulate their imagination and to enable them to better unders tand abstract descriptions of technical and organizational solutions. The relevance of activities in this area is of course dependent on the users' present experience. Even if they are daily users of some kind of system, they might not have experienced the variety of existing hardware and software. If we want designers to play an active role in designing the use of technology in organizations (although this is seldom an explicit goal, they often do this anyway) they must have organizational options. This is done to stimulate their organizational thinking and to enable them to unders tand the users' concrete experiences with, as well as their abstract descriptions of, organizational op-