Previous | Table of Contents | Next |
A good dialogue model constrains the order in which operations are carried out only where absolutely necessary. It is dangerous to constrain the order of operations according to what you as a designer consider to be normal or logical. You may have missed something in your analysis or the work situation can change. In some applications there will be legal constraints on the order in which things are done, while in others, constraints may by imposed by security considerations. However, in office systems, order constraints are rarely this fundamental. As the dialogue model is primarily concerned with such constraints, this is the time to consider these issues.
This principle of minimizing constraints on the order in which things are done was followed in the warehouse case study. Operators were allowed to change anything up to the moment the data was sent to HQ (objective 1.4). Data cannot be changed then because the consequences of making those changes would be very expensive. The resulting dialogue model is thus very simple, any form can be accessed at any time and any field on it changed, up to the point it is sent to DMS where upon it becomes read only.
Having produced an initial dialogue model, the next step is to check it against the scenarios. This is done by going through each step in the scenario simulating or walking through what the user would have to do. This will probably identify some problems such as points where the user cannot access the relevant commands or where access is unnecessarily laborious. When the dialogue model has been modified to cope with these problems, more exhaustive checking should be undertaken using the WOD and then the complete exceptions list. The reason for working from the most simple (scenario) to most complex (WOD) is to make the process more tractable. There may be some exceptions that would be just too expensive to deal with. These should be noted to be discussed with the customer.
The scenarios for the warehouse case study were checked against the dialogue model, then the exceptions, and WOD. Because it was so simple and unconstrained no serious problems were detected. Most dialogue models are more complex than this and the process of checking them against scenarios, WOD, etc. is thus more complex. There are software tools for producing dialogue models. The author has developed Action Simulator (Monk and Curry, 1994) This allows a designer to build simple models of the high level behavior of the user interface that can be executed to give a dynamic view of the design. StateMate is another tool that allows modeling using Harel diagrams (Harel, 1987). There are also multi-media tools such as MacroMind Director that can be used to make prototype user interfaces that behave without requiring the designer to fill in low-level details.
After all this work considering the needs of the user, filling the missing detail needed to turn the dialogue model into a full design should be very straightforward. A style guide for the platform being used, such as the CUA guidelines (IBM, 1991) or the Apple Human Interface guidelines (Apple Computer Inc., 1987) should be followed at this stage. The full design may take the form of a paper simulation or a bare-bones simulation using an interface generator. There may still be a few improvements that can be made in the wording of items, layout, and graphic design to make the screens communicate what is required to the users. These improvements are best identified using a technique that brings representative users in contact with the design such as Co-operative Evaluation (Monk et al., 1993).
8. AFTERTHOUGHTS
The techniques described here do not require extensive training to use and the effort required to use them has been minimized by using informal common sense representations. Despite their informality the representations can help a design team to communicate and to reason about the needs of users. They will result in designs that take account of many usability problems that might arise if no analysis of user needs had been carried out. However, they do not guarantee the exhaustive identification of all such problems. This may be more closely approached by formal techniques though these will certainly require more effort to apply and learn.
It is also important to recognize that these representations were developed for use in a very specific design context. It is assumed (1) that the number of people developing and using the representations is small so that all will have a great deal of shared background knowledge, (2) that the users of the system can be readily identified, and (3) that the development team will have access to them.
Previous | Table of Contents | Next |