5 Dialogue Design

This chapter takes interface design from the strategic to the tactical level.
The interface is designed first as a set of logical modules using input from
task design, and then the modules are organised into an interface structure
by addition of an access mechanism. Access mechanisms are the way in
which users address data or functions provided by the system, and can be
hierarchic, network or direct. The type of mechanism will be dictated
mainly by the task structure and to an extent by the interface design
style. For structured task systems, menus present a hierarchical organisa-
tion, while command languages provide for network and direct access, and
icons are a direct access mechanism which may also have a hierarchical
structure. The logical modules are then mapped on to physical screens,
windows and overlays, depending on the target hardware and software
environment.
Each module is decomposed into discrete steps, each step being a single
question and answer between man and machine. The steps are then
re-assembled into a detailed dialogue design which describes how the
interface communicates with the user. The detailed design aims to incor-
porate good practices of dialogue design and provides some means of
verifying that the design adheres to those practices. The steps involved are
first designing the structure, then the access paths, followed by either
prototyping the design with interface design tools (4th generation
languages, screen generators) or detailed design of each step before
implementation. The steps are summarised in figure 5.1 Which route is
followed will depend on the complexity of the interface. More complex
interaction in which the dialogue is critical should be designed in detail.

5.1 Designing the Interface Structure

So far the interface specification is composed of a set of task descriptions,

system requirements and a strategic choice about the style of dialogue
design which is going to be used. The next task is to add the access
mechanism and then subdivide the whole interface into modules which can
be mapped on to physical structures and then programmed as parts of the
system interface, such as data entry screens, help and error overlays,
reports, menus and command lines.
97
A. Sutcliffe, Human-Computer Interface Design
© A. G. Sutcliffe 1988
98 Human-Computer Interface Design

Task design
descriptions

~ dialogue
modules Design
guidelines

Rejected
interface

Verified
design A=pted
design

r:::J
~
Figure 5.1 Flow diagram showing the steps of detailed interface design.

5.1.1 Adding User Access and Control

As user access is not part of the task description, it has to be added as part
of the new system. The aim is to synthesise the user's view and the task
structure. With luck these will agree, but sometimes the analyst may
perceive a network of linked tasks which the user sees as a set of
independent tasks. When in doubt the user usually knows best.
Interface modules will rarely be ordered in a simple sequence. The user's
view or the user requirements for system operation may state that certain
modules must be available on demand while others should be organised in
sequences to achieve a particular task. Organising interface modules into a
system depends on user characteristics, which influences the choice of
interface style, the system-task structure, and the user view of the
interface. Access paths may be hierarchic, network or direct. A menu style