A starting point for the development of computer software should always be to obtain an understanding of the stereotypical expectations of the operators. There are, however, critical difficulties with this method. Different individuals have different mental models and therefore different stereotyped expectations. Thus, it is not relevant for the software designer to use himself as a reference in the prediction of plausible mental models in the mind of the intended operators. Instead the designer needs to refer to his basic knowledge in perceptual, cognitive, and social psychology using people who are as similar as possible to the real users of the system.
To obtain a structure, an analysis of the manual and mental tasks involved must be carried out. These tasks (functions) in turn comprise many different subtasks (subfunctions) that also have to be described. When this has been accomplished, one has to carry out an allocation of the tasks to the operator and to the computer. The operator should have a general understanding (not a detailed knowledge) about the tasks allocated to the computer and the compatibility of the operator’s mental model related to this situation. Two different complementary approaches are used for this process: the systematic, and the holistic and participative. The systematic approach is explained in Section 13.2.2 (Systems Analysis).
Traditionally, dialogues are designed last in the process of developing a new computer system. This is not advisable. The dialogue design should be regarded as a design process of its own party separated from the total system development and initiated from the outset. The result of the dialogue design should be a specification to be used in the rest of the system development.
The holistic approach implies that the design work is carried out to some extent on an ad hoc basis. This form of design process is claimed to give room for more creativity but is, of course, less predictable and might be difficult to use for very large projects. The holistic approach often also implies that one is working in close cooperation with the intended users of the system. Participative design is especially important in the design of dialogues. Working with the users would give access to the users’ knowledge and expertise about their own working conditions. This will help us to carry out the task analysis and to define the operator’s ‘mental models’. To include the operators in the development will also increase their motivation and willingness to cooperate in a positive and constructive way in the implementation of the system. The operators can also be used as subjects in different forms of expert evaluations. Expert evaluations can be done on either the whole or on parts of the dialogue.
It is, however, often difficult to involve users in a traditional process of system design. The users normally do not have sufficient levels of programming skills nor are they used to abstract thinking. The design procedure has, therefore, to be changed so that instead of using different theoretical development tools, it can be visualised in a more practical and realistic form. At a very early stage of the design, one can use ‘mock-ups’ of the dialogues. These mock-ups could simply be paper-and-pen – cil exercises that describe and illustrate the different dialogues. Another alternative might be to present the different dialogues on a personal computer. However, this form of dialogue consists only of visual illustrations and does not allow any realtime interaction.
The next refinement could be the use of prototypes. The prototype is a simplified version of the final system developed on a personal computer. The prototype will allow some real-time interaction between the system and the operator but it does not cover, or does not incorporate, the use of a complete database.
