“People know everything—everything—about what they do. They just can’t tell you.”
This is the central insight of Contextual Design—and sometimes the hardest for people to understand. The whole assumption behind requirements gathering is that it is possible to ask people what they want, what they need, or how they work and get a reliable answer. But this just isn’t so.
I was recently talking to a portfolio manager—her company had decided that they were going to re-implement their intranet portals on a new platform. Reasonably, they wanted to gather requirements for the new portals. The business analyst sat down with this woman, a clearly competent portfolio manager, and asked her: What do you want? What does a portfolio manager need? She found herself totally speechless. She had no answer—even though she does the work the portfolio portal is supposed to support. She didn’t know how she used the portals, she didn’t know what she wanted in the future, and she didn’t have any “requirements.” But the business insisted on getting the requirements—the analyst needed to figure out how to provide them—it was a requirement to provide requirements. So requirements would be provided, portals would be built, and she said, “We all know few will use them.”
Every methodology invented for designing the right thing starts with gathering requirements. Requirements gathering is the single most difficult part of the process because if you don’t get it right, you don’t build the right thing—or the most desirable thing.
Every classic customer data collection technique depends on the idea that you can ask your customer—or your business user—and get a need or requirement that you can reliably build your solution upon.
- Surveys start with questions and expect reliable answers. But surveys depend on the user understanding the question, being aware of their own behavior, being able to articulate the behavior or need, having a reliable, unchanging opinion, and then being able to put a number on it. Or worse, being able to list it in an open-ended question.
- Traditional interviews seem better, particularly if they are one-on-one—more amenable to probing and interaction. But the interviewer usually comes in with their questions, their burning issues that they want resolved based on discussions with the design team, marketing, or business. And they too, depend on the user understanding the question, caring about the issue, being aware of their own behavior, and being able to articulate the behavior or need or motivation. Open-ended questions again assume that the person spends their time thinking about what they need, do, and want.
- Focus groups start with questions developed by a business group to answer business questions. Focus groups also assume that people can answer the questions. But in this setting the group members influence each other—on the good side, they may remind each other about some issues that otherwise might have been overlooked. Often one person dominates the talk or influences the flow of the conversation. But everyone knows that they have signed up to give their opinion, so they will produce one. After all they do the job—how could they not know what they do or want? Everyone can always find something to say!
In the end, designers need design data. They need to understand what people do, where the glitches are and where people have had to create work-arounds. They need to find the opportunity for delighters and gotcha’s. They need to see the inefficiencies and the huge holes in how things are done. They need to understand what is going on with people.
People make their work work. People make their life work. People use whatever technology or solutions they have because people focus on doing their life not watching their life. Life is the center of people’s life, not requirements or needs or technology. People using a pen talk about what they are writing, not the pen features. Indeed, the pen features only matter when the pen leaks or breaks!
So surveys, focus groups, and interviews will capture the most recent complaints that are still top of mind—but this is not where significant value is to be found. Value can be found in the details of everyday life. But even though people know everything about what they do, they just can’t tell you—because the doing of life is habitual and unconscious and simply unfolds autonomically.
Consider driving. Most of us know how to drive—we are experienced drivers. So I can ask you, “What do you do when you drive?” It will sound like a reasonable question. You will give me an answer: “I get my keys, and go to the car, open the door, get in and start it and back up and, well, then I go.”
Anyone can give a high level description of what they do—but they don’t have the details.
- How do you hold the key?
- This matters for keyfob design, as I unfortunately found out when I kept locking my new car every time I held the fob.
- Where do you put your cups and phones, how do you grab them, what do you need in your line of sight—without getting in an accident, please!
- This drives design of the interior of the car, where storage and outlets are located, and these decisions affect the rest of the interior.
- How do you change gears? At what speed do you turn the corner?
- This drives understanding how to design the controls of the car.
- What distracts you when you drive? What are you paying attention to—really—when you drive?
- This guides the design of displays and automatic driving features coming into cars these days.
- What gives you the feeling of power, control, delight…?
- This drives the aesthetic design and even the sound that is produced on acceleration.
And if you doubt that little things matter, a personal story:
When I was in my 40’s transition I had to get a convertible—of course! So I went shopping with my husband. We went to look at the first Miatas, and I looked around while he went to get a salesperson to test drive. When he returned I said, “Let’s go—we aren’t getting this car.” Why? The door handle required that you put in one finger lengthwise to open it. “I’ll break a nail,” I said. They lost a sale over a handle design.
These low-level details of what people do are what designers need—believe me I wouldn’t have been able to tell car designers gathering requirements to be sure not to break my nails! Armed with the details of everyday life, at work and home, designers will find what can delight users and make their lives easier.
And if you get these details wrong? The big ones and the little ones? At worst, you lose the sale. Or your internal businesses system will fail to be adopted. Indeed you might even go out of business! Scan Design in New England went out of business because they put a broken new invoicing system in place and ran out of cash before it could be fixed.
At best, what are the consequences of bad design? You continuously irritate people every time they use the big function that they do value.
Getting the requirements right is just hard. What makes it harder is that people really do want to do the right thing; like my portfolio manager and her analyst. People want to build things that people buy and adopt. But to do that, designers, managers, and C-level people need to understand that—
“People know everything—everything—about what they do. They just can’t tell you.”
Even “requirements” techniques like rapid prototyping or Agile or co-designing possible screens with a user or business stakeholder assume that the user’s gut feel accurately reflects the most important things to build. But does it?
By the time an application or screen is built, someone—not the customer—decided what is best to build. Usability testing in any form can fix 10-12% of the little, annoying things at best—it doesn’t challenge the whole concept, or reveal the fundamental needs or value that the product could support but doesn’t.
So what to do? Don’t ask your customer what they need or want or like. Instead—go see for yourself. Go to the field. Talk with your users about what they are really doing while they are doing it. Then, when life is happening in people’s real life context, people can comment on it, people can react to events in their life, and you can see what works, what doesn’t, what is inefficient, where the delight might be, where the opportunity lies, and what value can be brought into people’s lives. You can see what people need and—in the context of real life—they can tell you.
In the end, this is the core secret of Contextual Design’s success—Don’t ask your customer—instead go into the field and see what is going on. Then the Contextual Design process helps a team use that design data and validate ideas with users. But without the right data—no organization can get the requirements right.
See the comic story of Don’t Ask Your Customer