2
User Data Drives Design
Abstract
User-centered design recognizes that all innovation has to start with an understanding of the user—with a real-world problem to solve. And good design needs an in-depth understanding of users' tasks, motivations, intents, strategies, and detailed steps, as well as an overall grasp of how they go through their days, what technology they depend on, who is important to them, and their self-image. This depth of knowledge is best available through field research and has to be elicited through observation and inquiry—you can't just ask users what they want, and you can't just observe and know without talking to them. This chapter makes the argument for user-centered design and for field research as the essential starting point.
Keywords
Business analysis; Contextual inquiry; Cool concepts; Design; Design thinking; Ethnography; Field research; Human–computer interaction (HCI); Human–machine interaction (HMI); Marketing; Mobile design; Product design; Requirements elicitation; Requirements gathering; System design; Tacit needs; Usability; User-centered design; User experience; User research; UX
The first phase of Contextual Design guides a team through gathering field data and interpreting it as a team. By capturing issues and modeling each individual’s experience, the team records the data that will later be consolidated to build a coherent view of the practices and experiences of the whole user population. This part describes how to get the best design data while involving and immersing the team in the lives of their users. Here we will describe the Contextual Interview and the Interpretation Session. We will talk about the Contextual Design models in Part 2.
User-centered design recognizes that to create a successful design—to transform lives with technology—the product team must be grounded in the relevant details of their users’ lives. Design for life tells us that understanding only the task is no longer enough, so the data we collect must include understanding core motives and a much wider range of life activities than before—even for a product that supports work. The sad news is that getting that detail is hard. It is best collected through field research: best for data quality and the best way to immerse the team in the users’ lives. But going into the field is time consuming, takes coordination, and is expensive. Here we provide the motivation for gathering field data to drive design and show how the detailed observational data produced by field techniques such as Contextual Inquiry is vital to a good, innovative design.
The challenge of design data
Consider what it means for products to be integrated into users’ lives as intimately as they are now. My phone plays my personal chime; I look and see it’s telling me I should leave for my next appointment. I touch the screen to see the details. A quick swipe, and I can see the rest of my day. Touch again, and my phone dials the person I’m going to see. And that is just one app.
Every one of those interactions is a design decision, and every one changes my life to some degree. From the high level (Do I want my phone to guess where I’ll go next, estimate travel time, and tell me when to leave?) to the lowest level (Is that swipe a direct and easy way to see the rest of the day?), every design element is intimately tied to an aspect of my life and behavior. This raises the stakes for design: every one of those design elements is an opportunity to enhance the user’s life or to interfere with it, for a product to make itself loved or cause irritation.
And that is just the low-level design. How do we decide what products or apps to build in the first place? How can we find what adjacencies will expand our market? What are the best next feature sets to add to an existing product, website, or IT application? What will enhance human life—what will detract? What will create joy and relief from hassle? What product will be abandoned for lack of fit to life?
The same in-depth data informs both detailed design decisions and product innovation. It is very different from what marketing, usability, focus groups, and standard requirements-gathering techniques provide. The very language of “requirements” assumes that there is someone doing the requiring—that people are capable of knowing what technology will transform their lives, and that they are aware enough of their own behavior and experience that they can just tell teams where the problems and delighters lie.
Standard requirements techniques give teams a multitude of ways to ask their users what they need. But in today’s world, design is invention. It’s up to a product team to discover how their users work and live, and uncover opportunities for small and large life transformation. Looking for a “user need” is simply the wrong focus. No one knew they needed a Walkman until the Walkman was invented; no one knew they would love music downloads until Napster made it cool and then iTunes made it legitimate; no one knew they wanted tailored music on demand until Pandora showed it was possible. Our experience of music has evolved with the introduction of products that met our unarticulated desire: instant, no hassle access to my music anytime, anywhere.
When the goal is innovation, whether in a wholly new product or even in the next version of your successful product, design methods must move beyond the idea of requirements, wish lists, pain points, and problem solving. These focus designers on solving specific problems rather than understanding the totality of the work and life context. Even thinking about user needs focuses the team on existing needs that can be articulated or recognized. But invention taps into our core unarticulated desires—so the data designers need is data that will lead them to identifying opportunities that even the users themselves don’t recognize.
To design at this level, the team needs not just data but insight; not just facts, but understanding. So the first task of any user-centered methodology has to be to provide structured activities that guide a team through the process of gathering trustworthy, detailed user insight. This is the role that Contextual Inquiry plays in Contextual Design.
Contextual Inquiry helps answer the product team’s most basic question: “What could I make that will enhance people’s lives and enable them to do what they really want easily?” This question requires that designers understand what is really going on in the users’ lives when they try to do the target task: What are you trying to accomplish? Is it so important that you need to do it immediately? Or is it a chore that you’d like accomplish during dead time? Where are you likely to be, and how much time and attention can you devote to the task? How do we give you an interface that lets you do what you need without forcing you to think about the tool?
Modern products impact work and life at a deep level, and speak to who we are as humans. To design for life not only requires a deep understanding of the whole work and life context but also of users’ core motives as humans. Successful design means going far beyond understanding the “cognitive load” or “steps of a task,” to quote two common concepts in the UX field.
Designers must learn to see how a product or device might enhance a user’s sense of self, through function or look: I’m a salesperson—with my cell phone I can provide clients the 24 × 7 availability I always dreamed of. I’m a craftsperson—with my cell phone camera and my online community, I can share and receive kudos for my great projects. These issues are part of the context of use, and designers must learn to see them.
Designers must also learn to see how products can enhance people’s relationship to their communities: I can connect quickly with a friend through text or Facebook, so I’m never out of touch. Even a quick touch counts—it reaffirms our relationship and keeps us in each others’ thoughts. My sense of community—of being not alone—is part of what makes my life matter.
So as a discipline, UX design needs a new way of seeing this larger whole life context. We need to recognize and collect new types of user data on core human motives, on wider dimensions of life, on work, and on how the whole of the user’s integrated life fits together. Designing for individual tasks is simply insufficient in this new world. Instead, we must understand the whole of how an activity fits into the structure and time of life and how it can enhance the wellbeing—the joy in living—of the person.
You can’t just ask for design data
The challenge of user research is that many of the important aspects of work and life are invisible, not because they are hidden, but just because it doesn’t occur to anyone to pay attention to them. These aspects of work and life practice cannot be discovered just by asking questions.
A group of friends on a multi-day bike trip send regular rude texts to the one member who stayed home. Do any of the participants realize how much these texts matter to his maintaining his sense of connectedness despite missing out on the trip?
A worker in accounting calls a friend in order processing to gossip and mentions that a rush order is on its way. Does his manager know this informal communication is the only thing enabling his company to fill rush orders on time?
A man gets alerts on his phone of transactions made against his account as they happen. Do we understand how this fits in with his overall desire to stay on top of his financial situation at all times?
Any method designers use must reveal tacit data—the aspects of users’ life and work that are so habitual that there’s no more need to think about them, or that are created in the moment so that no one did think about them.
In one health clinic, the request for a certain procedure is always on a green form. Not until looking at the actual forms did we realize the form isn’t used at all—people simply wrote across the face of the form. The only thing that mattered is that it was paper, and it was green.
Traditional methods of gathering user data assume people will say what is important if asked. But people simply don’t pay that much conscious attention to how they perform jobs they do well. Think about how difficult driving was when you were first learning—getting the steering coordinated with the accelerator and the clutch (if there was one) was awkward and jerky. With increasing skill came increased smoothness, and less attention to each detail, until at last the whole process became unconscious. Now, to teach someone else to drive, the teacher has to recover everything that is now autonomic. And driving is a simple, obvious task—how is one to know what aspects of everyday work are important? Even the user doesn’t consciously know what the questions are:1
A new cell phone user discovered that her Bluetooth earpiece was the perfect solution to a problem that had been bugging her for a long time. She got very poor reception in her apartment—there was just one location where the signal was acceptable. With her Bluetooth earpiece, she could leave the phone there and walk around her apartment while on the phone, and never lose the connection. It certainly never occurred to her that this was one of her needs in buying an earpiece.
This is true in general with “wish lists” and other user requests; the user will focus on a narrow fix, whereas understanding the context of the work that drove the request will result in more insight and better solutions. The user acts as though the question were, “What simple tweak or addition to the product as it is will overcome the problem I’m having;” the designer wants to know “What new concepts or features would make the product radically more appropriate to the job at hand?” Answering this question requires an open-ended technique.
Not only do users forget the details of the activities they do, when the products they use are broken, they figure out work arounds, get used to them, and then forget about what they did to overcome the product problem in the first place:
Our user opened an online form requiring some numbers; but instead of using the facilities in the form to calculate the numbers, she opened a spreadsheet in another window and used the formulas there to do the calculation for her. When asked why, she said, “Oh, the online thing has never worked. We just use the spreadsheet. It’s much simpler.”
People always make their work work; they overcome technology to make their life work. Contextual Inquiry shows teams how to uncover all these tacit aspects of life so that they can be understood and designed for.
Gathering requirements for a product is not simply a matter of asking users what they need, like gathering pebbles from a beach. One cannot simply ask for design requirements, in part because people don’t know what technology is capable of, but more because most people are not aware of what they really do. The everyday things people do become habitual and unconscious, so they are usually unable to articulate their practices. People can say what they do in general terms and can identify critical problems; they can say what makes them angry with the tools they use. But they usually cannot provide day-to-day details about what they do. They cannot describe inner motivations such as the need to express a particular identity or to feel connected with people they care about. They are likely to forget about the work arounds they had to invent to overcome problems in their current products. This low-level detail of everyday practice is critical to design for life.
Deep insight comes from the field
If designers cannot just ask users for this detailed data about their lives, can they get it through traditional requirements elicitation techniques? After all, most companies do gather some level of user data in developing products. Developer Sue went to a user’s group meeting and talked to people there; Marketing Director Joe showed a demo at an industry show; Project Manager Mary makes a point of meeting with internal users at least once a month. These are traditional and usual methods of maintaining user contact. And yet they do not result in the kind of design data discussed above. They do not generate real insight into the users’ world and incorporate that insight into the design of a product. It’s worth taking a few minutes to explain why that is so.
Because marketing and design have different goals, techniques useful to marketing and product management tend not to be useful to designers. These techniques characterize and scope the market, rather than describing the structure of its practice. As a result, they tend to be quantitative. When you want to scope a market or apportion development resources, it may be useful to ask, “How much money do you expect to spend on equipment next year?” and average the results across all respondents. This is the kind of question you can answer with a survey. Designers must build on more qualitative data. “What does it mean to set up travel, and how do people do it?”—The answer to this is a description of practice, not any sort of number. Even if a question looks like it has a numeric answer—“How many times do you check email throughout a day?”—this is deceiving. For a designer, the true answer isn’t a number, it’s “Every free moment—I want my email at my fingertips and I want always to be plugged into my community.”
Many traditional techniques assume you know what the questions are. For example, surveys and structured interviews both start with a list of questions which explicitly or implicitly drive the interaction and define what is important. But as soon as design starts, no one knows what the questions are. No one knows what will turn out to be important. Perhaps customer satisfaction surveys (a marketing technique) report that installation is the #1 problem. But what is wrong with installation (a design question)? When do installations happen, and who does them? What information is available when they do them? Which of the many alternative fixes is the best?
None of this is to say that designers don’t need to worry about what people will buy. It’s only within the context of a market with needs to be met and money to spend that design makes sense. Quantitative techniques using predefined questions can identify the market and show designers where it is interesting to explore. But once marketing techniques have identified a market and shown that there is money to be made there, designers must look in depth at the whole life and work context of people in the market to determine what to build.
Understanding a market requires a qualitative technique that explores the users’ activities and makes new discoveries about what people do and what they might value. The discoveries may then lead to new strategies or product concepts for addressing the market and new market messages for selling to it. They will confirm whether the identified market really has an opportunity given the mission of the company. Then, quantitative techniques may again be useful to show that the practice to be supported is sufficiently widespread to make a good business case. The two disciplines, marketing and design, build on each other with complementary goals and techniques, to result in a whole-product definition.2
Other traditional techniques have similar pitfalls. Two other common techniques are focus groups and hiring users to be in-house experts. But both approaches depend on the users to be able to articulate details of their work and life practice—which we already said is hard. Moreover, when the users are taken out of their daily context and put in a conference room with others, they lose the clues of daily life to help them remember what they really do—and they are overly swayed by the group dynamics in the room. Focus groups are great for getting a gut reaction to new product concepts, but they are not the way to find unarticulated opportunity. Similarly, putting an expert user on the design team immediately takes the expert out of doing the work she is now designing for. And since her practice was unconscious and her strategies uniquely her own, she can inadvertently narrow the team’s focus as they defer to her knowledge, observations, and beliefs.
Another popular approach to gathering user data is to start with an existing design: either build a prototype without user data or do “A/B” testing on a running system to evaluate alternatives. These techniques can improve a product incrementally once it has been invented, but they will rarely spark new invention. The users may be able to say they like something or do not, but they will have a much harder time saying why, what they are trying to accomplish, or what other features that the design team never considered would be more valuable to them. The team can tune their initial idea; they cannot discover what they don’t know, which might lead to more innovative ideas.
Our job is to understand the detailed lives of our users as it pertains to the target activities we are trying to transform or improve. The problem is that everyone can tell you at a high level what they did and what they cared about, but no user, expert or not, can remember or even know the low-level details of their own behavior—or their underlying emotions, motives, and hidden intents. If innovation is your goal and not just incremental improvement, then the team must go to the field.
Dealing with the data as a team
The team can only build from a deep understanding of the user’s world if they experience and internalize that world. Going to the field is the first immersion experience—but only for the interviewer. How do we get this knowledge into the “gut” of the rest of the team? How do we make sure that the rich data collected isn’t lost in a summary email, trip report, or list of key findings circumscribed by the point of view of a single interviewer? Without experiencing the users’ world, the intuition of the team will not be tuned to reflect the reality of the users’ lives. And without a way to quickly capture the detailed data of the field interview, the detail will be lost, or its significance overlooked.
When correlated with data from other interviews, data that may not seem immediately interesting can reveal transformative market issues and opportunities. Not only do we want to avoid “design from the I,” from the designer’s own point of view, we also want to avoid design for the issues of only one user. And for maximal market impact, we don’t want designers to generate new product concepts from only the one user they interviewed. When the team is immersed in the lives of the whole market, insight happens naturally. Our job is not just to get the best data for design but to capture and organize that data so that it can impact the final product design. This is the second challenge of design—making sure the whole team internalizes the lives of the users at the market level.
In the last chapter of this part, we introduce the Interpretation Session, our first design meeting. The interviewer shares their experience in the field with other team members, who capture the data into the affinity notes and models selected for the project. The Interpretation Session is also the first time we introduce the kind of design meeting structure that can help teams work together effectively in the face of their differing skills, job titles, and personalities. The Interpretation Session process lays the groundwork for later design meeting and teaches the team that they will go quickly, have fewer arguments, and be more focused and innovative if they work within a structured process.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.