Heuristic Evaluation

What is a Heuristic Evaluation?

The word 'heuristic' means expert. So a 'Heuristic Evaluation' of a system is an 'Expert Evaluation'. This expert evaluator uses a checklist of heuristics against which the system (website, multimedia CD ROM, windows application, washing machine) is graded.

Why Use it?

Participants Needed

Experts

4 or 5 experts needed

Sometimes is can be difficult to identify the correct expert for the evaluation. They could be any of the following:

The designer of the system

The designer of a system cannot be the expert evaluator, because they cannot see their own built in assumptions. For example, as I am writing this page I understand what I am trying to explain, but I can only be fairly certain that the readers also understand, if someone else (who knows nothing about the subject) can also understand it. Because the designer is a type of expert, they may not see problems that novice users might have with the system. The designer is also unlikely to be visually, motor or cognitively impaired and it can be impossible to then to comprehend what the system might look like from these perspectives. So the system designer cannot be the systems 'Heuristic Evaluator'.

Another designer

However, a system designer may be a Heuristic Evaluator of a system another designer has created, as they will likely see at least some of the mistakes the other designer has made. This in fact is the most usual scenario. To increase the liklihood of detecting all possible interface errors, several independant evaluators may be used. According to Jacob Nielson, the recommended number is 5. After 5, the time and cost outway the benefits of finding further errors.

A person who knows a lot about the system

A person who knows a lot about the system can also function as an expert evaluator, as they will have an expert understanding of task flows and expected system outcomes that a designer may not fully understand. These experts can catch errors and mistakes of a nature that a designer might never see.

A person who will use the system

A person who will use the system is not usually considered an expert in the system. For this reason they are not generally used for Heuristic Evaluation, although users are commonly involved with other evaluation methods such as User Testing and Task Analysis.

More than one of the above

Occasionally a person is available who is both a designer and an expert of the system being created. This person is the most likely to find the most errors and therefore are the most valuable team member during the evaluation phases.

Task List

As mentioned above, a checklist is required against which to grade the system being evaluated. The list I use consists of 13 checks, though others have 10 or 12.

  1. Familiarity of elements
    1. Use of familiar icons and layouts helps reinforce user learning and confidence
  2. Consistency of elements
    1. The interface should reinforce any expectations from previous contact with the system or other similar systems.
    2. The user should not be expected to learn one method of performing an action in one area of the system and another method of performing the same action in another area of the same, or similar, systems.
    3. There should be a consistent format for menus, messages etc.
  3. Clarity of elements
    1. On screen information must be short and relevant, but it must still make sense.
    2. Making sense to the design team is not the same as making sense to everyone else.
    3. There should be a minimum keystroke effort.
    4. Requests for input should be relevant.
    5. Output should be easy to understand.
    6. A good interface should appear to be natural, i.e. that it is a good way of performing the task.
  4. Appropriate language
    1. It should use the users words, and/or the jargon of the task, as opposed to the jargon of IT.
  5. Natural and logical ordering of information
  6. User control and freedom
    1. The system should adapt to the needs of the user not the reverse.
  7. Navigational support
    1. Where am I?
    2. How did I get here?
    3. What is happening?
    4. Where can I go next?
    5. How do I get there?
    6. What can I do?
  8. Recognition rather than recall
  9. Timely feedback
  10. Error prevention and recovery
  11. Flexibility of use
    1. The interface should accommodate differences in user requirements, preferences, and level of performance.
  12. Efficiency of use
  13. Aesthetics

 

Conditions required

Elements should be listed along with:

  1. the appropriate screen(s) / element
  2. the heuristic guideline(s) it does not comply with
  3. a description of the particular error identified
  4. a description of the user difficulty presented
  5. a suggested solution
  6. the severity of the problem - severity should be rated from 1 to 5, 5 being the most severe

The list should be ordered in descending order of severity, from most severe to least, and then by screen.

Examples

  1. Screen shots & Scenario for Heuristic evaluation of College PDA

Limitations Of method

Experts can pick up many obvious errors...
.. but ultimately the system MUST be tested with real, representative people

Exercise

Using the screen shots and scenario given, and the Heuristic Evaluation Sheet (.doc) / Heuristic Evaluation Sheet (.rtf), complete a heuristic evaluation of PDA screen designs for a Gastro-Intestinal unit

Reading

. CSS . XHTML . WCAG AAA .

created & designed by Vivienne Trulock for ilikecake