Chapter 2. What Do Users Want? (and Where, and When, and Why?)

Now that we know who our users are, we turn our attention to what they want to do. What problems are they trying to solve, or what pleasurable state are they trying to enter?

In this chapter we see how to interview users to find out the answers to these and other questions. We also learn how to express them to the development team in the form of stories.

We will do something similar in this chapter. We will figure out what our users really want or need from their software. What problem are they trying to solve, or what pleasurable state do they want to enter and maintain? And what would they consider to be the characteristics of a good solution or a good pleasurable state? We will then express this information in a format that our development team can digest and use: a story.

Did you think that being a UX geek was about programming? Wrong, my friend. For the first part of this process, we will be thinking like doctors. And for the second part, we’ll be thinking like fiction writers.

After this, and only after this, can we start to say, “OK, now that we know who our users are and what they want, how close can we get to that with the technology that we have?” We will discuss this progression in later chapters.

This isn’t a new problem. In my first-ever industrial job, my boss circulated a poem entitled “The Night before Implementation.” It ended with these lines:

And the user exclaimed with a snarl and a taunt,
“That’s just what I asked for, but not what I want!”

That was 30 years ago, half the lifetime of the computing industry, and it probably wasn’t new then.

Users have valuable information for us. Their satisfaction, and concomitant willingness to hand over their money, is our ultimate quality metric. But they don’t know how to access and express that information in terms of UX, in the same way that medical patients don’t know how to diagnose their own diseases. They can tell you if something feels good or bad once you ask them. But pulling the correct diagnosis out of the void isn’t their problem. It’s ours, trained professionals that we claim to be.

Think about it. When a patient goes to the doctor, he doesn’t usually say, “I think I have type C fulminating leprosy, Kaminski variation.” No. He says something like “Ow, my elbow hurts.” It is the doctor’s job to figure out what is causing the patient’s elbow to hurt: did he bang it on something, or is cancer eating away at his bones, or is his wife cheating on him and he’s displacing anxiety? Then, and only then, can the doctor decide whether to prescribe ibuprofen and ice packs, surgery and chemotherapy, or a divorce.

The patient doesn’t know which pieces of information are important, or how to relate one piece to another. It is the doctor’s job to ask the right questions (Figure 2.1): “Describe the pain for me. When did your elbow start hurting? What were you doing then? Does your other elbow hurt too? Does it hurt when I bend it this way? That way?” Lab tests and imaging may confirm the doctor’s hypotheses, but all diagnosis stems from interviewing and examining the patient. This is a difficult skill to learn, and doctors who can do it well are good doctors.

So it is with us and our users. They don’t come to us saying, “Jeez, I wish some animated character with bushy eyebrows would pop up at random intervals and say, ‘It looks like you’re about to crash. Don’t you think you ought to save your work?’” Like the medical patient, our users express their feelings as best they can, usually beginning in a very general way, such as “I want to kill those bastards!” It is our job to ask the right questions to make the diagnosis, to figure out what’s really hurting them so that we can make it stop. “Which bastards did you have in mind? What did they do specifically today to make you want to kill them?” and so on. Eventually, through our careful and patient probing, we can get the users to move past their immediate rage to identify its root causes: “I worked for three hours; then up came this stupid box saying, ‘Microsoft Word has encountered an error and needs to close,’ and all my work was gone.”

This is a difficult skill to learn. User experience designers who can do it well are good designers. If there is one topic in this book in which success depends on experience, it would be this one. This chapter will start you in the right direction. But more than anything else in this book, it takes practice, practice, practice.

It sometimes happens that you can’t talk to your actual users. You wish you could, you know the outcome would be better, but damn it, you just can’t get the access. For example, in the consulting business, it’s (depressingly) common that the customer’s IT team that is running the project will block direct access to users. They want to control the transaction, filtering everything through themselves, building what they want, rather than what the users want. Sometimes the users’ boss is the obstacle.

I call this the “third-party problem”: the party that’s writing the check isn’t the party using the software. Sometimes I call it the “Golden Rule problem”: the guy with the gold makes the rules, and those rules get in your way. It’s a tough problem, and you may never completely solve it, but here are workarounds with which you might find some success.

You need to come up with some sort of user representative or surrogate. Sometimes you can get the user population to delegate one. The thing you need to watch out for here is that often a person volunteers as a representative because she’s a technophile—she’s interested in software, she likes participating in the process; that’s why she volunteered. The results that you get from her will then be skewed toward the technophilic, not necessarily the mainstream of your user group. Perhaps you can rotate the role of representative—this week it’s one person, next week it’s another. The changes can be disorienting at first, but you’ll soon get an idea of the commonalities and variations within your user population.

Sometimes the users are just too tired to talk to you. This happens with industrial applications. These guys get off work and all they want to do is get out of the building and grab a cold brew. They don’t want to spend time talking to some pointy-headed geek. You see this in the medical sector as well, where hours of unpaid overtime are depressingly common. In this case, finding their watering holes and buying a round of beer can get you started. After they’ve had a drink or two, asking, “What really burns you about XYZ software package?” will open the floodgates. In vino veritas, as they say.

If worse comes to worst, you can try hiring an outside subject matter expert. I was working on a medical application once and for a variety of reasons couldn’t get to the actual users. I knew a nurse, who was employed at a different medical outfit and did the same sort of thing that the target users did. I offered to pay her to pick her brain about it. She found a few hours of moonlighting at consulting rates to be a much appreciated windfall. She’s good at what she does, so perhaps our solution will contain an improved workflow.

Above all, you have to get them started talking. Start by making your questions open-ended. Doctors are trained to open the conversation thus: “What brings you here today?” Following are some of the ways I get things moving:

Tell me about yourself and your role here at Company A.

What’s the biggest problem you’re trying to solve?

What do you foresee as the biggest risks?

What worries keep you awake at night?

Tell me what really bothers you about (whatever).

As you continue the interview process, you will need to drill deeper. You still want to keep the questions as open-ended as possible, so as to get the maximum information from the user. Suppose you are developing a Web site for job searches. You might say, “Tell me about your new job.” That will allow the user to tell you the types of things that matter to him. He might say something like “My kids are in the public schools, so I’m not willing to relocate. I’m looking to see what’s within 20 or 30 miles of my house. Either that, or if they have really good telecommuting.” You’ve gotten two pieces of information here: the sorts of things that cause a user to stay put, and one plausible alternative. If you had asked, “Do you want to search by title or salary range?” you wouldn’t have learned either of these. Now that the user has opened this line of discussion, you probably want to follow up with something like “Interesting. Tell me more . . .” before moving on to another topic.

Be careful not to signal the answers that you want. You may well get the answer that you signal, but that answer may not be true. Here’s one I got wrong back around 2004:

Me: Haven’t you always wanted your cell phone to give you driving directions?

My mother: Nope. I can usually figure out where I am without much trouble, and if not, I ask someone. They often give me a nice cup of tea, too. I know you want me to say yes because you think it’s so cool, but I don’t really care. Sorry.

Someone less truthful than my mother, or perhaps more sparing of my feelings, would have reflected my enthusiasm and said, “Sure, that sounds kind of cool,” even though she really didn’t think so. And I’d have gone charging off after the wrong thing, at least for that demographic. (Obviously, a decade later, this technology has become ubiquitous on our smartphones.)

You will eventually narrow it down to more specific questions. As you do so, try to avoid misunderstandings caused by ambiguity. Don’t ask, “Do you buy many music CDs nowadays?” Neither of you is sure how many CDs constitute “many.” Instead, you might ask, “How many physical music CDs did you buy in the last six months? How many MP3 tracks?”

1. This quote appears in the title of Mr. Berra’s book about teamwork (Wiley, 2009). It isn’t one of the faux Yogiisms, to which his autobiography, The Yogi Book: I Really Didn’t Say Everything I Said, refers (Workman, 1999).

Watching users comes in two flavors: hidden and open. We’re all familiar with the former. Many workers labor under the gaze of surveillance cameras more or less all day: bank tellers, cashiers, pharmacists, and many others (Figure 2.3). And many of our public spaces are under constant observation as well: shopping malls, transit centers, and so on. You can get a lot of objective information from watching these tapes—how many men and how many women got on a particular train, for example. You could do a time-and-motion study on the pharmacist—how often she went to this shelf, or to that one. It’s one way to look at things and has some value. But for what we want to know, this isn’t the best. The best comes from observing the users as they’re doing their work, and talking with them about it.

This is open observation. In this case, you sit with the user and watch while she uses her current software. You can talk to her, and ideally get her to explain what she’s doing and why (Figure 2.4).

This is what my European student did with his users. He sat next to them as they used the old system, asking, “What are you doing now?” They were happy to answer his questions, once they understood that he wasn’t there to criticize them and their lack of computer literacy. He found that they didn’t use the system all that often, so they didn’t remember any sort of shortcuts. The interface had to be obvious to them every time, and the existing one wasn’t. “We don’t like this,” they said. “It doesn’t work like any other app we use. We don’t use it all that often, so we have to figure it out again every time.” My student was able to ask, “Do you think you’d rather scroll up and down on a single page, instead of jumping back and forth to different pages as it currently does?” to which the answer was a resounding “Yes!”

In some ways, this open observation resembles the usability testing we’ll discuss in Chapter 4. You’re sitting next to the user and watching while she uses the software. It’s different in that here you’re not assigning a task, as you do in usability testing. You are looking at what the user currently does. Also, the conversations with the user here are more two-way. In the usability test case, you ideally want a test run unpolluted by any outside output. In the current case, you are looking to see how the user manages to live in the polluted water.

There are two primary ways in which we could express user requirements. We could use a prescriptive approach, specifying every detail of what the geeks are to code. Specifications exist for this, such as IEEE-830:

4.6) The system shall allow a company to pay for a job posting with a credit card.

4.6.1) The system shall accept Visa, MasterCard, and American Express cards.

4.6.2) The system shall charge the credit card before the job posting is placed on the site.

4.6.3) The system shall give the user a unique confirmation number.

This approach has several problems. First, simply creating and manipulating the formal structure consumes a great deal of time, like a flowchart. Also, it’s hard to add new pieces as they arise, and they always arise. Invariably, as we will see, the user sees the first few pieces and says, “That’s just what I asked for, but not what I want.” It’s hard to move things around once you’ve put them in.

The biggest problem, though, is that it’s written from the system’s point of view, rather than the user’s point of view: “The system shall do [this].” We’re not writing software for systems to use. We’re writing for users. As you’ll remember from the introduction, Avon had to junk a $125 million system because its UX was so awful that prospective users quit the company rather than touch it. A weasel spokesman said that Avon’s order management system “is working as designed, despite any issues with the implementation of this project.” That’s what happens when you work from the system instead of the user.

This prescriptive approach is similar to the requirements of sacrificial practice laid out in the first book of Leviticus:

³ If the offering is a burnt offering from the herd, you are to offer a male without defect. You must present it at the entrance to the tent of meeting so that it will be acceptable to the Lord. ⁴ You are to lay your hand on the head of the burnt offering, and it will be accepted on your behalf to make atonement for you. ⁵ You are to slaughter the young bull before the Lord, and then Aaron’s sons the priests shall bring the blood and splash it against the sides of the altar at the entrance to the tent of meeting. ⁶ You are to skin the burnt offering and cut it into pieces. ⁷ The sons of Aaron the priest are to put fire on the altar and arrange wood on the fire. ⁸ Then Aaron’s sons the priests shall arrange the pieces, including the head and the fat, on the wood that is burning on the altar. ⁹ You are to wash the internal organs and the legs with water, and the priest is to burn all of it on the altar. It is a burnt offering, a food offering, an aroma pleasing to the Lord.

What can we do instead? We could start working from the user rather than the system. You describe the situation from the users’ point of view, describing the participants, their actions, and the results. Continuing the biblical analogy, think of the parable of the Good Samaritan, here from the Gospel of Luke, Chapter 10:

²⁹ [An expert in law] asked Jesus, “And who is my neighbor?”

³⁰ In reply Jesus said: “A man was going down from Jerusalem to Jericho, when he was attacked by robbers. They stripped him of his clothes, beat him and went away, leaving him half dead. ³¹ A priest happened to be going down the same road, and when he saw the man, he passed by on the other side. ³² So too, a Levite, when he came to the place and saw him, passed by on the other side. ³³ But a Samaritan, as he traveled, came where the man was; and when he saw him, he took pity on him. ³⁴ He went to him and bandaged his wounds, pouring on oil and wine. Then he put the man on his own donkey, brought him to an inn and took care of him. ³⁵ The next day he took out two denarii and gave them to the innkeeper. ‘Look after him,’ he said, ‘and when I return, I will reimburse you for any extra expense you may have.’

³⁶ “Which of these three do you think was a neighbor to the man who fell into the hands of robbers?”

³⁷ The expert in the law replied, “The one who had mercy on him.” Jesus told him, “Go and do likewise.”

When asked the technical question of who exactly is a neighbor, Jesus didn’t reply with a specification. One who lives next door? A blood relationship out to second cousin once removed? No. He told a story. He used a specific example, hypothetical actions of fictional characters, to illustrate a general principle. He invited the listener to place himself in the shoes of the characters to think about what the underlying principle meant. It’s an extension of the persona principle, whereby we concocted an artificial person to illustrate our user population. We will now give these personas actions and results to describe the needs of our user population. We will tell stories.

The term story gets thrown around a lot in the UX business. It’s a very generic word. As always, when a generic word gets used to label a specific situation, no one agrees on exactly what the thing is or isn’t. (Object is the classic example.)

So it is with the term story. One development shop calls a certain thing a story, but to a different shop, “No, that’s not a story. That’s a use case [or maybe a scenario]. A story is something else.” This book uses the word story in its most generic sense: “a narrative, either true or fictitious, in prose or verse, designed to interest, amuse, or instruct the hearer or reader.” (I won’t be writing mine in verse, though it might be kind of cool if I could. Try it sometime and tell me what you get.)

Expressing our requirements through stories allows other users to read and understand them. Stories stick in human minds better. We can discuss and refine them iteratively as we proceed through the design process. And they keep implementation detail, undesirable at this stage, from obscuring the broadest issues.

Think about newspaper reporters. What information are they taught to find, and then compose into their stories? The fundamental questions: Who? What? Where? When? And then, if they’re thinking a little more deeply, Why? We’ll be doing that in our user story work. Then, and only then, can we proceed to How?

We dedicated all of Chapter 1 to working out Who? So you can generally start your story with a persona name—“Bob,” “Aunt Millie,” whoever it is.

The next most important question is What? What problem is Aunt Millie trying to solve, or what pleasurable state does she want to enter? What does she consider to be the characteristics of a good solution or pleasurable state? You’ll generally start with some sort of scene setting to describe the problem and some sort of goal setting to specify the sort of action she wants, and the goal she wants to achieve. As I said before, the key is to write these from the user point of view, not the system point of view. For example:

“Aunt Millie’s sciatica is really kicking up, worse than before. She wants to find some exercises that might help stretch her hip out and make it stop hurting, or at least hurt less.”

We can add information further describing the problem and its solution:

“The pain isn’t too bad when she’s resting on the couch, but it hurts when she walks even as far as the bathroom.”

We can add grokkability information, as we did in the persona:

“She’s out of oxycodone and can’t get any more until her doctor’s appointment two days hence.”

If we know anything at this stage about the desired solution, we can put it in as well:

“Aunt Millie saw a yoga instructor once demonstrate exercises that she said helped with hip pain. She didn’t think much of it at the time, but now she’s willing to try anything.”

You have a pretty good idea of what Aunt Millie is going through, and what she wants done, don’t you? You sympathize with her. You want to help her. It’s short, but it’s a good first cut at a story.

Remember, our stories are not saying anything about implementation. We will definitely not say things like “The database tables shall be named Customers and Products.” Nothing about iFrames and Divs. And goodness knows, nothing about HTTP versus HTTPS.

Now you start talking to a live user. Perhaps you got in contact with that user by waiting patiently in a library room, having asked the librarians to direct any interested patrons your way.

You: Tell me about reading library books on your Kindle. [What, most general]

Bob: Well, I really like it. It means that I can get books without having to go to the library.

You: Sounds interesting. What do you like best about library books on your Kindle? [What, refined somewhat]

Bob: I travel a lot. I especially love my Kindle when I go away on business trips or vacations. I can load it up with library books when I leave and read them at the airport or on the plane or in the hotel. I used to have to carry all my books in my pack, but now they all fit on this Kindle. I can even reload it from the road if I’m out long enough to finish them all, but I’m usually not.

You: Cool. Tell me more. [Inviting further discussion, What and Why]

Bob: I’m a cheapskate, and books are expensive now, so I borrow more from the library and buy fewer of them. The library mostly lends hardcovers, which take up more space and weight in my pack. And I’m afraid I’ll forget one in a hotel room, which would wipe out any sort of cost savings. As long as I have my Kindle, I’ve got everything with me. Man, that Jeff Bezos guy has it. I wonder if that New York Times article bothers him, about the brutal culture at Amazon. Maybe his Washington Post will attack it!

You (getting back on track): When would you say you most often download books to your Kindle? [When, also Where]

Bob: I usually head out on a Sunday. It’s a pain in the ass to get everything packed up. And I can never get to the bookstore or the library in time. And their hardcover books are heavy anyway. [This repetition is good. Don’t roll your eyes. Nod sympathetically.] I’m always running around trying to get ready.

You (guessing): So you’re at home packing up, and you want to load up your Kindle too? [When and Where, reconfirmation]

Bob: Yes, the library Web site is much easier to use on a PC than on a mobile device. They’re a nonprofit—I guess they can’t afford a good usability study—so it really sucks on a phone or tablet. And you can’t depend on Internet connections when you travel. I like to be loaded up before I go. If I can’t, then I can’t, but I’d rather.

You: What kinds of books do you like best? [What, Why, keep the guy talking]

Bob: [Whatever, it doesn’t matter]

You: Do they have a lot of those in the electronic library?

Bob: Actually they don’t have that many. Their electronic collection is new in the last couple of years, and they are just starting to expand it. There’ll be more in the future. The library director says they’re spending half their new book budget on electronic books. They’re actually quite expensive if you’re acquiring library loan rights.

You: Is it hard to find the ones you want? [What, When, possibly a new story]

Bob: You can put a hold on anything they have in their collection, and it will automatically show up on your Kindle when it’s available. Sometimes it takes a while for your request to get to the front of the queue. I hate having to browse and browse and browse and see all these books not available. That’s especially annoying when I’m loading up to head out.

You: So you’d like some way to restrict your selections to what’s currently available? [What, Why]

Bob: Yes, that’d be great. Oh, and one more thing. The librarian at the brick building has a shelf of books to read instead of popular ones that take a long time to get. Waiting for the new Jack Reacher from Lee Child? Try David Poyer, or maybe Stephen Hunter. Stuff like that. It’d be great when I’m loading up to head out and don’t have a whole lot of time to fart around choosing. Just toss something onto my stack and head on out.

You: So you’re asking for automatic recommendations among what’s available to you right now? [What, Why]

Bob: Yes, that’s it.

After thinking through Bob’s responses carefully, you might write the following story:

Bob travels a lot for his job. It’s Sunday afternoon, and Bob is packing up for another business trip. He reads a lot on these trips, in the airport and on the plane and at the hotel, or while eating alone in restaurants. When he travels, he likes to bring books on his Kindle, because it’s small and light and convenient. He wants to get his Kindle books from his public library because it’s cheap. As part of his packing, he logs in to the library Web site to see what they have for him. Many of the electronic titles are checked out right now, so he selects “Show Only Available Titles.” The display resets to show these. One or two of them catch his eye, and he selects them. He then is interested in some new things, so he clicks “Show Recommendations.” A list appears, based on [whatever criteria we decide]. He moves through the choices and selects the maximum the library will allow him to check out at a time. He tosses his Kindle into his pack and heads out to make a living.

Writing the initial story is generally not the last word. As you go through mockup development (Chapter 3) and usability testing (Chapter 4), you will learn new things about your users and the problem they’re really trying to solve. The testing will refine the mockups. And it’s not unusual that the refined mockups will refine these stories as well. Don’t consider that a failure. And to this iteration we now turn our attention.