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 user’s 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.

A.  In the middle of a large sheet of paper, draw a figure of some kind to represent each of the kinds of people who will actually interact with the system. These are the user roles (actors in Checkland’s terms). There will probably be more than one; for example, there may be computer operators who enter data and managers who use summary displays.
B.  Add further figures for people who might be affected by the introduction of the system even though they don’t have to operate the system themselves. These nonuser roles (other “clients” and “owners” in Checkland’s terms) may include, among others; supervisors, supervisees, and peers of the user roles; also customers, management, and the IT department who supply the relevant hardware and software services.
C.  Indicate the flow of work on the diagram with labeled arrows. Try to keep this description at a fairly high level and avoid getting bogged down in too much detail. For example, a customer may make an enquiry which is entered into a database by an enquiry clerk and which then results in some action by a repairman. A supervisor makes summary reports using the same database and gives them in printed form to a manager who uses them in his reports to the board of directors.
D.  Indicate the major concerns of all the roles represented by writing a short phrase next to each e.g., management are often concerned with cutting costs, operators with losing their jobs or being “deskilled”.
E.  On a separate sheet list each of the roles defined as drawings on the diagram and write for each a concise definition (not more than two or three sentences) of:
1.  Their responsibilities (people are responsible to someone for something).
2.  Their work (this is simply an amplification of the work flow arrows, step C, for that role).
3.  Their concerns (this is similarly an opportunity to explain and add to the concerns indicated in step 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