1. Usability Heuristics
CMPT 281

2. Outline
Usability heuristics
Heuristic evaluation

3. Usability heuristics Heuristics: As design principles:
rules of thumb that describe features of usable systems
As design principles:
broad usability statements that guide design efforts
derived by evaluating common design problems across many systems
As evaluation criteria:
the same principles can be used to evaluate a system for usability problems
becoming very popular
user involvement not required
catches many design flaws

4. Usability heuristics Advantages Problems the minimalist approach
a few guidelines can cover many usability problems
easily remembered, easily applied with modest effort
discount usability engineering
cheap and fast way to inspect a system
can be done by usability experts and end users
Problems
principles are at the ‘motherhood’ level
can’t be treated as a simple checklist
there are subtleties involved in their use

5. Nielsen’s Ten Heuristics
Visibility of system status
Match between system and the real world
User control and freedom
Consistency and standards
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
Help users recognize, diagnose, and recover from errors
Help and documentation

6. Visibility of system status
The system should always keep users informed about what is going on
Appropriate feedback within reasonable time

7. Visibility of system status
What mode am I in now?
What did I select?
How is the system interpreting my actions?

8. Visibility of system status

9. Match between system and real world
The system should speak the users' language
Words, phrases and concepts familiar to the user
Not system-oriented terms
Follow real-world conventions
Put information in a natural and logical order

10. Match between system and real world

11. Match between system and real world

12. User control and freedom
Users often choose system functions by mistake
They need clearly marked “emergency exits”
Let them get back without extended dialogue
Support undo and redo

13. User control and freedom

14. User control and freedom

15. Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing.
Follow platform conventions

16. Consistency and standardsOk
Cancel
Done
Never Mind
Accept
Dismiss

17. Consistency and standards

18. Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place.
Two options:
Eliminate error-prone conditions
Check for them and present users with a confirmation option before they commit

19. Error prevention

20. Error prevention

21. Recognition rather than recall
Minimize the user's memory load by making objects, actions, and options visible
The user should not have to remember information from one part of the dialogue to another
Instructions for use of the system should be visible or easily retrievable whenever appropriate

22. Recognition rather than recall

23. Recognition rather than recall

24. Flexibility and efficiency of use
Accelerators can speed up interaction for expert users
Accelerators are unseen by the novice user
The system can cater to both inexperienced and experienced users
Allow users to tailor frequent actions.

25. Flexibility and efficiency of use

26. Aesthetic and minimalist design
Dialogues should not contain information that is irrelevant or rarely needed
Every extra unit of information in a dialogue competes with relevant units, and diminishes their visibility

27. Help users recognize, diagnose, and recover from errors
Error messages:
Should be expressed in plain language (no codes)
Should precisely indicate the problem
Should constructively suggest a solution

28. Help users recognize, diagnose, and recover from errors

29. Help and documentation
Best if the system can be used without help!
May be necessary to provide help and documentation
Help should be:
Brief
Easy to search
Focused on the user's task
Concrete

30. Help and documentation

31. Help and documentation

33. Neilsen’s Nine Heuristics
1. Simple and natural dialog
2. Speak the user’s language
3. Minimize user’s memory load
4. Be consistent
5. Provide feedback
6. Provide clearly marked exits
7. Provide shortcuts
8. Deal with errors in a positive manner
9. Provide help

34. 1. Simple and natural dialogue
Use the user’s conceptual model
Match the users’ task in a natural way
minimize mapping between interface and task

35. 1. Simple and natural dialogue
Present exactly the information the user needs
less is more
less to learn, to get wrong, to distract...
information should appear in natural order
related information is graphically clustered
order of accessing information matches user’s expectations
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

36. 2. Speak the users’ language
Terminology based on users’ language for task
e.g. withdrawing money from a bank machine

37. 2. Speak the users’ language
Use meaningful mnemonics, icons, and abbreviations
eg File / Save
Ctrl + S (abbreviation)
Alt FS (mnemonic for menu action)
Open folder (toolbar icon)

38. 2. Speak the users’ language

39. 2. Speak the users’ language

40. 3. Minimize user’s memory load
Promote recognition over recall
Computers good at remembering things, people aren’t!
menus, icons, lists vs. command lines, field formats
relies on visibility of objects to the user (but less is more!)

41. 3. Minimize user’s memory load
Input formats
Indicate required format
give example and default entry

42. 3. Minimize user’s memory load
Small number of rules applied universally
generic commands
same command can be applied to all interface objects
interpreted in context of interface object
copy, cut, paste, drag and drop
for characters, words, paragraphs, circles, files

43. 4. Be consistent Consistency of effects
the same words, commands, and actions should always have the same effect in equivalent situations
increases predictability
Consistency of language and graphics
same information and controls in the same location
forms should follow boiler plate
use the same visual appearance across the system
e.g. icons, UI widgets
Consistency of input
consistent syntax across system Ok
Cancel
Cancel Ok
Done
Never Mind
Accept
Dismiss

44. 5. Provide feedback Continuously inform the user about:
what the system is doing
how the system is interpreting the user’s input
The user should always know what is going on
What’s it doing?
Time for coffee.
> Doit
> Doit
This will take 5 minutes...

45. How is the system interpreting my actions?
5. Provide feedback
What mode am I in now?
What did I select?
How is the system interpreting my actions?

46. 5. Provide feedback Be specific, based on user’s input
Interpretation of feedback:
Simpler when in the context of the action

47. 5. Provide feedback Response time how users perceive delays
0.1 second: perceived as instantaneous
1 second: user’s flow of thought stays uninterrupted, but delay noticed
10 seconds: limit for keeping user’s attention focused on the dialog
> 10 seconds: user will want to perform other tasks while waiting

48. 5. Provide feedback Dealing with long delays: Cursors/Throbbers
for short transactions
Percent done dialogs
for longer transactions
how much left
estimated time
what it is doing…
Random animation/Throbber
for unknown times
Contacting host (10-60 seconds)
cancel

49. 6. Provide clearly marked exits
How do I get out of this?

50. 6. Provide clearly marked exits
Users don’t like to feel trapped by the computer!
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)

51. 7. Provide shortcuts Support experienced users Strategies:
experts should be able to perform frequent actions quickly
Strategies:
keyboard and mouse accelerators
abbreviations
command completion
menu shortcuts
function keys
double clicking vs. menu selection
type-ahead (entering input before the system is ready for it)
navigation jumps and hyperlinks
history and bookmark lists
e.g. WWW: ~60% of pages are revisits

52. Keyboard accelerators for menus
Customizable toolbars and palettes for frequent actions
Split menu, with recently used fonts on top
Double-click raises toolbar dialog box
Double-click raises object-specific menu
Scrolling controls for page-sized increments

53. Alternate representation for quickly doing different tasks
Toolset brought in appropriate to this representation

54. 8. Deal with errors positively
People will make errors!
Errors we make
Mistakes
arise from conscious deliberations that lead to an error instead of the correct solution
Slips
unconscious behaviour that gets misdirected en route to satisfying goal
e.g. drive to store, end up at the office
shows up frequently in skilled behaviour
usually due to inattention
often arises from similarities of actions

55. I can’t believe I pressed Yes...
Types of slips
Capture error
frequently done activity takes charge instead of one intended
occurs when common and less common actions have the same initial sequence
change clothes for dinner and find oneself in bed (William James, 1890)
confirm saving of a file you meant to rename
I can’t believe I pressed Yes...

56. Types of slips Description error Data-driven error
intended action has much in common with others that are possible
usually occurs when right and wrong objects physically near each other
pour juice into bowl instead of glass
go jogging, come home, throw sweaty shirt in toilet instead of laundry basket
move file to trash instead of to folder
Data-driven error
the data for the intended action is similar to other data
more common data pushes itself forward
telephone home instead of correct number

57. Types of slips Loss of activation error Mode errors
forgetting what the goal is while undergoing the sequence of actions
start going to room and forget why you are going there
navigating menus/dialogs and can’t remember what you are looking for
can sometimes continue action to remember (or go back to beginning)!
Mode errors
people do actions in one mode thinking they are in another
insert / edit mode in vi
refer to file that’s in a different directory
look for commands / menu options that are not relevant

58. Designing for slips General rules Examples
Prevent slips before they occur
Detect and correct slips when they do occur
User correction through feedback and undo
Examples
mode errors
have as few modes as possible (preferably none)
make modes highly visible
capture errors
instead of confirmation, make actions undoable
allows reconsideration of action by user
e.g. trash can can be opened and “deleted” file taken back out

59. Designing for slips Examples continued loss of activation errors
if system knows the goal, make it explicit
if not, allow person to see path taken so far
description errors
in icon-based interfaces, make sure icons are not too similar
check for reasonable input

60. Design approaches for errors
General idea: forcing functions
prevent or mitigate the continuation of wrongful action
Gag
deals with errors by preventing the user from continuing
e.g. cannot get past login screen until correct password entered
Warn
warn people that an unusual situation is occurring
when overused, becomes an irritant
e.g.,
audible bell
alert box

61. Design approaches for errors
Do nothing
illegal action just doesn’t do anything
user must infer what happened
enter letter into a numeric-only field (key clicks ignored)
put a file icon on top of another file icon (returns it to original position)
Self-correct
system guesses legal action and does it instead
but leads to a problem of trust
spelling corrector

62. Design approaches for errors
Let’s talk about it
system initiates dialog with user to come up with solution to the problem
compile error brings up offending line in source code
Teach me
system asks user what the action was supposed to have meant
action then becomes a legal one

63. A problematic error message to a nuclear power plant operator

64. 8. Deal with errors positively
Provide meaningful error messages
error messages should be in the user’s language
preferably task language
don’t make people feel stupid
Try again, bonehead!
Error 25
Cannot open this document
Cannot open “chapter 5” because the application “Microsoft Word” is not on your system
Cannot open “chapter 5” because the application “Microsoft Word” is not on your system. Open it with “Teachtext” instead?

65. 8. Deal with errors positively
Prevent errors
try to make errors impossible
modern widgets: only “legal commands” selected, or “legal data” entered
Provide reasonableness checks on input data
e.g. on entering order for office supplies:
“5000 pencils is an unusually large order. Do you really want to order that many?”

66. 9. Provide help Help is 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
intermediate users need reminding, plus a learning path

67. Types of help Tutorials and getting started manuals
short guides that people are likely to read when first obtaining their systems
encourage exploration and getting to know the system
try to give main concepts and essential syntax
on-line tours, exercises, and demos
demonstrates very basic functionality through working examples

68. Types of help Reference manuals
used mostly for detailed lookup by experts
rarely introduces concepts
thematically arranged
on-line hypertext
search / find
table of contents
index
cross-index

69. Types of help Reminders short reference cards keyboard templates
expert user who just wants to check facts
novice who wants to get overview of system’s capabilities
keyboard templates
show shortcuts and syntactic meanings of keys
promotes recognition vs. recall
tooltips
floating text over graphical items indicates their function or purpose

70. Heuristic Evaluation
Helps find usability problems in a UI design by systematic inspection
Small set (3-5) of evaluators examine UI
independently check for compliance with usability principles (“heuristics”)
different evaluators will find different problems
evaluators only communicate afterwards
findings are then aggregated
Can perform on working UI or on sketches

71. Inspection methods Systematic inspection of a user interface
Goal is to find usability problems
Inspections use inspectors not real users
Works for systems at any stage:
paper or code prototypes
working systems
Heuristic evaluation:
the most popular inspection technique

72. Phases of Heuristic Evaluation
Pre-evaluation training
give evaluators needed domain knowledge & information on the scenario
Evaluation
individuals evaluates UI & makes list of problems
Severity rating
determine how severe each problem is
Aggregation
group meets & aggregates problems (w/ ratings)
Debriefing
discuss the outcome with design team

73. Heuristic Evaluation Details
Each inspector works alone with the interface
A session typically lasts 1-2 hours
The two-pass approach
first pass: focus on specific interface elements
second pass: higher level integration and flow
If system is walk-up-and-use or evaluators are domain experts, no assistance needed
otherwise might supply evaluators with scenarios
Each evaluator produces list of problems
explain why with reference to heuristic or other information
be specific & list each problem separately

74. Severity Rating Used to allocate resources to fix problems
Estimates of need for more usability efforts
Combination of
frequency
impact
persistence (one time or repeating)
Should be calculated after all evals. are complete
Should be done independently by all judges

75. Severity Rating 0 - don’t agree that this is a usability problem
1 - cosmetic problem
2 - minor usability problem
3 - major usability problem; important to fix
4 - usability catastrophe; imperative to fix

76. Severity Ratings Example
[Heuristic “Consistency”, Severity=3]
The interface used the string "Save" on the first screen for saving the user's file, but used the string "Write file" on the second screen. Users may be confused by this different terminology for the same function.