Download ‘printer-friendly’ PDF version (File size: 12 KB)
A Usability Review (more formally known as ‘Heuristic Evaluation’) is a technique for identifying usability issues.
A Usability Review:
- Is cheaper to conduct than formal usability testing
- Can be completed in a very short period
- Can be conducted at any stage of the design.
Usability Reviews are somewhat subjective, because no real users are involved.
When is Usability Review appropriate?
A Usability Review is particularly appropriate if an application has a large number of serious usability problems, or if an application is not sufficiently mature for usability testing with real users.
In a hostile environment, a Usability Review is open to the accusation of being only one opinion against the opinion of others. In such circumstances, consider usability testing instead.
How is a Usability Review conducted?
At least two people should independently review the application, to maximize the number of issues identified.
In general, avoid being given a walk-through of the application before beginning, as it is best to approach the task with a fresh and un-biased viewpoint. However, you should know:
- The purpose of the application
- The characteristics of the intended users and their levels of domain knowledge
- The context of use.
Before you start, create a working document for your notes. This allows you to capture first impressions, which you may not readily recall once you have begun working with the application.
Once you begin your review, use a standard notation for capturing issues. For each issue, note:
- An exact description of the issue. Write this in the voice that you will use in your report, to facilitate subsequent ‘cutting-and-pasting’ with a minimum of re-writing.
- The usability principle (heuristic) violated
- An estimate of severity.
- Error handling
- Visual clarity.
You should be able to explain precisely why you consider each issue to be relevant from a usability perspective – avoid personal opinions that may be grounded in prejudice.
When you have finished listing issues, use a checklist to make sure you have considered the application in sufficient detail. A checklist example is available.
Combine and print the issues from each reviewer, and use affinity diagramming to group like issues together. This should give you the basic structure for the body of your report.
Review your working notes to ensure that all the issues you noted have been included as issues.
Review the checklists to see if all reviewers are in agreement, and examine any discrepancies.
Reporting your findings
Make sure you acknowledge the positive aspects of the system under review – remember that some readers may be hostile to or upset by your findings.
Give careful and reasoned comments.
Provide clear recommendations. Decide whether the application can be ‘patched’, or whether more fundamental changes are required.
The first part of the report should summarize your findings. Do not expect all readers to have time to go through the issues in detail. An example report is available.