We need the help of volunteers to refine and extend the content. If you are interested in contributing, please fill out the volunteer form.
A method in which one or more reviewers, preferably experts, compare a software, documentation, or hardware product to a list of design principles (commonly referred to as heuristics) and identify where the product does not follow those principles.
In discussing , many books written for practitioners reference work by Nielsen or Nielsen and Molich. (Preece, Rogers, and Sharp, 2002; Dumas and Redish, 1999; Mayhew, 1999).
While the Nielsen and Molich heuristics (or one of the modified versions developed by Nielsen with other colleagues) are commonly thought of as THE heuristics, design guidelines had been proposed long before 1990. Cheriton (1976) proposed a list of guidelines for the design of interfaces for time-sharing systems. GOMS, proposed by Card, Moran, and Newell (1983), models the user’s cognitive processes, using operator times that are derived from the results of human performance research. Norman (1983a, 1983b) proposed some basic design rules for interface design. Ben Shneiderman first presented his “Eight Golden Rules of Interface Design” in the 1987 edition of his book Designing the User Interface (Shneiderman, 1987).
Nielsen and Molich themselves place their usability heuristics within a larger context. “Ideally people would conduct such evaluations according to certain rules, such as those listed in typical guidelines documents (for example, Smith and Mosier, 1986)…most people probably perform heuristic evaluation on the basis of their own intuition and common sense” (Nielsen and Molich, 1990). Nielsen and Molich cut “the complexity of the rule base by two orders of magnitude [from a typical guidelines document] by relying on a small set of heuristics such as the nine basic usability principles” (Molich and Nielsen, 1990). This description disagrees with the description provided by Molich and Dumas, in which heuristic evaluation is described as a subset of expert reviews (Molich and Dumas, 2005). In any event, while there may not be a clear linear relationship between heuristic evaluation, guidelines documents, and expert reviews, they are certainly related.
Nielsen, J. (1989). at a discount. In G. Salvendy & M.J. Smith (Eds.), Designing and using human-computer interfaces and knowledge based systems (pp 394-401). Amsterdam, The Netherlands: Elsevier Science Publishers, B.V.
Molich, R. & Nielsen, J. (1990). Improving a human computer dialogue. Communications of the ACM. 33(3). 338-348.
Nielsen, J. & Molich, R. (1990). Heuristic evaluation of user interfaces. Proceedings of the SIGCHI conference on in computing systems: Empowering people. Seattle, WA, USA. April, 1990. 249-256.
Nielsen, J. (1992). Finding usability problems through heuristic evaluation. Proceedings of the SIGCHI conference on human factors in computing systems. Monterey, CA, USA, 1992. 373-380.
Cockton, G., Lavery, D., & Woolrych, A. (2003). Inspection-based methods. In J.A. Jacko & A. Sears (Eds.), The human-computer interaction handbook (pp. 1118-1138). Mahwah, NJ: Lawrence Erlbaum Associates, Publishers.
Molich, R. & Dumas, J.S. (2005). A comparison of Usability testing and expert reviews. In preparation.
Heuristic evaluation can be used throughout the design life cycle – at any point where it is desirable to evaluate the usability of a product or product component. Of course, the closer the evaluation is to the end of the design lifecycle, the more it is like traditional quality assurance and further from usability evaluation. So, as a matter of practicality, if the method is going to have an impact on the design of the interface (i.e. the usability issues are to be resolved before release) the earlier in the lifecycle the review takes place the better. Specifically, heuristic reviews can be used as part of requirements gathering (to evaluate the usability of the current/early versions of the interface), competitive analysis (to evaluate your competitors to find their strengths and weaknesses) and prototyping (to evaluate versions of the interface as the design evolves).
Nielsen and Molich described heuristic evaluation as “an informal method of usability analysis where a number of evaluators are presented with an interface design and asked to comment on it” (Nielsen & Molich, 1990). In this paper, they presented nine usability heuristics:
This list, and later versions (for example, Nielsen, 1994; Nielsen, Bush, Dayton, Mond, Muller, & Root, 1992), are commonly used by many practitioners as the basic heuristics for product evaluation. However, there are other published lists of heuristics available, including Shneiderman’s eight golden rules of interface design (Shneiderman, 1998), Gerhardt-Powals research-based guidelines (Gerhardt-Powals, 1996) and Kamper’s lead, follow, and get out of the way principles and heuristics (Kamper, 2002).
Heuristic evaluation is not limited to one of the published lists of heuristics. The list of heuristics can be as long as the evaluators deem appropriate for the task at hand. For example, you can develop a specialized list of heuristics for specific audiences, like senior citizens, children, or disabled users, based on a review of the literature.
The basic heuristic inspection does not involve users of the product under consideration. As originally proposed by Nielsen and Molich (1990), the heuristic review method was intended for use by people with no formal training or expertise in usability. However, Nielsen (1992) and Desurvire, Kondziela, and Atwood (1992) found that usability experts would find more issues than non experts. For some products a combination of usability practitioners and domain experts would be recommended.
The stakeholders are those who will benefit from the cost savings that may be realized from using a “discount” (i.e. low cost) usability methods. These stakeholder may include the ownership and management of the company producing the product and the users who will purchase the product.
Heuristic evaluations are generally organized by a usability practitioner who introduces the method and the principles, though with some training, other members of a product could facilitate.
The data are collected in a list of usability problems and issues. Analysis can include assignment of severity codes and recommendations for resolving the usability issues. The problems should be organized in a way that is efficient for the people who will be fixing the problems.
Discuss the usability issues with the product team. Track what problems are fixed, deferred, and viewed as “not a problem” by the product team.
There is no special equipment required for a heuristic evaluation, other than the computer or other hardware (PDA, cell phone, etc.) used to run the application. The cost will reflect the number of evaluators, their level of usability and domain expertise, and the amount of time they put into the evaluation. As originally proposed by Nielsen and Molich (1990), the heuristic review method was intended for use by people with no formal training or expertise in usability. However, Nielsen (1992) and Desurvire, Kondziela, and Atwood (1992) found that usability experts would find more issues than non experts, and Nielsen (1992) found that double experts (evaluators with usability expertise and expertise in the domain in which the software is used) will find more issues than usability experts. Short training sessions on the list of heuristics may add some costs, but make for more effective evaluations.
Molich and Dumas (2005) reported that expert reviews (which included one heuristic review) conducted for the CUE-4 study took significantly less time than usability tests, and that the expert reviews identified the same number and quality of issues.
None (unless the list of heuristics will be used to evaluate accessibility).
None (unless the list of heuristics will be used to evaluate localization issues).
For mission-critical products, the heuristic evaluation should not be the sole evaluation method for examining potential usability problems. More formal methods including summative testing and formal user interface inspections may be required to examine subtle interactions between the user, task, and product that would create serious errors.