[an error occurred while processing this directive]



Book Contents

Ch. 5
Designing and Evaluating DSS User Interfaces

Chapter Contents
Previous Page
Next Page

Building the DSS User Interface

The ROMC framework can be a useful tool for designing the DSS user interface. Also, the ROMC specification of elements along with screen layouts can aid in implementing the actual DSS user interface. Every DSS will have a specific set of representations, operations, memory aids, and control aids. The generality and usefulness of a DSS will depend on the skill of the designers in selecting design elements.

Flow-charting the existing or a desired decision process can help develop the ROMC framework. A decision process flowchart should focus on the inputs, operations and outputs of each decision task. The resulting DSS design will likely follow the flowchart and its sequencing of tasks. The resulting representations may be effective, but the operations and control aids developed from this approach may provide limited flexibility to the decision-maker. Creating prototypes of the DSS screens early in the analysis process, and then eliciting input from potential users can reduce the problem of limited flexibility in the operations of a DSS.

Screen designs and layouts should be aesthetically pleasing. The design does not need to be "artistic" but it should not create a negative impression. Managers and designers should evaluate a DSS user interface in terms of balance, symmetry, proportion and arrangement. Balance means the design elements are equally weighted on the screen. Symmetry refers to correspondence in size and shape of the design elements. Proportion is a harmonious relation among the parts. Arrangement is the ordering of elements. A balanced, symmetric screen design is the easiest screen layout to create and it is generally pleasing. Working with unbalanced and asymmetric screen designs is much more difficult for most of us. Figure 5.4 provides an example of a simple screen design. Do you think the design is balanced and symmetric?

Figure 5.4 An example of a simple, balanced screen design.

Keen and Gambino (in Bennett, 1983, p. 168) provide the following suggestions for building a DSS user interface. They believe rapid prototyping and adaptive design is essential; they argue any systems analyst, programmer, or consultant who wants to build Decision Support System must know how to:

a. Get started. A DSS application does not come packaged with neat specifications. Start with an initial user interface design. It provides a means of learning from and responding to the user.

b. Respond quickly. A DSS must evolve rapidly and designers must learn quickly. The design structure and programming techniques must facilitate evolution and learning.

c. Pay close attention to user-system interfaces and outputs. A DSS is a set of relatively simple components that must fit together to permit complex, varied, and idiosyncratic problem solving. The designer needs to get a very detailed understanding of the task to be supported and of the people who carry out the task.

According to Keen and Gambino the "natural sequence and order of priority" in developing a DSS is the following four steps:

  1. Design the user interface and dialog.
  2. Design commands and operations in terms of the users' processes and concepts.
  3. Define what the user does and sees when a command is invoked.
  4. Work backward to create the program logic and data management.

An alternative design approach is reviewed by Silver (1991). He notes the following steps are appropriate for developing a DSS user interface:

  1. Determine who your user is.
  2. Determine what the user will do with the system.
  3. Determine what sequence of steps the user must follow to accomplish a task.
  4. Diagram the steps in item 3 and the decision tree involved. Review them with the user.
  5. Determine which of these steps require interaction with the system.
  6. Determine information and decision requirements for each interaction (both system and user).
  7. Select the categories of dialogue (menus, prompts, forms, etc.).
  8. Diagram the flow of dialogue, showing all decisions and their information requirements. Review these with the user.
  9. Design screens.
  10. Try it, analyze it, simplify it, change it, try it . . .
  11. Update the decision diagrams.
  12. Bulletproof the dialogue by asking what happens if the user does something unexpected?

While Silver's list focuses on a broad set of steps; steps 4 to 11 are an iterative design process. Even if a DSS analyst plans to develop a DSS user interface using rapid prototyping, it is important to understand who your DSS user is, what the system will be used for, and what sequence of steps a user will follow. A designer may be able to skip over some of the formal diagramming steps, such as steps 4, 8, and 11, in favor of creating a prototype, but some understanding of the task should be formalized and documented.

[an error occurred while processing this directive]