If you’ve been in testing for long enough, you’ll eventually report or demonstrate a problem, and you’ll hear this:
“No user would ever do that.”
Translated into English, that means “No user that I’ve thought of, and that I like, would do that on purpose, or in a way that I’ve imagined.” So here are a few ideas that might help to spur imagination.
- The user made a simple mistake, based on his erroneous understanding of how the program was supposed to work.
- The user had a simple slip of the fingers or the mind—inadvertently pasting a letter from his mother into the “Withdrawal Amount” field.
- The user was distracted by something, and happened to omit an important step from a normal process.
- The user was curious, and was trying to learn about the system.
- The user was a hacker, and wanted to find specific vulnerabilities in the system.
- The user is confused by the poor affordances in the product, and at that point was willing to try anything to get his task accomplished.
- The user was poorly trained in how to use the product.
- The user didn’t do that. The product did that, such that the user appeared to do that.
- Users actually do that all the time, but the designer didn’t realize it, so product’s design is inconsistent with the way the user actually works.
- The product used to do it that way, but to the user’s surprise now does it this way.
- The user was looking specifically for vulnerabilities in the product as a part of an evaluation of competing products.
- The product did something that the user perceived as unusual, and the user is now exploring to get to the bottom of it.
- The user did that because some other vulnerability—say, a botched installation of the product—led him there.
- The user was in another country, where they use commas instead of periods, dashes instead of slashes, kilometres instead of miles… Or where dates aren’t rendered the way we render them here.
- The user was testing the product.
- The user didn’t realize this product doesn’t work the way that product does, even though the products have important and relevant similarities.
- The user did that, prompted by an error in the documentation (which in turn was prompted by an error in a designer’s description of her intentions).
- To the designer’s surprise, the user didn’t enter the data via the keyboard, but used the clipboard or a programming interface to enter a ton of data all at once.
- The user was working for another company, and was trying to find problems in an active attempt to embarrass the programmer.
- The user observed that this sequence of actions works in some other part of the product, and figured that the same sequence of actions would be appropriate here too.
- The product took a long time to respond, the user got impatient, and started doing other stuff before the product responded to his earlier request.
And I’m not even really getting started. I’m sure you can supply lots more examples.
Do you see? The space of things that people can do intentionally or unintentionally, innocently or malevolently, capably or erroneously, is huge. This is why it’s important to test products not only for repeatability (which, for computer software, is relatively easy to demonstrate) but also for adaptability. In order to do this, we must do much more than show that a program can produce an expected, predicted result. We must also expose the product to reasonably foreseeable misuse, to stress, to the unexpected, and to the unpredicted.