Most practitioners of user-centered design (UCD) have a repertoire of methods that they apply to the design and evaluation of products, for example, brainstorming, card sorting, storyboards, formative usability testing, and field interviews. While these general methods serve us well, there are lesser-known variations that complement the "standard" methods. For this end-of-year column, I will suggest some techniques that you can add to your UCD toolkit in 2008. Let's begin by looking at variations on scenarios that can broaden your perspectives about how products can be used and misused.
Misuse scenarios are used to document threats toward a system. The threats may be a hostile actor (a hacker who is trying to gain entrée to a system), a safety hazard, or the attempt to achieve user goals that are not compatible with system goals. Alexander and Farncombe  describe misuse cases for seating on commuter trains that take into account how various design trade-offs (for example, armrests versus no armrests) could affect misuse. Interviews with stakeholders revealed that vandals enjoyed breaking off the armrests, but commuters liked the armrests because it put more space between "good riders" and "pests" who would abuse the norms of physical space between strangers. If you are designing a kiosk for a public space like a mall or museum, you might have misuse scenarios that focus on hoodlums who like to put superglue in payment slots, parents who put heavy packages (or large children) on the kiosk, a spilled 32-ounce Coke, or serious criminals who pose as repair persons and steal your kiosk or ATM for fun and profit. Misuse scenarios can be developed from field data, support databases, and "misuse workshops," where product stakeholders brainstorm misuse cases. Related concepts include "exception scenarios," where there is an analysis of what could go wrong at various steps in a process, and "obstacles," which are negative scenarios that describe something that hinders progress toward a goal. Obstacle scenarios point out unfortunate things that may affect how long or how much effort it takes to achieve a goal.
In my September-October 2006 column , I covered best practices for traditional group brainstorming. One variation on traditional brainstorming that is useful when you have a very opinionated or hostile group is negative or reverse brainstorming . In this variation on brainstorming, you look for causes rather than ideas or solutions to a problem or you ask participants to first brainstorm negative aspects of a topic and then, with the list of negative aspects visible, brainstorm positive ideas for each of the negative items. The basic procedure is to:
- Brainstorm on a negative topic. For example, instead of asking, "How can we improve customer satisfaction?" you might ask, "What can we do to make customers dissatisfied or angry with us?" or "How can we cause customers to be dissatisfied?"
- Identify groups of related negative comments.
- Generate positive ideas for the groups of negative comments.
The philosophy behind negative brainstorming is that it is often easier to find fault first, then use the faults as catalysts for positive ideas. I've tried this approach, which participants often greet with wry smiles, but it has proven useful for corralling unruly groups and getting them to think more broadly about possibilities for improvement.
Reverse card sorting is related to closed sorting. In reverse card sorting, participants are asked to place cards that represent navigation items onto a diagram of a hierarchy (or other structure) and, optionally, rate how confident they are about putting each card into the "right" place on the hierarchy. The average percentage of cards that are sorted into the correct level in the hierarchy would indicate how well your users understand the general navigation structure. This method is useful for validating changes to website navigation or task structures. Figure 1 illustrates a reverse card sort in which the cards from the pile at the bottom are placed on a diagram of a site map, navigation structure, or task hierarchy.
Traditional focus groups are group interviews in which a moderator guides a group of five to 12 participants, who were screened as potential users of a product, through a series of questions related to a particular topic. Unfocus groups  are group interviews in which you choose participants who:
- Are unlikely users of a product
- Have no use for the product
- Are extreme users of the product
- Have a tangential connection with the product
- Don't like a product
- Have a vested interest in the impact of the product
The goal of the unfocus group is to get a broader range of opinions and feedback about a product. Let's say you want to understand the experience of using a kiosk in a medical office to fill out a personal medical history. In a focus group, you would pick out a representative sample of people who would fill in the form. In an unfocus group, you might invite a more diverse audience, including doctors, privacy experts, functional illiterates, homeless people, people who don't speak or read English very well, someone with severe arthritis or macular degeneration, a health inspector, and a form designer. The idea here is to get much greater diversity to explore a broader range of issues than you might get with a representative sample of users. You might discover that you need:
- Taller partitions to protect privacy
- A multilingual system
- A system that self-cleans the keyboard, mouse, or alternate input device (remember this is a place where people could be contagious and spread disease through a communal system)
- A system that times out quickly when the person leaves the area so sensitive medical information isn't visible when a person forgets to log out.
- Forms that allow people with very limited reading or writing ability to save face
In many diary studies, participants are asked to record daily events in sequential order. At some point an investigator might interview the person about the diary entries and engage in some limited reflection about the broader meaning of individual entries, but more often the results are simply entered, without reflection, into some database, analysis tool, or spreadsheet. Reflective diaries ask more of participants than traditional diariesparticipants record events, activities, or situations as they occur and sometimes later reflect on what they wrote . For example, you might make diary entries about collaborative activities at work (meetings, group design discussions, use of collaboration tools for creating documents) and then, every few days, write down your reflections about what worked well or poorly, what lessons you learned, and what ideas or hypotheses might be emerging from the diary entries. A reflective diary is intended to help participants (and investigators) make connections that might not be evident just by collecting descriptive diaries of sequential activities.
Folktales are stories (sometimes called war stories) that cultures and organizations use to pass on values and lessons learned . When you start a new job, for example, you often hear folktales that reinforce corporate norms, values, and goals (there is a computer company where new employees routinely hear a story about how senior managers have to go on a retreat where they all walk across a bed of hot coals). The collection of folktales can provide insight into morale, organizational behaviors, and how people work when critical events occur. Folktales, like the one about fire walking, might, on the surface, be a story of personal bravado, but the underlying meaning is that "you will have to sacrifice a lot to work at this company." The underlying meaning of folktales may have considerable relevance in the design of systems; you can use collections of folktales to illustrate important points for colleagues who don't make it to the field, as input into personas and scenarios (including the misuse, exception, and obstacle scenarios mentioned earlier), and as indicators of important social, political, and cultural forces in organizations.
One of the issues that many of us face in UCD is insularity and a narrowing of focus the longer we work on a project. The methods listed above are a sample of simple ways to expand and refresh our design thinking. If you try these or other variations on standard methods, I would love to hear about your experience. Best of luck in 2008!
1. Alexander, I., and A. Farncombe, A. "Use and misuse cases in railway systems." In Scenarios, Stories, Use Cases: Through the Systems Development Life Cycle, edited by I. F. Alexander and N. Maiden, 347-362. Hoboken, N.J.: Wiley, 2004.
Chauncey E. Wilson
About the author
Chauncey Wilson is a usability manager at The MathWorks, instructor in the Human Factors and Information Design Program at Bentley College in Boston, and author of the forthcoming Handbook of Formal and Informal User-Centered Design Methods (Elsevier). Chauncey was the first full-time director of the Bentley College Design and Usability Testing Center and has spent more than 25 years as a usability practitioner, development manager, and mentor. In his limited spare time, Chauncey hones his culinary skills as an amateur (but very serious) chef. Chauncey is a senior user researcher at Autodesk, Inc. working on Building Information Modeling (BIM) Software.
©2007 ACM 1072-5220/07/1100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.