100 User Experience (UX) Design and Evaluation Methods for Your Toolkit
This is the 15th in a series of 100 short articles about UX design and evaluation methods. Today’s method is the “misuse scenario”. This is a method that focuses on possible misuses, both unintentional and malicious, of a system.
Method 15 of 100: Misuse Scenarios
Scenarios are used to focus product teams on user needs in specific contexts. There are a variety of scenario types that you might consider in design. Here are a few general categories:
- Typical scenarios - These scenarios focus on common tasks and contexts encountered by the major personas.
- Atypical scenarios - These are infrequent, but sometimes important, scenarios. An example here would be the scenario for the recovery of information after a major and extended power failure. Recovery after a disaster is rare and an atypical scenario might describe this rare event (sometimes called a “black swan”) and how it would be handled.
- Extreme (but not misuse) scenarios - Extreme scenarios often focus on scalability issues like what happens to a Web site when a particular event results in quadruple the number of people expected by the requirements document pounding your server.
I would add misuse scenarios to this list. Misuse scenarios might deal with events like vandalism or inadvertent damage.
- Vandals put superglue in the slots for credit cards, receipts, and stamps. (malicious misuse).
- Parents put their infants on the scale designed to weigh packages of no more than 15 pounds (unintentional misuse).
- A slightly intoxicated couple spills a drink during the science museum’s New Year’s gala (unintentional misuse).
- People with the flu and other diseases handle the mouse and touch screen in a health clinic (inadvertent contamination of public computer systems).
- An evil person gathers information from a web browser at a library that wasn’t cleared after someone left quickly to deal with a home emergency (malicious misuse).
- The software is being used for something completely unintended (could be malicious or not).
When to Use
Misuse scenarios are probably something to consider on any project where there is potential for someone to perform either malicious actions or actions that result in an unintentional, but unfortunate damage to a person, organization or the product itself.
This method can be used early in the product design and development process as part of requirements gathering and conceptual design. Including misuse scenarios in the UX design process could lead to a system design that would minimize the damage caused to the system itself.
- Consider typical or atypical scenarios or common use cases and convert them to misuse cases.
- Tap field support or technical support colleagues and ask them to recount stories related to misuse of a similar product or system.
- Consider aspects of the environment that might interact with the system and users to create a misuse scenario.
- Brainstorm with a range of colleagues about “how could things go wrong with our system?”
- Create a matrix of misuse cases and brainstorm ways to eliminate or mitigate any threats.
Strengths and Weaknesses
+ There are often stories and bug reports that can be used to develop misuse scenarios. Using misuse scenarios strengthens the likelihood that the entire user experience is considered during design.
- Misuse scenarios can be quite vivid and may prompt design teams to go overboard in designing against misuse.
Alexander, Ian. Misuse Cases: Use Cases with Hostile Intent. Retrieved on June 29, 2011 from https://perceval.gannon.edu/xu001/teaching/2010spring/GCIS504/termpaper/readingList/MisuseCasesHostileIntent.pdf
Alexander, Ian, Use/Misuse Case Analysis Elicits Non-Functional Requirements, Computing & Control Engineering Journal, Vol. 14, 1, pp. 40-45, February 2003
Wikipedia. Scenario. Retrieved on June 29, 2011 from https://en.wikipedia.org/wiki/Scenario_(computing)
What’s Next in the Series?
The next UX method posting will discuss backcasting, a technique for generating a vision of a desirable future and then working backwards to see what is needed to get to that desirable future.