Previous Table of Contents Next


Note that these scenarios are very selective in what they illustrate. There are many ways an ideal scenario could have been generated from Table 5.4. Nevertheless, the scenario illustrates well how the work proceeds. Similarly, only two exceptions were selected from the list of 11 in Table 5.5. These were judged to be most important as it was known that the existing system handled them very poorly.

6.3. HOW TO DO IT

It is useful to include sample documents and other data with a scenario, e.g., photocopies of delivery notes and invoices, printout, and so on. Wherever possible these should be real documents and data. If real data are not available it is still useful to make something up and show it to users and ask how it could be made more realistic.

There is no need to be exhaustive in this exercise. It is unnecessary to have more than five or six scenarios in total. Also, there is generally no need to have scenarios illustrating the situation before the system is implemented; the intention is to illustrate what will happen with the new system. To generate the scenarios

A.  Use the WOD to write one or more best-case scenarios. Use the sample documents and your knowledge from interviews to flesh out the extra detail. Choose orders of events that you think will be good tests for the new system, e.g., those that are at present reported to be difficult to deal with.
B.  Select the most important exceptions from the exceptions list. These might be exceptions that are reported as being most disruptive to work at present or that you have other reasons for thinking will be difficult for the new system. Another criterion to think about is the frequency with which exceptions occur. Clearly, something that happens very infrequently would not need to be considered unless it is likely to have very severe consequences. Write these exception scenarios by adding to the best-case scenarios described in A.

7. BRIDGING THE GAP — THE NEED FOR A DIALOGUE MODEL

The four representations described are to reason about and record the needs of the user. They allow developers to communicate and develop their understanding as a group and to check their understanding with their informants. They also serve to record that understanding in a form that facilitates making the bridge to an initial design. The only additional information required is some sort of characterization of the users. A good user interface takes account of the previous experience of the user, their skill with mouse and keyboard, their knowledge of different operating systems, and their use of other computer systems (for “upward compatibility”). There will also be constraints imposed by the hardware and software available. This should all be written down and agreed among the design group and with the customer. One is then ready to “bridge the gap” to a first design. This section describes how to do this and then how to use the representations described above to evaluate that initial design.

Again we wish to argue that the gap can be made easier to bridge by choosing the right representation at the other side of the gap. The representation suggested is a dialogue model. This is a description of the high-level structure and behavior of a user interface. A common form of dialogue model is a rough sketch of screen outlines and a flow diagram to indicate how the user can change parts of the screen or move from one screen to another. The reason for starting with a high-level description of the behavior of the system is that this is the same level of abstraction as is provided by the WOD, exceptions list, and scenarios and these representations can thus provide inspiration for this part of the design.

Returning to the warehouse case study, the first step was to decide which objectives in the WOD (see Table 5.4) it would be most useful to support. 2. Goods allocated to stores and 3. Picking notes generated are already well automated as is 1.4 Delivery record sent to DMS for allocation to stores. Therefore, objectives 1.1, 1.2, and 1.3 were identified as the crucial work objectives to be supported. As these objectives are essentially data entry tasks the next step was to specify a data structure for storing the information to be entered. This took the form of a list of the data fields associated with each delivery.

The first really creative step was to decide how these data fields should be distributed across screens. It was decided that one basic screen, a form, would suffice for all three tasks. This form would gradually be filled in as the objectives were accomplished. The reasons for this were as follows:

1.  It makes the dialogue model very simple, there is only one screen layout.
2.  The commands needed would mainly be the standard commands for editing a form and this would be familiar to the users who were all experienced Windows users.
3.  The additional commands needed to create a new blank form and two others to hide or display existing ones could again be made similar to the commands they already new for creating, hiding and revealing documents.

This central screen, the form, was sketched in pencil. This allowed various details to be glossed over. Similarly, no commitment was made about how the commands, hide_form, display_form, and make_new_form would be implemented. This lack of commitment is important as it allows one to get the top level structure of the design right. If the first design had been produced using a software prototyping tool or user interface generator the developer would have been forced to make decisions about low-level detail, such as the names for fields, menu items, etc. before the overall structure of the design has been worked out. These details can pre-empt the top-level design and are also difficult to get right without the overall picture presented by a more abstract dialogue model.


Previous Table of Contents Next