Design Heuristics

1. Simple and natural dialogue

Dialogs should not contain irrelevant or rarely needed information. Every extraneous unit of
information in a dialog competes with the relevant units of information and diminishes their
relative visibility. All information should appear in a natural and logical manner.
• Simplify as far as possible, reduce items to be learnt and remembered.
• Provide as much information as is needed (and no more) when and where it is
needed.
• Interface should match task : provide a natural mapping between user concepts and
computer system concepts.
• Sequence of operations should match the way users would naturally do things.
• Allow user control of sequences of events.
• Use appropriate graphics and colour.

2. Speak the user’s language

The dialog should be expressed in words, phrases, and concepts familiar to the user rather
than in system oriented terms.
• Stick to user’s perspective.
• Avoid restricting naming conventions
• Use metaphors where appropriate.

3. Provide clearly marked exits

A system should never capture users in situations that have no visible escapes. Users often
choose system functions by mistake and will need a clearly marked "emergency exit" to leave
the unwanted state without having to go through an extended dialog.
• All dialogue boxes should have cancel/escape
• Use un-dos
• Allow interrupts

4. Provide short cuts

The features that make a system easy to learn such as verbose dialogs and few entry fields on
each display are often cumbersome to experienced users. Clever shortcuts, unseen by the
novice user, may often be included in a system such that the system caters to both
inexperienced and experienced users.
• Allow frequently used operations to be performed rapidly.
• Use abbreviations, function keys etc..
• Reuse interaction history.
• Use default values.

5. Minimise user memory load

The user's short-term memory is limited. The user should not have to remember information
from one part of the dialog to another. Instructions for use of the system should be visible or
easily retrievable whenever appropriate. Complicated instructions should be simplified.
• Recognition is easier than recall, exploit computer’s ability to store.
• Use dialogue boxes to allow selection of options.
• Use default values to show typical values or formats.
• Provide hints as to valid input, i.e. ranges.
• System should be based on a small number of pervasive rules.
6. Good error messages
Good error messages are defensive, precise, and constructive. Defensive error messages blame
the problem on system deficiencies and never criticise the user. Precise error messages
provide the user with exact information about the cause of the problem. Constructive error
messages provide meaningful suggestions to the user about what to do next.
• Should be phrased in clear language
• Should be precise
• Should be constructive.
• Should be polite.
• Use multiple levels.

7. Be consistent
Users should not have to wonder whether different words, situations, or actions mean the
same thing. A particular system action when appropriate - should always be achievable by
one particular user action. Consistency also means co-ordination between sub systems and
between major independent systems with common user population.
• A specific command or action should always have same effect.
• Format information consistently on all screens and dialogue boxes.
• Be consistent with other interfaces (where appropriate).

8. Prevent errors
Even better than good messages is a careful design that prevents a problem from occurring in
the first place.
• Use selection in preference to typing.
• Confirm commands.
• Avoid commands that are too similar

9. Provide feedback
The system should always keep the user informed about what is going on by providing him or
her with appropriate feedback within reasonable time.
• System should continuously inform the user what it is doing, and how it is interpreting
user input.
• Don’t wait for errors ( positive feedback, partial feedback)
• Avoid abstract and general terms.
• Vary persistence appropriately.
• Warn of system response times where appropriate.
Nielsen's Revised Usability Heuristics
Nielson revised the original list of Heuristics to a form more natural to learn, remember and use:

1. Visibility of system status

The system should always keep users informed about what is going on, through appropriate
feedback within reasonable time.

2. Match between system and the real world

The system should speak the users' language, with words, phrases and concepts familiar to the
user, rather than system-oriented terms. Follow real-world conventions, making information
appear in a natural and logical order.

3. User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency
exit" to leave the unwanted state without having to go through an extended dialogue. Support
undo and redo.

4. Consistency and standards

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

5. Error prevention
Even better than good error messages is a careful design which prevents a problem from
occurring in the first place.

6. Recognition rather than recall

Make 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.

7. Flexibility and efficiency of use

Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert
user such that the system can cater to both inexperienced and experienced users.
Allow users to tailor frequent actions.

8. Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra
unit of information in a dialogue competes with the relevant units of information and
diminishes their relative visibility.

9. Help users recognise, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the
problem, and constructively suggest a solution.

10. Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary
to provide help and documentation. Any such information should be easy to search, focused
on the user's task, list concrete steps to be carried out, and not be too large.
Conducting an Heuristic Evaluation

Use 2 - 3 evaluators
Difficult for one individual to find all usability problems.
Different People find different problems.
Little pay back from using more than five evaluators

Each Evaluator inspects interface alone

Ensures independent and unbiased evaluations.

Evaluate
1- 2 hours
Inspect features at least twice (1 = get a general feel, 2 = Focus)
Usage scenario ( based on task analysis of actual users)

Output
List of usability problems.
Reference to specific heuristic + explanation of violation

Record results
Written reports from each evaluator (provides a formal record)
Or use an observer:
Additional overhead
Usually quicker (one set of personal notes)
Can provide assistance (unstable prototype, domain expertise)

Debriefing session
Useful as evaluation provides no systematic way to generate fixes.
Include evaluators, observers, and design team.
Brainstorm - discuss possible redesigns
Focus on positive aspects.