Your User Is Not You

The title of this post, “Your User Is Not You”, is cheerfully cribbed from a fellow named David Platt, who wrote a pointed and very funny book called Why Software Sucks…and What You Can Do About It. He also gave a terrific talk at SD West 2007, excerpts of which you can see here and here. Attending that talk was one of the highlights of that year for me.

Today some of us on Twitter were discussing Twitter’s “Favorite” feature. I realized that some people use Twitter favorites to indicate approval of tweets, and that others use it to save the tweet for later reading or review. Colleague Ben Simo (@QualityFrog) said “For me, Twitter favorites are like IE favorites: bookmarks to help me find things later.” George Dinwiddie (@gdinwiddie) said, “‘Favorite’ can also mean a positive acknowledgement of a tweet not felt worth retweeting.” Tracy Harms startled some of us by saying “I know it’s used sometimes to signal recognition, sometimes approval, sometimes dislike (my emphasis).” Later, Tracy added “Marketing often involves calling something by an inspiring name rather than a dryly accurate label.”

That’s true. And people respond both to inspiring names and to dryly accurate labels in their own ways. People not only observe or use relationships between things; they develop those relationships (that’s an important theme of the book Surfaces and Essences: Analogy as the Fuel and Fire of Thinking, by Douglas Hofstadter and Emmanuel Sander.)

All that is why David Platt’s talk and book were so significant. To me, the two most important points of his talk for testers were 1) “Know thy user, for he is not thee”; and 2) “People don’t want to use your software; they want to have used your software.” Some people may want to do something; others may simply want to get something done, which is subtly different, and which has important implications for testing. In order to get things done, people will use products in ways that their designers and developers did not intend or anticipate. Sometimes what we infer from observable behaviour is not what someone else intended to imply, or to do. This doesn’t apply only to end users, either. Even within a development shop, the function or object or library or API developed by one person or group for some purpose may get used by other people in a surprisingly different way, or for a strikingly different purpose.

That’s why, when you’re testing, it’s so important to learn about your users; about their purposes; about competitive products and their features; and about the importance of parallels, analogies, and metaphors. That’s why it’s important to create and maintain good relationships with customers and with vigilant, helpful technical support people who talk with your customers. That’s why it’s important to develop, as Jerry Weinberg says, “a suspicious nature and a lively imagination”: our big challenge is to test not only for reliability but also for adaptability; not only for what happens, but what could happen; not only for what people are expected to do, but what they might do. Learning about those things—and reporting on them—can help our clients to decide whether the product they’ve got is the product they want.

A related post: Why Would a User Do THAT?