Usability Guidelines

1
Usability Guidelines

• Jim Eales

2
Usability Guidelines

• Guidelines provide us with advice on the solution
  to design problems
• Guidelines may be based on psychological theory
  or practical experience
• Design guidelines are no substitute for user
  involvement in design and user testing

3
Design guidelines

• The word guideline has often been misused and
  many types of advice are packaged together as
  so-called guidelines
• Design principles
• Design rules

4
Design principles and rules

• Design principles are high level and widely
  applicable. Principles must be interpreted and
  applied in relation to the particular
  application.
• Reduce cognitive load
• Engineer for errors
• Maintain consistency clarity
• Design rules are low level instructions. A rule
  is an instruction that can be carried out with
  minimal interpretation.
• Dates should be formatted as DD-MM-YY

5
Smith Mosier (1 of 944)

• 1.3 DATA ENTRY Text
• 1.3/1 Adequate Display Capacity
• Ensure that display capacity, i.e., number of
  lines and line length, is adequate to support
  efficient performance of text entry/editing
  tasks.
• Example For text editing where the page format
  of subsequent printed output is critical, the
  user's terminal should be able to display full
  pages of text in final output form, which might
  require a display capacity of 50-60 lines or
  more.
• Comment A single line of displayed text should
  not be used for text editing. During text
  editing, a user will need to see some displayed
  context in order to locate and change various
  text entries.
• Reference    Elkerton Williges Pittman Roach
  1982

6
Limitations of guidelines

• Problems in selecting guidelines - It is
  sometimes hard to select the most important
  guidelines, and tempting to apply only those that
  are easy.
• Problems in applying guidelines - Guidelines are
  often stated in the minimum number of words. We
  may completely misunderstand the significance of
  the guideline.
• Problems with multiple guidelines - We often find
  that several guidelines apply to the same
  problem. The order in which we apply the
  guidelines may affect the final outcome.

7
Nielsens Usability Heuristics

• From
• Usability Engineering
• Jakob Nielsen
• Academic Press
• 1993

8
Nielsens heuristics

• Simple and natural dialogue
• Speak the users language
• Minimize memory load
• Consistency
• Feedback
• Clearly marked exits
• Shortcuts
• Good error messages
• Prevent errors
• Help and documentation

9
Illustrations

• Positive examples
• Negative examples

10
Simple and natural dialogue

• Dialogues should not contain information that is
  irrelevant or rarely needed
• All information should appear in a natural and
  logical order
• Graphic design and colour
• Less is more

11
Irrelevant information
12
Rarely needed information
13
Less is more?
14
Speak the users language

• The dialogue should be expressed clearly in
  words, phrases and concepts familiar to the user
• The dialogue should not use jargon or
  system-oriented terms
• Mappings and metaphors

15
System-oriented terms
16
The users language?
17
Minimize memory load

• 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
• Recognition rather than recall

18
Recognition rather than recall
19
Consistency

• Users should not have to wonder whether different
  words, situations or actions mean the same thing.

20
Consistency?
21
Feedback

• The system should always keep users informed
  about what is going on
• Appropriate feedback within reasonable time
• Response time
• System failure

22
Feedback - example
23
Clearly marked exits

• Users often choose system functions by mistake
• They often need an emergency exit to leave the
  unwanted state

24
Clearly marked exit?
25
Shortcuts

• Accelerators (unseen by the novice) may often
  speed up the interaction of an expert user
• Systems should cater for both inexperienced and
  experienced users

26
Shortcuts
27
Good error messages

• They should be expressed in plain language (no
  codes)
• Precisely indicate the problem
• Constructively suggest a solution

28
Whose fault?
Error 999 ILLEGAL USER ACTION JOB ABORTED
29
Whose fault?
This program has performed an illegal operation
and will be shut down. If the problem persists
contact the program vendor.
30
Prevent errors

• Even better than good error messages is a careful
  design that prevents a problem from occurring in
  the first place
• Avoid modes

31
Help and documentation

• It may be necessary to provide help and
  documentation
• Easy to search
• Focused on the users tasks
• List concrete steps to be carried out
• Not be too large

32
Task-based
33
Not too large?
34
(No Transcript)