Previous Table of Contents Next


5.3. HOW TO DO IT

Go back to your interviews with the users and note where they mention events that were disruptive to the flow of work. Then go through the WOD and try to think of all the things that could go wrong. Finally, gather together your thoughts under the three headings described below.

A.  List the application exceptions — These will include physical breakdowns and ‘correct’ behavior (e.g., an unacceptable ID when the user is logging in to a system). Work out where these exceptions could occur, i.e., which objectives might the user be working on when they occur.
B.  Problems/mistakes — List user exceptions due to the users making mistakes or changing their minds. Take each subobjective to be computer supported in turn. Ask yourself whether the user having achieved that objective might want to “undo” it at some later stage and if so where such a decision is likely to be taken, i.e., which objectives might the user be working on at that point.
C.  Interruptions — List user exceptions due to interruptions. Most people interleave several tasks in their daily work. Ask yourself when they could be interrupted and what implications this could have for design. The higher level work objectives and the rich picture will suggest what these interruptions are likely to be. Again work out where in the WOD these interruptions could occur.

6. ILLUSTRATIVE STORIES — SCENARIOS

6.1. WHAT THEY ARE FOR

The rich picture, WOD, and exception list will capture most of your understanding of the work context that is to be supported by the computer system. However, these representations are relatively abstract and may seem rather cryptic to someone who has not been in on their development. The purpose of the scenarios is to put back a bit of detail and make the understanding more concrete.

Scenarios have been used widely in HCI design (Campbell, 1992). In this chapter the word is taken to mean a fictional but nonetheless typical story describing a user’s work. Scenarios are to summarize and illustrate your understanding of the work so fictional scenarios are more useful than real accounts of user behavior because it is possible to make several points in the same scenario in an efficient way. Another reason for using fictional scenarios rather than real transcripts is that you need to illustrate the new way of working, after the system has been introduced.

Scenarios flesh out a WOD and exception list by including sequences of actions and some detail. They contain examples of typical data associated with real use. It is particularly valuable to attach samples of the actual documents used such as delivery notes or invoices. The stories should highlight crucial sections of the users tasks. Scenarios are the first representation to be used in checking a design and the best representation for describing the work to someone who has not seen any of the representations before.

6.2. WHAT THEY LOOK LIKE

Two scenarios developed for the warehouse case study are given here. Table 5.6 was constructed directly from the WOD in Table 5.4 and represents the ideal case where there are no exceptions. This illustrates how the work involves interleaving different jobs in a way that is much less apparent in the WOD. Table 5.7 was generated by adding two of the exceptions from Table 5.5 to the ideal scenario in Table 5.6.

Table 5.6 Scenario of Work When There are No Exceptions
Scenario 1: Ideal case

1. Driver Dave Hodges gives Jenny gate house pass 7492 and delivery note (see sample documents)
2. Jenny enters gatehouse no. “7492”, supplier code “Smith34”, product codes and quantities (see sample delivery notes)
3. Jenny request printing of tally cards (see sample documents) for 7492 and gives them to warehouseman John
4. Warehouseman Mike comes in with tally card for 6541 with locations (see sample documents)
5. Jenny recalls delivery 6541 to screen and enters locations.
6. DMS prints store picking notes for cv49w to cv52z; Jenny gives these to warehouseman George
7. Warehouseman John comes to window with tally card for 7492
8. Jenny recalls delivery 7492 to screen and checks quantities with John — OK
9. Request printing of COD for 7492 (see sample documents)
10. Jenny gives COD to driver Dave Hodges
11. Jenny sends delivery record for 7492 to DMS

Table 5.7 Scenario of Work with a Data Entry Mistake and Interruption when Entering Data from the Delivery Note
Scenario 2: exceptions

1. Driver Dave Hodges gives Jenny gate house pass 7492 and delivery note
2. Jenny enters gatehouse no. “7492”, supplier code “Smith 34”, and half of the product codes and quantities (see sample delivery notes)
3. Warehouseman Tim informs Jenny of priority cold storage delivery and hands her gate house pass 7581 and delivery note from driver
4. Jenny enters “7581”, supplier code “Browns67”, and the product codes and quantities
5. Jenny request printing of tally cards (see sample documents) for 7581 and gives them to warehouseman Tim
6. Warehouseman Mike comes in with tally cards for 6541 with locations (see sample documents)
7. Jenny recalls delivery 6541 to screen and enters location
8. Jenny recalls partly entered delivery 7492 to screen and enters remaining quantities and product codes
9. Jenny request printing of tally cards (see sample documents) for 7492 and gives them to warehouseman John
10. DMS prints store picking notes for cv49w to cv52z; Jenny gives these to warehouseman George
11. Warehouseman John comes to window with tally card for 7492
12. Jenny recalls delivery 7492 to screen and checks quantities with John; one product code was mistyped but the quantities correspond
13. Jenny changes product code and requests printing of COD for 7492
14. Jenny gives COD to driver Dave Hodges
15. Jenny sends delivery record for 7492 to DMS


Previous Table of Contents Next