Previous | Table of Contents | Next |
3.3. HOW TO DO IT
The information needed to construct a rich picture is obtained by talking to the stakeholders identified. In most projects there will be a designated contact to represent the users needs. While you should start by talking to them it is important to talk to other people as well, particularly people who will end up working with the system. It is a good idea to interview people in their place of work. Here they will have access to documents, computer systems, etc. that can serve as prompts and examples. You may like to tape record what they say and it is always a good idea to go with a prepared set of questions to get you going (for practical advice of interview technique see Clegg et al., 1988).
A rich picture is informal enough to be presented to the stakeholders themselves so that your first stab at a rich picture can be taken back to your most useful informants. The process of explaining it to them will often elicit important new information and point up misunderstandings and errors of fact. Like all the other representations described in this chapter a rich picture may go through several iterations before the end of the design process.
The following steps should be taken to construct a rich picture. It is not necessary to be good at drawing to do this, the crudest figures will suffice (as is clear from Figure 5.1!). A drawing package has certain advantages given that you are going to have to change and add to the drawing. It is probably a good idea to use a different color for steps C and D.
Each of the steps A to E will suggest changes and additions you want to make to what you recorded in the earlier steps; this is a good thing to do. You will almost certainly have to redo the whole thing to make it presentable anyway. The diagram and these descriptions should stand on their own but may be supplemented by a short paragraph of explanation.
You will generally need to prepare a before and an after picture, i.e., a rich picture of the situation before the introduction of the computer system and a rich picture of the situation after it has been introduced. The before picture is needed when interviewing informants, to play back your understanding of the situation. The after picture is the basis of the design and used in the next stages. It should also serve to alert management in the user organization of the broader implications of the design.
4. REPRESENTING WORK AS OBJECTIVES THE WOD
4.1. WHAT IT IS FOR
The description provided by the rich picture should be very high level because one is aiming for a broad scope. The WOD and exceptions list, specify the work of the target user population in more detail. WOD stands for Work Objective Decomposition. Alternative approaches to representing this information tend to be (1) very time consuming and (2) focus the designer on what happens at the moment rather than the opportunities for creative and innovative design. The advantages of the WOD over these alternatives will be illustrated by representing the work of making a cup of tea.
Most people when asked to describe this task will generate a numbered list such as in Table 5.1. This does not easily code conditionals (what if the kettle is already full) or hierarchical structure (1 and 2 are part of the same subtask). The commonest response to this, in human factors, is to use a Hierarchical Task Analysis (HTA) as in Table 5.2. HTAs separate processes (the numbered items) from control (the plan in italics). Designers with a systems background tend to get deeply into specifying plans in great detail when this is really irrelevant to the design. It is irrelevant as the purpose of design is to change (and improve) the way the task is done. Focusing on processes has a similar unfortunate effect of emphasizing what is done now rather than how it might be done better. A WOD describes the task in terms of required states of the world, and avoids considering the processes by which these are achieved and the order in which they are achieved. This forces the designer to think clearly about the purpose of each process rather than the interdependencies between them. An example is given in Table 5.3.
Previous | Table of Contents | Next |