it’s tempting for me to be nostalgic about that time period as one that had a special focus on learning, I don’t think anything has changed for me. Nowadays, I travel widely to interview users and to teach others how to interview users. In the past few weeks, I’ve led a number of training workshops and interviewed a bunch of fascinating people. (I called home from the field to report that, once again, “This is the most interesting project I’ve ever worked on!”) Maybe it’s my researcher nature, but having fresh stories from the field to share in the workshops and having refined thoughts about how to interview to take with me into the field is pretty damn wonderful.
My best wish for you is that learning about how you learn about users will fuel your own passions in some similar measure.
—Steve Portigal, March 6, 2013, Montara, California
CHAPTER 1
The Importance of Interviewing in Design
User Insight in the Design Process
To Interview Well, One Must Study
This is a great time for the design researcher. Within user-experience design, service design, and to a lesser extent, industrial design, user research has gone from being an outsider activity, to being tolerated, to being the norm. Across industry events, conferences, online forums, school curricula, and professional practice, there’s a tacit agreement that designing for the user is the preferred way to think about design. As with any generalization, there are exceptions. Maybe you aren’t feeling the love right now, but you probably can agree that things are much better than they were in the past. To design for users, you must begin with a deep understanding of users. If you don’t already have that understanding, you need to do some form of user research.
TIP YOU ARE NOT YOUR USER
You may be a user, but be careful of being seduced into designing for yourself. Jared Spool calls that “self design” and identifies the benefits and risks at www.uie.com/brainsparks/2010/07/22/uietips-self-design/. I think he’s too easy on self design. Lots of niche companies make the snowboards, outdoor equipment, and mixing gear that they, as enthusiasts, would want. But some have trouble expanding their offering in an innovative way, because they are so caught up in being the user.
NOTE GAINING INSIGHT VS. PERSUADING THE ORGANIZATION
While doing ethnographic research in Japan, I sat with my clients while they conducted another study. They brought users into a facility and showed them the most elegantly designed forms for printer ink cartridges. They were smooth, teardrop shapes that were shiny and coated with the color of the ink. They also showed users the existing ink cartridges: black rectangles with text-heavy stickers.
Can you guess what the research revealed? Of course. People loved the new designs, exclaiming enthusiastically and caressing them. Regardless of methodology, there was no insight to be gained here. I’ve gone back and forth about whether this was good research or bad research. It didn’t reveal new information, but it provided tangible evidence to persuade someone else in the organization. This team’s approach suggests that there are other issues with their design process, and while their research might have been the best solution in that situation, ideally this isn’t the best use of a research study.
User Insight in the Design Process
Although there isn’t a clear alignment about how much time and effort to invest and what approach to use, at least we, as user researchers, share a common goal: to gather information about users in order to support the organization when creating products, services, and more.
What I’m calling interviewing is also referred to by other names: user research, site visits, contextual research, design research, and ethnography, to name a few. Regardless of nomenclature, these are the key steps in the process:
• Deeply studying people, ideally in their context
• Exploring not only their behaviors but also the meaning behind those behaviors
• Making sense of the data using inference, interpretation, analysis, and synthesis
• Using those insights to point toward a design, service, product, or other solution
We go to visit our users (in their homes, their offices, their cars, their parks, and so on) most of the time, but not always. When planning a project, we ask ourselves if it’s more insightful to bring participants in to see our stuff (say, prototypes we’ve set up in a facility meeting room) than it is for us to go out and see their stuff. Overall, our objective is to learn something profoundly new. There are points in the design process where quickly obtained, if shallow, information is beneficial, but that’s not what we’re focusing on here.
NOTE IS THIS ETHNOGRAPHY?
If you are interviewing users, are you doing ethnography? I don’t know. What I do know is that if you refer to your use of interviewing of people as ethnography, someone will inevitably tell you that no, you aren’t doing ethnography (you are doing contextual inquiry, or site visits, or in-depth interviews, and so on). The term ethnography seems to be particularly contentious for some folks, but...whatever! That’s really their problem, isn’t it? I’d rather we move on from definition wars and focus on what it is I’m getting at when I say interviewing—which means conducting contextual research and analyzing it to reveal a deep understanding of people that informs design and business problems.
Of course, there are varying perspectives on any “best practice.” Everyone from Henry Ford to Sony to 37 Signals has offered up their reasons not to incorporate direct customer input into the development process. The subtext of those claims is that people in those organizations possess an innate talent for building stuff that people love. Yet some companies that publicly make those claims have hired me to interview their users. The insights that come from studying users not only inform design but also inspire it. Across organizations, different design cultures have more or less of an appetite for inspiration or information, although in my experience it’s hard to interview users without taking away a hearty dose of both.
Sometimes, the stated goal of interviewing users is to uncover their pain points (often known as needs). Embedded in this mindset is the mistaken notion that research with users is a sort of scooping activity, where if you take the effort to leave your office and enter some environment where users congregate, you’ll be headed home with a heap of fresh needs. People need an X and Y, so all the designer has to do is include X and Y in their product and all will be good. What? No one really thinks that, do they? Well, take a look at Figure 1.1
Microsoft’s ad campaign for Windows 7 implies an unlikely approach to research, design, and product development. The customer asks for some feature—in this case, for the OS to use less memory. Microsoft, seemingly unaware of the need—or opportunity—to