Method 10 of 100: Perspective-Based Inspection

100 User Experience (UX) Design and Evaluation Methods for Your Toolkit

by Chauncey Wilson

This is the 10th in a series of 100 short articles about UX design and evaluation methods. This means that this series of short postings on methods is now 10% complete and there are only 90 or so weeks until the toolkit project is complete. Today’s milestone method is the perspective-based inspection. A perspective-based inspection is a user interface evaluation method where the evaluators are asked to adopt a specific perspective as they examine a product for problems. For example, I might ask members of my UX team to review a product from the following perspectives:

• Consistency czar – this person looks for any consistency issues with the product.
• Disabled user – this person would role play a person with specific disabilities and note where the product is not accessible.
• Psychologist – this person would look for violations of psychological principles related to memory, learning, attention, fatigue, interruption, persuasion, etc.
• Super power user – this person would look at issues of efficiency, shortcuts, and aspects of the product to support the very expert and frequent user.
• Error expert – this person would focus on areas where users might make errors and places where the system could support error prevention.
• Artist – this person would look for problems with aesthetics like clutter, poor user of color, graphics that look amateurish, and ugly icons.
• The Keyboarder – this person does not use the mouse and evaluates a product for complete keyboard access.

While each person has a specific focus for the inspection, any person can report any issue.

Method 10 of 100: Perspective-Based Inspection

When to Use:

Perspective-based inspections are useful for broadening the problem-finding ability of both experienced and inexperienced evaluators. For example, if your team was composed of mostly young people, you might ask one or more team members to adopt the perspective of an elderly person. Adopting a perspective might involve reading about issues with older users, simulating the effects of aging by wearing glasses that blur vision, or spending time with some older users before the inspection to understand some of the issues they might face. Since I’m now 60 and officially old by some measures, I am aware of the issue with tiny text and that might be something a younger colleague would miss.

Personas can also be the source of different perspectives and a persona-based evaluation would be a variation on the perspective-based inspection. Perspective-based inspections of current or competitive products can be a source of requirements as well as problems. You might note in the requirements definition phase how well a product supports particular perspectives. This type of UX evaluation is good when you need a quick review, don’t have easy access to the necessary users, and are lacking travel budget. You can do this type of review at any time during the development cycle, from requirements to finished product. 

Procedure:

1. Define the perspectives that are important for the product or service you are developing. Some of the things to consider are:
   1. Existing personas. Each persona will have a different perspective.
   2. Frequency of use by users. Two perspectives that I’ve used are the “really naive user” and the “product guru”. One perspective gets at learnability while the other focuses on efficiency.
   3. International users. These users could be colleagues from other countries who would look at issues with icons, idioms, metaphors, layout, etc.
   4. Users with disabilities.
   5. Angry users of the current product.
2. Provide some background about the perspectives and consider ways to understand the perspective better. If you were simulating an elderly user, you might have the evaluator read several studies that describe user experience issues that confront elderly users. If there are particular heuristics or checklists for the perspectives, make those available to the team.
3. Define the tasks, goals, and specific characteristics that are important for each perspective.
4. Provide the inspection team with the forms to record the issues and problems they find.
5. Conduct a short training session to review the perspectives, procedures, and reporting forms.
6. Have the evaluators conduct their inspections of the product independently.
7. Pull all the issues together from the independent inspections and review the issues with the entire team to clarify the data and prioritize the findings.

Strengths and Weaknesses:

+ The method is relatively inexpensive.

+ This method can be conducted by evaluators at different sites.

+ The method broadens the types of problems that emerge.

+ The method can be accomplished using a variety of online tools.

- Some perspectives may be difficult to assume. For example, I once worked on a project where one of the perspectives was that of an elderly Nobel Prize winner and taking on that perspective required some effort.

- The evaluators have to be open to adopting different perspectives; some colleagues may have difficulty with role playing.

References:

A Perspective-based Technique for Usability Inspection. http://www.cs.umd.edu/projects/SoftEng/ESEG/topics/usability.html

Redish, G., Chisnell, D., & Lee, A. A new take on heuristic evaluation: Bringing personas, tasks, and heuristics together with a new model for understanding older adults as users. http://www.redish.net/content/talks.html.

Zhang, Z., Basili, V., and Shneiderman, B., Perspective-based usability inspection: An empirical validation of efficiency, Empirical Software Engineering 4, 1 (March 1999), 43-69.

---

What’s Next in the Series?

The next UX method posting will be a surprise. : )