Book Contents

Ch. 5
Designing and Evaluating DSS User Interfaces

Chapter Contents
Previous Page
Next Page

Appendix 5.1 User Centered Design Guidelines

Please review and evaluate the following design guidelines. Why are they called user centered design guidelines? Do the guidelines make sense? Are they complete? Are they too detailed? Will they help a manager evaluate a DSS user interface? Or will they be of greater use to a DSS designer/builder?

The guidelines are based on a web document prepared at NASA called HCI Guidelines at URL http://groucho.gsfc.nasa.gov/Code_520/Code_522/Documents/HCI_Guidelines.

A.1 Transparency: Create Low Profile Software.

  1. Have the user interface design focus on the decision task, e.g., approving loan applications, monitoring key results metrics, allocating resources.
  2. Have interface styles reflect the users point of view and conception of what is being done, not designer’s point of view.
  3. Present only information relevant to the user’s decision tasks. Do not present extraneous information on the screen.
  4. Use system capabilities because they enhance user task accomplishment, not because they can be used. For example, color or blinking text should be used appropriately.

A.2 Transparency: Design Intuitive Software.

  1. Use abbreviations, mnemonics, codes, and acronyms based on normal language usage, specific job related terminology, or a known logic, do not use an arbitrary selection.
  2. Design the DSS to take advantage of what the user already knows.
  3. Make terminology for labeling, commands, messages, and prompts consistent with the user’s frame of reference. A term should mean what a user thinks it means.
  4. Design icons to directly represent the associated object or action.
  5. Design the DSS to do what the user would naturally or naively guess it should do.

A.3 Transparency: Design Predictable Software.

  1. Maintain visual consistency as well as action consistency.
  2. Predictable software results from consistency.
  3. Maintain consistency in the display, labeling terminology, system control and abbreviations.
  4. Design the DSS so the user is able to predict how it will respond to actions.

B.1 Resiliency: Accept minor deviations in responses.

B.2 Resiliency: Anticipate User Actions and Needs.

C.1 Orientation and Navigation: Provide Orientation in the System.

  1. Make sure the user knows: Where she is, What she can do there, How she can leave a page or the system.
  2. Give each screen and window a descriptive title, placed in a consistent location.
  3. Provide cues to identify the currently displayed page and the total number of pages in a multi-page display.
  4. When appropriate, provide a system map to show the user where s/he is in the system.

C.2 Orientation and Navigation: Consider Possible User Actions.

  1. Provide a general list of basic control options, always available, to serve as a home base or consistent starting point for control entries.
  2. Make applicable menus and control options available to the user at all times.

C.3 Orientation and Navigation: Exiting.

  1. Provide the user a means to log-off a DSS by a single action (e.g., menu option, command input).
  2. Require a confirmation to exit without saving changes.

D.1 Productivity: Simplicity.

  1. Provide an overall design and specific features that take job requirements and decision tasks into consideration and that supports job accomplishment.
  2. Avoid the use of acronyms and abbreviations.
  3. Require recognition rather than recall memory where possible.
  4. Use units of measurement familiar to the user. Do not require the user to transform units of measurement.

D.2 Productivity: Screen Layout.

  1. To support critical tasks, keep screen density as low as possible (for warning and emergency messages, preferably less than 25% of the screen space).
  2. Maintain consistent display formatting within the system.
  3. Use highlighting, blinking, reverse video, etc. to draw attention to specific screen elements -- but do not overuse such devices (Do not use blink coding for text that must be read).
  4. Use colors for coding and emphasis, but use it sparingly (no more than 4 colors on a screen).
  5. Display only task related information and place all data related to one task (operation/transaction) on a single screen.

D.3 Productivity: Feedback.

  1. Highlight data, a message, a menu item, an icon, or other display structure as feedback to acknowledge that the user has selected the item.
  2. Provide users with information about the current system status as it affects their work (for example, printing delays, inoperable peripherals, and processing delays due to system load).
  3. When the completion of a command results in a consequence that is not visible to the user, provide a feedback message that describes the actions resulting from the command in simple, direct, positive language.
  4. When the completion of a command results in a consequence that is easily perceptible to the user, do not provide additional feedback.
  5. If a process is time-consuming and causes the screen and input devices to be locked, display and update a progress message.

E.1 Integrity: Dangerous Operations.

  1. Maintain the integrity of DSS data.
  2. Build protection around dangerous operations; permit the user to undo things that have been done.
  3. Require users to confirm that they want to perform a critical, potentially hazardous, or potentially destructive command before execution.

E.2 Integrity: Help Function

  1. Provide on-line Help -- summary information initially, with more detailed explanations available on request.
  2. Permit the user to enter Help at any point and use a simple, standard action for the user to request Help.
  3. Permit the user to browse Help topics.
  4. Provide an easy means of returning to the task after accessing Help.

F.1 Control: System Control.

  1. Make sure the user feels in control of a decision support session. The user should not feel controlled by the computer.
  2. Give the user multiple means for doing things and let the user, not the computer, set the pace.
  3. Provide for simple command language control of a DSS by advanced users.

F.2 Control: Entry.

  1. Use command keystrokes where speed of command input is important. Make other dialog techniques available as appropriate.
  2. Require the user to enter any particular data only once; have the system access that data if needed thereafter.
  3. Design any data entry transactions and associated displays so that the user can stay with one method of entry and not have to shift to another.

F.3 Control: Feedback Messages.

  1. Permit the user to request a more detailed explanation of feedback.
  2. Use neutral wording in feedback messages -- do not make them funny or negative.
  3. Make messages brief. Do NOT use the word "error".
  4. Design the DSS so users are unlikely to make "errors".

 



DSSResources.COMsm is maintained and all its pages are copyrighted (c) 1995-2002 by D. J. Power (see home page). Please contact power@dssresources.com. This page was last modified Wednesday, May 30, 2007. See disclaimer and privacy statement.