Ch. 5
Designing and Evaluating DSS User Interfaces

According to Larson (1982), user interface design success is influenced by 11 factors. Some of them overlap with Shneiderman’s (1992). System factors include DSS execution time; the system's versatility; quality of help provided; adaptability; and uniformity of the commands and interface. Human factors include the: learning time for the DSS; ease of recall; errors made by end users; concentration required; fatigue from using the system; and the fun the user has while using the system. Larson elaborates on each of the factors that are determined, or at least affected, by the DSS user interface.

DSS execution time. How long does it take the end user to perform his or her task? Some fraction of task time is determined by actual DSS execution time. DSS execution time, while developers have some control over it by choosing software tools and hardware that are fast enough to provide the desired responsiveness, is not a user interface issue. Proper user-interface design can, however, minimize wasted time on the user's part.

Versatility. Can the system be used to perform a variety of tasks? The DSS must be versatile enough to accommodate the full range of tasks for which decision-makers will want to use it. Once a system becomes widely used, tasks related to its original purpose--but distinct from that purpose--will often arise. While it is reasonable for these new tasks to require new development work, it should be possible to incorporate them into the existing user-interface framework.

Quality of Help provided. Does the system provide help when the end user has trouble? On-line help facilities are becoming the norm for DSS. More and more development tools make it easy to incorporate on-line help into a system. Wherever possible, help should be context sensitive. The Help facility should recognize what the user is trying to do, or at least what screen the user is looking at, and provide help that is tailored as closely as possible to the current need. Expert systems have unique requirements in this area since they are often expected to explain to their users why they are asking for a particular data item or how they reached a particular conclusion.

Adaptability. Does the system adjust to the end user's level of competence as he or she becomes more experienced? Does it tailor itself to the habits and styles of different users? It may be difficult or impractical for the system to be truly self-tailoring in this sense. It is easier, and may be sufficient, to let the experience user select an "expert user" mode in which prompts are minimized. In a graphical user-interface environment, it is helpful to provide keyboard equivalents for commonly used mouse-and-menu commands, as some users prefer mice and others prefer keystrokes.

Uniformity of commands and interface. Are the commands of this system identical to equivalent commands of other systems? People can learn any idiosyncratic or esoteric interface it they want to. What is difficult is learning (and remembering) two, three, or more interfaces, be they esoteric or simple, and switching frequently among them. A DSS developer must be aware of other systems that the intended DSS users are familiar with. Also, using familiar terminology is a factor in making commands look uniform.

Learning time of the DSS. How long does it take a novice to learn the system? A design that provides for rapid learning must take into account what the user knows and how the user's mind fits that knowledge together.

Ease of recall. How easy is it for an end user to recall how to use the system after he or she has not used it for some time? This is a more important factor for DSS than for data processing systems because managers often return to a DSS after a long interval of nonuse. Some systems, for example, are intended to help with decisions that recur predictably on an annual basis. Eleven months might elapse from a manager's last use of the system on one annual cycle until his or her first encounter with it on the next. A user interface that facilitates recall will reduce the time it takes to "get back up to speed" each year.

Errors. How many errors does the DSS user make, and how serious are those errors? The most serious errors lead to wrong decisions as a result of system misuse. Following closely behind are errors that corrupt a corporate database. Then come errors that bring down ("crash") the computer, followed finally by errors that waste the user's time but have no other bad effects. Fortunately, most user errors will be in the last category. Understanding the users' usual decision-making process can help minimize errors. Design the system to make errors less likely, or at least to make recovering form them as easy, quick and painless as possible.

Concentration required. How many things must an end user keep in mind while using the system? Most people have difficulty keeping more than six or seven active facts in mind at any one time. One way to reduce the memory load is to label screens and output with the parameters of the current scenario: "Profit Projections: 6% inflation, 10% sales growth, Model 47 shipments start 4/94. . ."

Fatigue. How quickly does the user tire while using the system? Physical fatigue--or, more seriously, repetitive strain injuries such as carpal tunnel syndrome--is seldom a factor with DSS because usage frequency is not high enough to lead to such problems. However, mental fatigue can occur. Minimize mental fatigue by keeping the necessary concentration required within the capabilities of the users and by asking for information in the sequence in which users would normally use it.

Fun. Does the end user enjoy using the DSS system? This does not mean "funny" error messages or jokes on the screen. Such "humor" grows stale quickly. It means you should keep users informed about what the system is doing, warn them of time-consuming operations, provide progress displays or reports as long operation is being carried out, and generally try to minimize frustrations that come from using an uncooperative system.