This semester I am taking a User Interface Design course (CIS577). As part of the course work, we have been required to review articles that have been published. The below review is from two articles published in 1992 and 1994, although I believe they make points that are relevant today.
Ref: Neilson, J. Finding Usability Problems Through Heuristic Evaluation. In Proc. CHI '92, ACM Press (1992), 373-380.
Ref: Rettig, M. Prototyping for Tiny Fingers. In Communications of the ACM 37, 4 (April 1994), 21-27
Review of Finding Usability Problems Through Heuristic Evaluation and Prototyping for Tiny Fingers.
The two articles reviewed are both over fifteen years in age. However, the underlying points made by the authors of each article are as useful today as they were at the time of the writing. Finding Usability Problems Through Heuristic Evaluation (Finding) was written by Jacob Neilson of Bellcore for the 1992 Association of Computing Machinery’s (ACM) Computer Human-Interaction Conference. Prototyping for Tiny Fingers (Prototyping) was also produce for the ACM, specifically written by Marc Rettig for the April 1994 Communications of the ACM. Both articles focus on [the author’s] recommended techniques for the evaluation and utilization of user interface (UI) prototyping. Two links exist between these two articles: (1) not so blatant is the link found in the discussions of paper prototypes compared to [full] running system prototypes, and (2) Rettig makes use of, and reference to, Neilson’s Funding. As Rettig presents a the more straightforward suggestions, as compared to the higher level of Funding, it is therefore more germane to discuss Rettig’s work first.
In Prototyping, Rettig thoroughly discusses his belief in the value of Lo-Fidelity (Lo-Fi) prototypes. Lo-Fi prototypes, as explained by Rettig, are UI prototypes that are constructed of paper and manipulated through an individual “playing the computer.” To present his support of Lo-Fi prototypes, Rettig first takes the natural path of explaining what he defines as Hi-Fidelity (Hi-Fi) prototypes consist of: fully functioning prototypes created through the use of modeling tools and/or high level programming languages. Through his defining of Hi-Fi prototypes, Rettig presents a concise set of problems/risks that are inherent in this method of prototyping: Length of build/change time, Reviewers tend to focus on “fit and finish” issues such as color choices and font, Developers resistance to change, Setting of unrealistic expectations, and, One bug can bring the project to a halt.
Once Rettig presents the issues that he believes are typical (and cost-inducing) of Hi-Fi prototyping, Rettig explains how his organization had come to use the Lo-Fi method and the benefits that they (he) had identified in its usage. His introduction to Lo-Fi is not important. However, the benefits of its use that he has articulated are well worth some discussion.
The primary benefit, according to Rettig, of Lo-Fi prototypes is that of cost, in terms of both time and money. Rettig presents a reasonable and efficient procedure, as well as [his] recommended material that allow for a development team to construct prototypes that allow for both effective end-user evaluations as well as low cost changes. This procedure is one that allows for a component based paper prototype to be quickly created, have parts duplicated where necessary, and have the user evaluation results created/documented in a manner that can successfully drive the necessary documentation and changes.
Rettig does an excellent job in explaining the benefits of Lo-Fi prototyping as well as the established set of procedures that he and his coworkers followed. It should be noted that Rettig also makes the points of: (1) If you already have a working Hi-Fi prototype then it should not be scrapped for a Lo-Fi prototype as it would not be cost effective, and (2) Hi-Fi prototypes have their place in UI design but every developer should at least attempt to utilize a Lo-Fi methodology in order to compare for themselves the possible benefits that may be gained from its usage. These benefits can be traced to heuristic evaluations of prototype reviews and empirical evidence garnered from these evaluations.
One of the sources for Rettig’s belief in the benefits of Lo-Fi prototypes is Neilson’s Finding, in which Neilson examines the use of heuristic evaluations during prototype review processes. Neilson presents here an enumeration of three primary types of reviewers as well as an articulation as to when heuristic evaluations did, and did not, prove to be efficient.
The effectiveness of Neilson’s discussion of heuristic-based evaluations can be found in the three primary groups of reviewers that Neilson used. The three groups identified and used by Neilson were: Novice, Regular, and Double. The Regular (a general usability expert) and the Double (a usability expert that specialized in the field of focus) were often expensive to employ and not always available. Due to this fact, Neilson identified and used a third group of reviewers: Novices (those with no usability evaluation experience).
The interface chosen by Neilson to test and present his evaluation was that of a telephone banking system. This interface was similar to many of the same types in use today. For the purposes of his evaluation, Neilson gave each evaluator a list of tasks that should be performed using the system. This set of tasks and the given interface allowed for Neilson to categorize the results.
The results produced by Neilson’s evaluation were able to be categorized into two primary groups: Major Problems and Minor Problems. In addition to this grouping, focal areas were identified as well as the benefits of paper or system prototypes in a given evaluation step.
Neilson’s conclusions were predominantly expected: (1) usability specialists were able to utilize heuristic evaluations to identify problem areas more than novices were able to identify, and (2) usability specialists with specific expertise were the best suited to utilize heuristic methods in interface prototype evaluations. Of interesting note is that Neilson’s recommendation of 3-5 evaluators on one project appears to be the basis of Rettig’s belief that no more than four team members should be used (and in differing capacities).
In reading both Prototypes and Finding it is apparent that there is no single method that best allows for a complete evaluation of a user interface. Both Hi-Fi and Lo-Fi have their requisite places, as do the differing heuristic areas presented by Neilson. This was as true 19 years ago as it is for today’s software developer. A developer, or even a program manager, would be well-cautioned to learn multiple methods and to attempt to implement the one that best addresses the project being evaluated.
No comments:
Post a Comment