1
Introduction
Abstract
User-centered design is a tried and true approach to product design. Start with an understanding of the user gathered via rich field interviews and build that understanding into your new product—then test and iterate the result with the user again. The first edition of this book introduced Contextual Design, a complete method to do just that. But over the last 10 years, there's been a revolution in technology with smartphones and tablets providing constant, continuous connection with people, information sources, media, and the support structures of our lives wherever we happen to be. Our inquiry into the impact of these devices led to the development of the Cool Concepts, an articulation of what makes these devices loved. This new integration of technology into life requires new ways to understand and design, and therefore a revision of the Contextual Design method. This chapter motivates that redesign and discusses the principles driving the method: design for life, design in teams, and immersion in the life of the user.
Keywords
Business analysis; Contextual design; Contextual inquiry; Cool concepts; Design; Design for life; Design thinking; HCI; Human-machine interaction; Marketing; Mobile design; Product design; Requirements gathering; System design; Usability; User-centered design; User experience; User research; UX
Contextual Design is a user-centered design process built upon in-depth field research to drive innovative design. Contextual Design was first invented in 1988 and has since been used in a wide variety of industries and taught in universities all over the world. It is a complete front-end design process rooted in Contextual Inquiry, the widespread, industry-standard field data gathering technique. Contextual Design includes techniques to analyze and present user data, drive ideation from data, design specific product solutions, and iterate those solutions with users. In 2013, we redesigned the method to account for the way that technology has radically changed people’s lives with the invention of the touch-screen phones and other always-on, always-connected, and always-carried devices. This book describes the current practices in Contextual Design, which has evolved to help teams design for the way technology now fits into peoples’ lives. Twenty years ago we wrote:
“Developing software has never been easy. But over the last 20 years the requirements on software development have gotten vastly more stringent. Whereas once computers were used by experts in glass rooms, now everyone on the street expects to use a computer to get their jobs done. Whereas once computer users knew and liked technology, now users want their computers to be as invisible as a ball–point pen so they can focus on their jobs. Whereas once applications supported a single, bounded task—compute compound interest for a bank’s loans, perhaps—now they are expected to support the whole work of the business, from electronic funds transfers with the Federal Reserve to the company’s Email system. It’s no longer enough to be a good software engineer. To be successful in today’s world, those who define and build hardware and software systems must know how to fit them into the fabric of everyday life.”
This is still true. But 20 years ago computers were not really mobile. Laptops were clunky and had limited use. Software applications required a person to sit at a desk, locked to a keyboard and screen, and a proprietary data source. There was no Internet back then, no possibility of streaming megabytes of data and video to a handheld device. There were no consumer applications to speak of. Supercomputers of that era couldn’t match the cell phone of today. There was no online shopping, no social media, YouTube or streaming video at all, no search engine that could find anything instantly in a single request. We read paper books and newspapers. Games were locked in a box. So was business data. In other words, there was no possibility of real, on-the-go access—the technology didn’t exist and the content was not available. Even the BlackBerry was a few years in the future. We had no access to all of our life’s information, no support for work and life activities and no access to entertainment.
So what did it mean to “fit systems into the fabric of everyday life,” in that limited context? The history of user-centered design was a reaction to at least two things.
First, traditional product design was dominated by smart software engineers thinking up a bright idea, building it, and then trying to create a market for it. But even at that time our industry had moved away from green screens toward products that supported applications for regular people. Technology had become more sophisticated; user interfaces and interactions had gone beyond command lines. It had become critical to consider ordinary users—not specialists. Early usability professionals realized that fixing a product’s problems by making better documentation made no sense. We knew we had to work with users. But usability testing, the hot new thing at the time, was and is not a way to invent a better product. Usability testing can fix 10–12% of the problems with an existing product or concept. It cannot reveal what will really enhance and transform people’s lives.
Second, user-centered design1 was driven by the need to create a space for design as an activity. A product or business system was defined as a set of requirements, a list of features that were parceled out to developers who did all the design. There was no concept at the time of design as a separate activity or of professionals who designed. A product was a list; requirement gathering was about what to put on the list. “Design,” in software development, invariably and always meant design of the structure of the code. Even today, “design” usually means design of the look of the user interface only.
As the industry moved to tools supporting everyday people, those of us leading the charge toward user-centered design recognized a need for a more systemic approach to product design. We realized that the way an engineer thinks about the world, the product, and the activity being supported is simply not the way ordinary people think and work.
Witness an early word processor: Paragraphs, footnotes, headers and the like were implemented as “elements.” A document was a collection of elements in a database. Behavior was coded as attributes on the elements. And so a footnote could float around the page, just by changing a few attributes! Not what any writer would expect.
For us, design has always meant figuring out what to make that will enhance life. Today the overarching concept of User Experience (UX) refers to a collection of activities—research, interaction design, and visual design—all of which work together to build the right thing for people. Product definition and specification are at the core of design.
Twenty years ago, the message of Contextual Design was: first understand your users, then design a coherent product that works for the task you want to support. Don’t generate a list of features to achieve a preconceived purpose structured in a way that made sense to engineers. Fit to life meant design for a coherent task.
Contextual Design has been used to design business products and systems, websites, mobile devices, mobile apps, medical devices, consumer products and electronics, automotive electronics, business information products, CRM, manufacturing systems, and more. But none of these products radically altered the way people used technology in daily life. All these products could still be supported well with a task-focused design process. The activities they supported were all achieved sitting at a desk in front of a computer. Even as we moved to WYSIWYG, to the web, to online retail and social media, we were still sitting in front of a computer, doing a task, in a space which supported that task.
Then in 2007 and 2008, the iPhone and the Android put small computers into everyone’s hands, and the role of technology in life radically changed. They supercharged a transformation that was already in progress: Google taught us that any question can be answered, in seconds, anywhere, without arcane query languages. Facebook and Twitter taught us that we can reach out and touch others any time we wish. Then iPhone, Android, and tablets gave us these and our whole world—our friends, shops, books, news, and pictures, the things we’ve created and the things we need for work—in our palms, on our wrists, always just a touch away. There’s no boot time anymore—hardly any setup, login, or preparation. There’s just me and my work, me and my life—and increasingly, not much distinction between them.
And, of course, how technology interacts with the people has radically changed. Technology is now an appendage—always available in every moment of time, anywhere. Now people get their whole life done by filling up every bit of time they have, anytime, anywhere, across multiple platforms. No longer can successful product teams focus only on individual tasks done in one stationary location. Now teams must design for life: how a product fits into all the contexts of everyday life.
Products must still fit into the fabric of everyday life, as we said in the first edition—but now they must understand the whole life. A simple focus on task is not enough. Today, users’ activities are broken up into small bits of action strewn across time, space, location, and devices. So every task must be designed to ensure it doesn’t slow people down as they barrel along, getting their whole life done.
To support design for life, Contextual Design had to change to help teams collect and use data about that larger life and how a target activity flows through daily life. This book reintroduces Contextual Design, building on the strength of its existing techniques; integrating lessons learned over the last 20 years; and incorporating new forms of data collection, analysis, ideation, and design so that product teams can more effectively design for life.
Contextual Design is a step-by-step process for collecting field data and using it to design any sort of product that includes a technical component. There are three phases to Contextual Design: First, the team immerses itself in the life of individual users through field visits and interprets the data using models to show a big picture of the whole market. Second, the team uses that big picture to drive ideation, inventing new product concepts from the user data. Third, these product concepts are designed with concrete user interfaces and behavior, which are validated and iterated with users. Contextual Design can be used to create, refine, or extend existing products, design for new markets, or drive longer-term product roadmaps. It can drive coherent design to support a target activity across multiple platforms. It can be and has been used as part of many requirements and software development processes, including Agile. And because it addresses how to design for life it can help you deliver joy—or coolness—to your customers, as we explain later. Contextual Design is guided by three overarching principles and challenges which will recur throughout the book:
• Design for life, not just for individual task or activity;
• Immersion in the users’ world to tune intuition and focus design thinking; and
• Design in teams, because in the real world, it’s always a team of people that need to work together, design together, and come to agreement.
Here we describe these core principles and provide an overview of the Contextual Design techniques. Throughout the book we will refer to these principles and also introduce additional principles as relevant to the part of the process being discussed.
Design for life: the Cool Project
Contextual Design is driven by the realization that a product is always part of a larger practice, used in the context of other tools and manual processes to deliver value to the user’s overall life and work. Product design is really about the redesign of the user’s life and work, given technological possibilities—designing a new and better way for users to live their lives, achieve their goals, touch the people that matter to them, and perform their activities by introducing better products. The need for this deep understanding of users has only become more compelling as touch phones, tablets, and other devices continue to infiltrate our lives.
Since at least the late 1980s, the basic idea that designers must understand the context of task activities has stood the test of time. Accordingly, Contextual Design introduced a set of models—diagrams and pictures, each showing one aspect of the users’ life context. These original Contextual Design models successfully focused the design effort on understanding the context of task activity. They revealed the context of use, showed the structure of the users’ activities, and revealed the key issues in a market.
These Traditional Contextual Design Models are still relevant; we describe the most important ones in Chapter 8. But to design for life, we must understand the whole of life as the context of use, which is very different from the context of use of the traditional products Contextual Design was designed to create. The wall of separation between home and work has broken down—torn down by people trying to make their whole life work. Work is done on the road, in the air, at tables in restaurants, and at Little League games. And personal life has filtered into work—tickets to the theater may be found at work between completing sections of writing or reading or filling out a form. They may be agreed on with text messages during a meeting, and bought later online while on hold during a phone call. A work task may be started over breakfast at home on a tablet, continued at traffic lights during the commute on a touch phone, and wrapped up in the office on a desktop machine. Today, the context of use for what used to be a single, coherent task includes all these places—flowing across place, time, and devices.
Successful design now means going far beyond understanding the “cognitive load” or “steps of a task”—buzzwords from a previous generation of user-centered design. Transformative products help us get our life done, celebrate our accomplishments, connect to the people who matter to us, express the core elements of our identities, and create moments of surprise and sensory delight—all in a product that just works, like magic, with no hassle or learning required. That is a tall order, and means that designers must understand a much wider life context than they ever had to before.
When the iPhone and then Android phones came out, we at InContext noticed that the way ordinary, nontechnical, people felt about them had radically changed from older technology. The language people used was, “This is so cool!” We saw that something fundamental had changed in the way that people related to technology, and we wanted to understand it. So we started our Cool Project in hopes of uncovering the core of the cool user experience.
We went out in the field and talked with more than 60 consumers between 15 and 60 years old about what makes things cool for them. We asked people to show us products with some technical component that they experienced as cool. Then we talked with them about their experience, watched them use the products, and discussed how they transformed their lives. We didn’t try to define “cool” for them. Instead, we let them define it by showing us the products they thought were cool. We then turned to 30 enterprise workers to see if these same experiences were relevant for workers—and they were. The seven Cool Concepts, which guide the deliberate creation of a cool user experience, emerged from our analysis of this data.
To validate the concepts and create a metric, we partnered with SAP. The Cool Metric is a set of 40 questions that have been validated with over 2000 people worldwide2. The metric can differentiate coolness between different kinds of consumer and business software and between devices. It can be used to compare scores across competitors, or to focus an initial market study. It can be used in between rounds of iteration to see how the team is doing as it develops new product concepts and tests them with users. It works in the lab, in the field, and with a large population survey. Most importantly, this research provides quantitative validation of the Cool Concepts: that they indeed reflect key elements of the users’ experience and identify the important design principles for the experience of cool. Armed with these tools, Contextual Design can help teams move the dial on their design’s coolness.
So what makes things cool? The Cool Project revealed that successful products today deliver joy in life. Joy: not just satisfaction, not just a “good user experience.” Joy: because cool products enhance our core human motivations in specific ways that we will explain. The Cool Concepts identify what is needed to design for life, and what is central to designing a product users will experience as transformative or “cool.” We redesigned Contextual Design in light of the Cool Concepts to help teams design for joy and to collect the right data about human experience needed to manufacture joy.
The Cool Concepts are broken into two parts. The Wheel of Joy in Life (Fig. 1.1) organizes the four Cool Concepts that define how cool products touch our core human motives. The four Cool Concepts of the Wheel of Joy show how products enhance the joy of life, how they make our lives richer and more fulfilling.
Accomplishment: Empower users to achieve all the intents of their life, work, and personal, wherever they are in whatever amount of time they have, across place, time, and platform. Support the unstoppable momentum of life by helping users fill every moment of dead time with useful or amusing activities. Design with the expectation that users will be distracted, splitting their attention across multiple activities.
Accomplishment in life is the main driver of the cool experience in the Wheel of Joy in Life.
Connection: Increase the intimacy and collaboration of users’ real relationships. Help them make frequent contact, have something of mutual interest to talk about and share, and find things to do together as everyone pursues their separate lives. Foster real connection in business relationships as well as personal relationships. Communities of interest—online or in person—will produce real relationships and a sense of connection if they support frequent contact, provide conversational content, and promote shared activities.
Connection is generally less important than accomplishment, unless the product’s primary purpose is to connect people.
Identity: Support users’ sense of core self and enable them to express that sense of self in what they do and how they show up to others. Identify the core identity elements associated with the activity being supported by a product and deliver products that increase the users’ sense of being their best selves. If people are taking on a new identity, help them create that identity through examples of what others like them do and by checking with friends or trusted colleagues to determine if their behaviors, choices, and values are appropriate.
Features that support success in activities core to the person’s identity increase the overall coolness of the product.
Sensation: Provide the user with pleasurable moments of sensual delight through color, sound, movement, and animation. Modern aesthetic design is expected by users today—use appropriate stimulation, graphics, and animation to enhance interaction and create products that evoke a smile. But don’t add gratuitous or distracting graphics or animation—that just annoys users and actually reduces cool.
Sensation augments the coolness of any product but is not the main driver of coolness unless the product’s value is delivering sensual delight, like games, entertainment products, and music.
The three Cool Concepts of the Triangle of Joy in Use (Fig. 1.2) show how the design of the product itself can enhance (or detract from) the joy of use by creating moments of “magic” or by eliminating the hassle people have come to expect from technology.
Direct into Action: Provide immediate, simple fulfillment of core intents: I think of what I want and I get it—with no thought, no figuring, no deciding. It just happens like magic. Think for me—give me what I want without my having to ask for it, just as the Pandora service did for music when it first came out. Produce the desired result with little or no direction from me.
Of the Cool Concepts in the Triangle of Joy in Use, Direct into Action has the most impact on the user’s joy in the use of the product. Direct into Action calls for much more than good usability and fewer clicks; it calls for true instant into action so that achieving an intent in moments is possible.
The Hassle Factor: Remove all inconveniences, setup, plugging in, logging in, boxes, customization and technology hassles from the product. Create joy by removing all the glitches and inconveniences that interrupt the flow of life. A “good enough” user experience is no longer good enough. Users no longer tolerate technical hassles and no longer value new function if it is not instant into action.
The Hassle Factor combines with Direct into Action in the Cool Metric to create one powerful design focus for creating joy in product use.
The Learning Delta: Reduce the time it takes to learn the tool as close as possible to zero by building on known interaction paradigms and natural interactions like touch and voice. Nudge the user into use with tiny hints. Reduce complexity; reduce the number of things the user has to know and places the user has to go to use the product. Avoid designing actions and options that increase complexity. Make product use so direct that there’s nothing to learn.
The Cool Project revealed that good UX and user interface design are no longer just “nice to have”—they can determine whether a product is cool or not, valued or not, purchased or not. Even a product that is cool in concept can become uncool if its use is not Direct into Action.
The Cool Project taught us that the Cool Concepts are as true of business products or IT solutions as they are for commercial products for consumers. The term “the consumerization of business products” describes how users’ expectations, driven by consumer products, are now creating demands on business products to measure up. Business products also must be designed for life: fit into the places and times life is lived, support connection to people that matter, enable users’ professional identity, and provide appropriate sensory fun—and be direct into action without hassles. This is true even for highly technical products—everyone, no matter how technical, values and expects a cool user experience.
So what is design for life? We must design our target activity so it fits into life on the go: the unstoppable momentum of life. But design for life also means that we must design for a much wider spectrum of human experience if we want our product to be experienced as cool. Design for life means that we have to take a whole-life and a whole-person perspective when doing product design.
The insights from the Cool Project demanded changes to Contextual Design itself. A design team needs to recognize and collect new types of user data on core human motives and behaviors, on wider dimensions of life, and on how the whole of the user’s integrated life fits together. So we extended Contextual Design to collect wider data about the whole of life experience, and have added new models to represent this wider view. We’re calling these new models Experience Models to emphasize their role in highlighting life experience, and to distinguish them from the previous, Traditional Contextual Design Models. We also added design principles and ideation activities, all to ensure that the design thinking of the team is focused on the right dimensions of a product to ensure success.
Immersion: tuning intuition and design thinking
Contextual Design is built around a series of immersion experiences for team members and stakeholders to continuously ground themselves in the lives of their users. Engineering-driven design, where technologists think up what they would like in a product, was typical 20 years ago—and sadly still is, in some companies today. These engineers had little contact with customers and little appreciation for the lives and challenges of the people who they were designing for. Engineers produced a list of features that they wanted or that came from marketing, and then structured the product however they thought best. Whether it’s engineers, product managers, designers, or any other of the many job roles we have today, this process of figuring out what to build without really understanding the activities of the customers relies on faith in the individual and collective intuition of the people producing the product.
When a product is formed primarily from this inner gut feel we call it “Design from the I.” You can tell if you and your teams are designing from the “I” because they will sound like this:
“I like this feature—it really works for me.”
“Well I don’t think it works best that way—I like it this way.”
“We don’t need that feature at all—I think we need to do it like this.”
Design from the “I” focuses the team of what “feels right to me.” When the team is isolated from the lives of users they only have access to their own personal experience to guide them. Without a user-centered design process, all teams have to draw on their own interactions with the tool, customer contacts, sales complaints, interactions with competitive products, and experience with their own favorite tools.
Without deep user data, teams default to designing solutions based on what seems reasonable to them—using their intuition to design for themselves. But no one on the product team is a good surrogate for the user. They know too much and love technology too much to design for the general public. And they know too little about specific work domains to get the details of a design right. Because of the way technology is thoroughly embedded in users’ lives, because of the depth of knowledge needed to understand the interplay between technology and life, and because we must design holistically across platforms, it is more critical than ever to understand the whole lives and motives of users.
Nor can a product team create a holistic design by running down a checklist of parts. Engineers and product managers both love lists. Lists can be organized, checked off, and reviewed for completion—but they never lead to a holistic design. How much interruption can a driver tolerate before they are too distracted from the road? What quick questions does a medical practitioner need answered right away—and what questions merit in-depth research? What is the interplay between large applications with lots of function and related apps for monitoring, quick decisions, and in-the-moment information? The team needs to be immersed in the everyday details of their users’ lives and respond with a coherent design if they are to get the right answers to questions mentioned earlier.
To truly design for their customers, a team must be steeped in the life context of the users they are supporting. In this way, we deliberately tune the teams’ intuition so it reflects the real life of their users. This combats “design from the I” and makes the team “get real.” So Contextual Design includes a well-defined set of immersion activities.
This immersion recurs throughout the process. Contextual Design techniques immerse the team in the world of the user, give them an opportunity to reflect and respond—and then re-immerse them, and so keep the team grounded. The first of these immersion experiences is the Contextual Inquiry field interview, when the designer sits in the user’s environment and finds out firsthand what the user’s world is like. Later, other immersion experiences expose the team over and over to the relevant data, systematically tuning the intuition of the team and stakeholders. In the face of real data about a market, it is much harder to hang onto misconceptions about the customer or favorite features that match no actual user needs.
Explicit, articulated user data gathered through a well-defined public process ensures the data is trustworthy, avoiding arguments about what is best for the users. It’s not a question of what I like versus what you like—two team members who disagree can go back to the user data and make arguments based on what they actually discovered. An initial design can be checked against the data to ensure it covers all the important points. When talking to stakeholders, design elements can be justified based on the observed user issues they address.
Immersion also guards against the almost inevitable tendency to add features that “might be useful” or that “make sense to me.” And it ensures that when quick decisions must be made, the engineers’ intuition has been tuned through repeated immersion to reflect the users’ perspective. In this way Contextual Design supports tuning the collective intuition of the team. Together they can discuss and design from a deep understanding of users’ lives.
But what about the belief held by some that good innovation never comes from talking to customers? Where does innovation come from anyway? We will talk more about innovation in Part 3, but at the core of any invention is the value a product brings to the people the invention is for. When a product delivers value that helps people live their lives and do their work better with more delight, it sweeps the market. So how do teams find that value? Contextual Design steeps inventors in the reality of the lives of potential customers. Then opportunities, delighters, tacit “needs,” work-arounds, irritations, and potential transformations stand out in bold relief, inviting the team to be creative.
We have found that engineers, designers, user researchers—all members of a team—simply love to invent. If you’ve built your team well, they know what is technically possible and what great design looks like; they know the tools and principles of their trade. Then, when these people are steeped in the world of the user through field visits and through interaction with the resulting rich data, they naturally use their skills to reinvent the lives of their users.
So no, we don’t ask the user what they need or want, as we discuss in Part 1. Users are not engineers and designers. Unlike the skilled team they don’t know what is technically possible or what good design looks like. Often they say things like, “Make it work like my current tool,” or “Make it faster,” or “Fix this one little function that bugs me.” Usability testing and rapid prototyping depend on users’ tacit knowledge to tune an existing product or prototype but these techniques are not generative—they do not lead to new product directions.
Users may make feature requests, but they don’t think of the product as a whole system supporting a coherent practice. If we only listen to these user requests, we will produce products that lack coherence, are over-featured, and are profoundly complex. As we discuss in Part 4, a product, or family of products, needs to be designed to hang together as a coherent system of support and to work smoothly in the context of the users’ life. So don’t ask your users what they want—understand the lives of your users so you can invent the product that will transform their lives. Contextual Design gives you a systematic way to do this.
Profound innovation emerges from the collective knowledge, insights, and intuition of the team who truly knows their customers. But therein is the third challenge that Contextual Design addresses, the challenge of working in teams.
Design in teams
Contextual Design is team-based. It is designed to take advantage of a cross-functional team including such specialties as product management, marketing, product architects, UX designers (user research and user interface), visual designers, developers, service designers, and more, each providing their unique skills and insights to help invent the right solution for users. Contextual Design builds in ways of involving stakeholders and other team members to assure buy-in from the business and ensure the solution is one the company can successfully deliver.
The reality of product creation is that it takes many people to make and ship a product. Commercial products, IT systems, cars, medical devices, games, even apps—all require the work of many coordinating people. And all these people contribute to defining requirements and translating those requirements into design, specifications, and implementation.
All these people need to have a shared understanding of both the user needs and the agreed product solution. Achieving a shared understanding isn’t “nice to have”—achieving a shared understanding is at the center of shipping successful products in a reasonable timeframe. Products generally don’t fail to ship because the technology doesn’t work or because the people can’t think up features. Products don’t ship because people can’t come to agreement.
The challenge of a shared understanding doesn’t go away with a small team or the “One Great Guru” theory of product development—the idea that you can hire one smart person and let him or her do it all. No “One Great Guru” can ever do it all. And as soon as multiple people are expected to coordinate to deliver, they must operate from a shared understanding to be effective. Product development is always about people acting together and in parallel based on a common understanding of the problem and the solution.
Unfortunately, people come with a host of idiosyncrasies, cognitive styles, cultures, interpersonal tendencies, and personality quirks. No organizational role definition, careful separation of the code into independent modules, management rules, organizational structures, or fun outings to build team spirit can eliminate the need to deal with the issues of getting people to work together well.
One division manager addressed a particular thorny problem by booking rooms at a local hotel, sending his five senior architects there, and telling them they were fired if they didn’t come up with a solution in a week. He got a result, but we find people are usually happier, more creative, and produce results more quickly if they have a reasonable process to work in. The typical response to having a process—even from people who say they hate process—is, “Thank you. Now I finally know what to do.”
This organizational challenge—this need for a shared understanding and coordinated action—underlies many of the techniques used in Contextual Design. We don’t address the whole of the product development life cycle, but we can get the team started by using clear, structured techniques for working together. Throughout the book we will describe techniques that are built around a set of principles that make creative face-to-face work. Here are some core considerations built into Contextual Design.
Use a cross-functional team: Different perspectives on the problem lead to divergent, creative solutions. Including diverse job roles is one way to get different perspectives.
Manage interpersonal dynamics: Divergent perspectives and interpersonal differences will deliver a more creative solution—but they will also create tension in the room. Structure the process to manage and direct that tension toward the design problem rather than the participants.
Create a creative team culture: Articulate the process and the group norms to foster creativity. Group culture doesn’t happen by itself—so Contextual Design includes elements to foster a productive team culture.
We explore these elements in detail in the Interpretation Session chapter, the first intensive design meeting in Contextual Design. But as you read the next sections, you’ll see them start to emerge in the very first team activities.
Contextual Design V2
The first edition of this book introduced Contextual Design—a complete, user-centered front-end design process. This edition introduces Contextual Design V2.0—Contextual Design updated for modern technology, device use, and device capabilities. With Contextual Design 2.0 you can not only make your products useful and innovative—you can make them transformative and loved. When you find your users saying, “After using this product—I’d never go back!” you know you won.
Much of what we do in Contextual Design is to make explicit and public things which good designers do implicitly. Each part of Contextual Design reflects an aspect of the design process which has to happen anyway—either informally in one person’s head or publicly as an explicit design step. So Contextual Design explicitly defines how to gather, interpret, and model data about how people live and work, organizing it so that design teams can use it to drive ideation. It includes techniques which manage the interpersonal dimension of designing in cross-functional teams and keep designers focused on the implications of this data for redesigning life and work with new technology solutions. It organizes design thinking sessions to help teams structure the potential product and defines ways to validate that what is shipped is actually desired. With articulated, teachable technique teams are clear about what to do to achieve success—and how they may modify the techniques to better suit their specific needs.
In this book we introduce you to the techniques of Contextual Design in five parts. Each part starts with a chapter introducing the issues and principles of that part. Then it is followed by two or three chapters describing the techniques. We end with a chapter concluding the book.
Part 1: Gathering user data
Chapter 2: User data drives design
User-centered design starts from the recognition 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.
Chapter 3: Principles of Contextual Inquiry
Contextual Inquiry is the core field research process of Contextual Design. In this chapter we describe the four principles of Contextual Inquiry: Context, Partnership, Interpretation, and Focus. We talk about how the Cool Concepts affect the interview situation. We describe how to structure the interview itself and how to tailor the interview to different kinds of project. These field visits are our first immersion activity, putting designers out in the users’ world.
Chapter 4: The Interpretation Session
Gathering data isn’t enough—the insights need to be shared across the team so that everyone can see the issues and work toward a common goal. In Contextual Design, we make all design activities team-based so that everyone builds the insights and designs together. Every interview is captured and analyzed through an Interpretation Session, a team meeting where the whole team (or a representative subset) can see the data and pull out the implications. This is our next immersion activity, allowing the whole team to experience each interview.
In this chapter we describe the structure, roles, and process of the Interpretation Session. We also take the opportunity to discuss team-based design and how to use our understanding of working in teams to define a design process that works.
Part 2: Revealing the world
Chapter 5: From data to insight: Contextual Design Models
Just asking designers to go out in the field and run inquiries is a big step forward. But it’s still a challenge to see what matters when you’re there. The user’s world is complex, overwhelming, and full of a million details—some of which matter for any design problem and many of which don’t. It has become a larger problem over the years to communicate insight from the user research to the whole product team, so that everyone can see what matters. Contextual Design has always used models of the user to communicate; with Contextual Design 2.0 we’ve expanded those models to communicate the aspects of design that matter for today’s highly connected technology. In this chapter we discuss the problems of representing user data to reveal what is going on across an entire market.
Chapter 6: The Affinity Diagram
Any type of ethnographic or qualitative data is hard to organize. It’s complex and unstructured. The easiest methods of organizing the data, some sort of classification, tends to work against innovation—if you organize data into a classification you already know, how do you get new insight? The Affinity Diagram is an inductive process that bubbles structure up out of the details of the user data. It creates a single view of the market out of hundreds of individual data notes. Building it acts as another immersion activity, as the whole team comes together to organize the data. This chapter describes what an Affinity is and how to build one that will drive design insight. It also introduces communication design as an essential skill for organizing data to drive innovation.
Chapter 7: Building Experience Models
Contextual Design 2.0 introduces a new set of models, the Experience Models, derived from the insights of the Cool Project. The Cool Project defined four ways that technology enhances life: accomplishment, connection, identity, and sensation. The Experience Models focus the team on these concepts to ensure that the team recognizes them when they see them, and captures the data in a way that enables the team to design for them. In this chapter we walk through each Experience Model, describing the model, how to collect data for it, how to use it in Interpretation Sessions, and how to consolidate the data into a view of the market based on the data of individual users. The models we cover are The Day-in-the-Life Model; the Identity Model; the Relationship Model; the Collaboration Model; and the Sensation Board.
Chapter 8: The Traditional Models
The Traditional Contextual Design Models introduced in the first edition of this book are still viable and offer insight, but we have found that we rarely use some of them. In this chapter we discuss the Traditional Models that we do use regularly, and their variants: The Sequence Model; the Decision Point Model, derived from the Cultural Model; the Physical Model; and Personas.
Part 3: Reinventing life
Chapter 9: Inventing the next product concept
More than ever, technology is inextricably integrated into daily life; designers today are truly reinventing daily life by creating a human–technical system, a way of living and working augmented by our products and systems. That product is no longer likely to be a large monolithic application but rather a constellation of products, apps, and platforms to help us get an activity done. Successful innovation results when a cross-functional team skilled in the modern materials of design is immersed in structured customer data. Then they naturally recombine elements of practice, technology, and design in new ways to create a vision of new product concepts. In this chapter we introduce the necessary ingredients and processes that help your team innovate consistently.
Chapter 10: From data to design—the Wall Walk
At the core of innovation is immersion in the world of the user. Having produced the Affinity Diagram and consolidated models tuned to reveal insights and issues, the team is ready to use the models to drive design thinking. In this chapter, we describe the Wall Walk, a process whereby the team interacts with the consolidated data, letting it stimulate initial design ideas. The Wall Walk is a time-tested process for ensuring that the data collected drives invention.
Chapter 11: Ideation—Visioning and the Cool Drilldown
Good product design ensures that the life of the user is enhanced, enlivened, and remains coherent. The best way to ensure a coherent life is to reinvent technology in the context of telling the story of the new ways that users’ activities might be transformed by introducing technology. In this chapter we describe the Visioning workshop, a group storytelling process focused on reinventing life, not on technical solutions. This results in a set of visions implying new product concepts. Then, we describe the Cool Drilldown where the principles of the Cool Concepts are used to hone and enrich these new ideas.
Part 4: Defining the product
Chapter 12: The challenge of product design
Products aren’t just standalone tools, particularly not in this day and age. Products—even cell phone apps—exist in a larger ecosystem of tools, processes, habits, and technology. Any new product has to fit into this ecosystem while simultaneously transforming the users’ lives in desirable ways. The design team must not only think about the users’ lives as a coherent whole, they must design a product that is also coherent, having the appropriate structure to best support the user. In this chapter, we lay out the challenges of detailed product design and introduce Contextual Design’s techniques for helping teams see and define product structure in a way that keeps the user practice coherent.
Chapter 13: Storyboards
Telling stories of how people will work in the new system we’re designing helps the team keep the user’s life coherent. Storyboards are like freeze-frame movies representing to-be scenarios of the user’s practice. These stories ensure that a task or activity works—the things the user wants to do are supported and that they can flow from step to step conveniently. Storyboards ensure that designers think through the different activities, strategies, and situations that have been revealed as important in the field data or are relevant to the Vision. In this chapter we describe storyboards and how to build them.
Chapter 14: The User Environment Design
Storyboards ensure the tasks and the flow of life are coherent, but they don’t keep the system coherent and well-structured. The new product or feature set must have the appropriate function and structure to support a natural flow of interaction. For that, Contextual Design uses the User Environment Design. The User Environment Design is a floor plan of the new product showing the places in the product, the function in that place, and the links between one place and another. It shows the parts of the product from the user’s point of view and helps the team think structurally about the product. In this chapter, we describe the User Environment Design, show how it is represented, and lay out the process for building one from the storyboards.
Chapter 15: Interaction Patterns
The User Environment Design lays out the structure of the new system. It doesn’t define the look or layout. As with all aspects of design, Contextual Design gets the high-level structure right first, then designs the detail. Interaction Patterns help the team think structurally about the high-level structure of each page or screen in the User Environment Design. We give principles of design and layout to ensure this interface structure works for the user’s activities and defines a user interface architecture that is both modern and ensures consistency across the product. We discuss the importance of having designers on the team and how to structure the interface but we do not cover detailed UI design—there are many other good books on this topic.
Part 5: Making it real
Chapter 16: Making it real
In Contextual Design we drive product concept and structure from a deep understanding of the users’ world. Once the User Environment Design and Interaction Patterns are defined we have a working hypothesis of what we think will deliver value to the target users. But we don’t know if that is true—and we have a high-level design, but are likely missing lower-level details. All this is best tested and worked out with the user during paper prototype interviews. Furthermore, the result of any design process will likely generate more than a team can ship in a reasonable timeframe. In this chapter, we introduce the steps needed to make the product real and define a release that will deliver value. To do that the team needs to validate and iterate the design with users and then plan a rollout strategy that delivers the concept in useful, product-sized chunks. Last, we talk about how to set up and run the overall Contextual Design project providing practical advice and perspective.
Chapter 17: Validating the design
Testing is an important part of any product’s development process, and it’s generally accepted that the sooner problems are found, the less it costs to fix them. Rough paper prototypes of the product design test the structure and user interface ideas before anything is committed to code. Paper prototypes, now a well-known, documented practice, support continuous iteration of the new product, keeping it true to the user and giving designers a data-based way of resolving disagreements. In prototyping sessions, users and designers redesign the mock-up together to better fit the user’s activities. In Contextual Design we use a combination of paper mock-ups, online mock-ups, and early versions of running code to get the right kind of feedback at each stage in the process. In this chapter, we introduce how to build a mock-up, run a paper prototype interview, interpret the data, and update the design for the next round of testing.
Chapter 18: Prioritization and rollout
Your Contextual Design project will produce a larger design than you can build in one version. That is a good thing because it helps you see where you are going next. So every Contextual Design project needs a prioritization step. Choosing what to put into each release is a design and communication challenge—the cross-functional team, including additional players from development and marketing, must come to a shared understanding of what to release. Prioritization works best when it is based on what is of true value to the customer, what will make enough splash to be worth shipping, and what is doable technically in the time available. In this chapter, we describe how to partition the validated User Environment Design into reasonable releases while keeping the user’s practice, UI design, and overall system structure coherent. With an agreement in hand, the different organizational functions can work in parallel to ship the release.
Chapter 19: Project planning and execution
Having described the techniques of Contextual Design, we step back to talk about how to organize the team and the project for success. In this chapter, we describe how to set the project’s scope and focus to map the business mission and willingness to innovate. We describe how to put your team together, considering both cross-functional roles and the leadership needed on the team to ensure success. We describe how to plan who and how many people to interview, how to gather data in challenging situations, and how to schedule the work. We end with a discussion of how to manage the team. This is a practical chapter to help you get your project started.
Chapter 20: Conclusion
In this brief concluding chapter of the book we return to the core principles of Contextual Design: immersion, design for life, structural thinking, and team-based design. We wrap up insights and reflect on the future.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.