CS 66-460
Introduction to Graphical Human Machine Interfaces

Design Guidelines and Usability Heuristics

WEDNESDAY, FEBRUARY 26, 1997

Instructor: G. Bowden Wise
Rensselaer Polytechnic Institute
Spring 1997

{

Design Guidelines and Usability Heuristics

Design guidelines are broad ``rules of thumb''

• Describe features of usable interfaces
• Can be applied to both character-based or graphical interfaces
• Usability statements that guide a developer's design efforts

Heuristic evaluation

• Same principles/guidelines used to ``evaluate'' a system for usability problems
• Becoming popular
  • user involvement not required
  • catches many design flaws

Design Guidelines and Usability Heuristics (continued)

Advantages

• the ``minimalist'' approach
  • a few general guidelines can correct for the majority of usability problems
  • easily remembered, easily applied
• discount usability engineering
  • cheap and fast way to evaluate system

Problems

• Principles are intricate
  • Can't be treated as a simple checklist
  • Subtleties involved in their use
• Best applied by experienced designers
  • understand their application and breakdown

Design Guidelines

1. Simple and natural dialog
2. Speak the users' language
3. Minimize user memory load
4. Be consistent
5. Provide feedback
6. Provide clearly marked exits
7. Provide shortcuts
8. Deal with errors in a positive and helpful manner
9. Provide help and documentation

Simple and Natural Dialog

• Use the user's conceptual model
• Match the user's task in as natural a way as possible
  • Minimize mapping between computer syntax/semantics and task semantics
• Present exactly the information the user wants
  • ``Less is more'' (Keep it simple)
    • If complex to explain/document, then redesign
    • Concise language
    • Avoid extraneous pictures and information
  • Information should appear in natural and logical order
    • related information is close together and graphically clustered
    • order of accessing information matches (or is controlled) by user's expectations

Simple and Natural Dialog (cont)

Good graphic design and color choice

• Appropriately direct attention
• Group related objects
• Balance and white space
• Maintain display inertia
• Few fonts and colors (5 to 7 colors)
• Appropriate colors
• Some people are color blind (8 percent of males)

Remove or hide irrelevant or rarely needed information

• competes with important information on screen

Use windows frugally

• don't make navigation and window management excessively complex

Speak the Users' Language

• Use mappings and metaphors between a user's conceptual model and computer display
  • Task analysis to understand user's domain
  • Metaphors can help or hurt
• Allow full-length names
• Terminology base on users' language for task, not on system oriented terms
  • Use common words, not ``techno-jargon''
  • Error messages and feedback refer to user objects
  • e.g., withdrawing money from a bank
    ``Maximum withdrawal of $50 at this time''
    versus
    ``X.25 connection discarded due to network congestion. Local limits now in effect''
• View interactions fro the user's perspective
  • e.g., a security transaction
    ``You have bought 100 shares of XYZ Corp''
    versus
    ``We have sold you 100 shares of XYZ Corp''

Speak the Users' Language (cont)

use meaningful mnemonics, icons, abbreviations

• a meaningful symbol that is easily remember and recognized

Minimize User's Memory Load

• Computers are good at remembering things, people are not!
• Short term memory: 7 + or - 2 items; 30 seconds to 2 minutes
• Menus rather than type-in (but short enough)
• Don't require retyping of remembered information
• Promote recognition over recall
  • menus, icons, choice dialog boxes, ... vs. command lines, field formats, ...
  • relies on visibility of objects to the user (but less is more!)
• Describe required input format and example and default
  • Enter date: __/__/__ (DD/MM/YY)
• Small number of rules applied universally
  • generic commands: cut, paste, copy, drag-n-drpo
  • same command can be applied to all interface objects

Be Consistent

• Consistency of effects
  • same words, commands, actions will always have the same effect in equivalent situations: predictability
• Consistency of language and graphics
  • same information/controls should be in same location on all screens or dialog boxes (e.g., OK and Cancel buttons)
  • Following interface standards helps
• Consistency of input
  • Consistent syntax across complete system
• Consistency can also hurt (see Grudin, CACM, October 1989, pp 1164-1173)

Provide Feedback

• Continuously inform the user about
  • what the system is doing
  • how the system is interpreting the user's input
  • minimizes the gulf of evaluation ( user should always be aware of what is going on )
• Should be as specific as possible, based on user's input
  • e.g., ``Saving file paper.doc'' not just ``Saving ... ``
• Response times
  • how users perceive delays

     0.1 secs: perceived as instantaneous
     1.0 secs: user's flow of thought stays uninterrupted, 
               but delay noticed
    10.0 secs: limit for keeping user's attention focused on the dialog
    10+  secs: user will want to perform other tasks while waiting

Provide Clearly Marked Exits

• User's don't like to feel trapped by the computer!
  • should offer an easy way out of as many situations as possible
• Strategies
  • Cancel button (for dialogs waiting for user input)
  • Universal undo (can get back to previous state)
  • Interrupt (especially for lengthy operations)
  • Quit (for leaving the program at any time)
  • Defaults (for restoring a property sheet)

Provide Shortcuts

• Experienced users should be able to perform frequently used operations quickly.
• Strategies
  • Keyboard and mouse accelerators
    • abbreviations
    • command completion
    • menu shortcuts
    • function keys
    • double clicking vs menu selection
• Type ahead (entering input before the user is ready for it)
• Navigation jumps
  • e.g., going from window/location directly, and avoiding intermediate modes
• Reuse
  • history systems (e.g., Unix, 75% of all commands have been entered before)

Deal With Errors In A Positive and Helpful Manner

• People will make errors!
• Kinds of errors
  • Mistakes
    • arise from conscious deliberations that lead to an error correct action
    • e.g., generalizations made to early
  • Slips
    • automatic (unconscious) behavior that gets misdirected en route to satisfying goal (e.g., stop car, turn off engine, unbuckle wristwatch)
    • shows up frequently in skilled behavior, usually due to inattention
    • often arises from similarities of actions

Deal With Errors In A Positive and Helpful Manner (cont)

Good error messages

• Help users when they are in trouble
• Opportunities for users to learn about the system
• Clear language; no codes
• Be precise. Not ``syntax error''
• Constructively help the user solve the problem? (tell why the error happened and how to fix it)
• Be polite and not accusing; positive wording:
  • Not: ``FATAL ERROR'', etc.
• Blame the system, not the user
  • ``Unrecognized'' vs. ``illegal'' command
• No humor or snide comments
• Easy error recovery
  • NOT: segvhandler: No mapping fault: 0x00e80000
  • NOT: can't save file - why not?

Prevent errors

• Selection rather than entry
• Remove or grey-out illegal choices
• Confirmation

Provide Help and Documentation

• Manuals are not a replacement for bad design!
• Simple systems
  • walk up and use; minimal instructions
• Most other systems
  • feature rich
  • some users will want to become experts rather than casual users

Heuristic Evaluation

• Systematic inspection of a user interface design for usability
• Method
  • small set of evaluators (3-5) examine interface using heuristics as a structure
    • individual evaluators inspect in isolation
    • then compare notes afterwards
    • single evaluator catches approx 35% of usability problems
    • with 5 evaluators, approx 75% of usability problems found
• Works for paper mock-ups, prototypes, and working systems.

Discount Usability Engineering (Nielsen)

• User and task analysis
  • Observe real users doing work
• Scenarios
  • ``Minimalist prototype'' only simulate the interface as long as a test user follows a previously planned path
• Simplified thinking aloud
  • Have users test system while ``thinking aloud''
• Heuristic Evaluation
  • There are thousands of rules you can use to evaluate an interface
  • Discount method: choose only 10, broad rules