Hidden in the details of real life is the structure of the day and how activities play out within it, why we do what we do, who we do it with, how we feel about ourselves when we are doing it, the culture we are operating in, and more. Dealing with this complexity to help a team see a big picture of their users’ lives is our challenge. If we do it well, we will reveal their challenges and potential delighters, failed communications and collaboration patterns, invisible yearnings, and core motivators. Now you have the context you need to reinvent their lives with technology.

So how do we make the complex approachable? Remember the human anatomy books many of us had as kids? First, you see an outline of the person; then successive transparencies overlay the skeleton, then the blood, then the nervous system, and so forth. Understanding the person as a physical organism is complex and messy, but those books broke it down into meaningful subsystems—the skeletal system, neurological system, and cardiovascular system—which encourage thinking about one system at a time. By looking across all the systems, we have a shot at understanding the whole body and the interaction between the parts (Fig. 5.1).

Identifying the body’s systems led to whole professions surrounding each system. Researchers were able to pay attention to each system, find its structure and rules, see how it interacted with other systems, develop hypotheses about how it worked, investigate chemical interaction, and so forth. A whole professional language developed to describe what was going on—that’s what medical jargon is. A specialized language of this sort creates a focus—a set of things to pay attention to. Once you know how the pulse sounds in the ventricles of the heart, you can start to make sense of the noises a body makes. The medical language gives doctors a way to see—a way to interpret what is observed and a structure of understanding they can elaborate as they learn more.

Because a language creates a focus, it is not neutral. It directs your thought. Any language is designed to say certain things easily—the things for which it provides concepts. Artists have a language of color, shape, and shade to talk about the sky; meteorologists have a language for talking about the sky too, but it is very different from the artist’s language. Which language is better depends on whether your current concern is aesthetics or weather. So language reveals and conceals—meteorologists have many words for clouds, enabling them to see more when they look at the sky and to draw more meaningful implications for the weather. But do they forget to appreciate a sunset? In this way, language structures thought—which can be constraining. We must be able to use the point of view it offers but deliberately break it when we find the data doesn’t fit.¹

Complexity is simplified and made actionable through frameworks such as the physiological systems of the body. Similarly, Contextual Design models provide a framework for understanding human behavior and experience for the purpose of design action. Any practice has structure—it hangs together to achieve work and life intents. But that structure has many aspects. People take on roles and responsibilities, collaborate with others, act out of core values and identity, and are influenced by culture, organizations, physical location, and space. So to see life we need to look at it from multiple points of view. We need multiple models, each focusing the team on a different aspect of work and life.

Each model expands the team’s entering focus, enabling them to see more details when they interview. This is a starting point—team members can expand on this focus, creating new concepts and distinctions unique to the domain they are designing for. The Traditional Contextual Design Models we introduced 20 years ago represented the core dimensions of practice for designing task support:

Along with the issues captured in the Affinity Diagram, these models provide a 360-degree view of the context of the target task. These models are our first framework for understanding the users’ lives. And these models were sufficient for any project we encountered for over 20 years.

But then came the radical transformation of life introduced by truly mobile touch-screen devices. Technology now touches more of life—and the worlds of work and personal life are being merged. The Cool Concepts expanded the framework needed to understand our users. To support inquiry into these areas of life, we developed new data collection techniques, new models, and new design practices. To help teams characterize life as represented in the Wheel of Joy in Life, we created the Experience Models:

These models reveal human behavior and experience. They show what people are doing to get the activity done, their responsibilities, and their motives. They reveal the activity within the context of the larger physical and emotional life.

With all 10 models, our view of the world of the user is greatly expanded. Each model brings its own point of view into focus and challenges the team to think from that point of view. But we have learned that in practice, not every model is necessary for every project—and 10 points of view is too many for a team to use productively. Today, when we plan a project, we pick only the models most relevant to the problem.

Because of changes in the nature of technology and practice, many of the Traditional Contextual Design Models are relevant in only a handful of projects. Mobile apps have a narrow focus on a single core intent; large enterprise applications supporting huge corporate processes are giving way to suites of focused function sets with additional apps to fill the gaps. New functions in these enterprise systems are chunked into “products” organized by target activities. IT is building less and buying more. As a result, the Flow Model, which focused on process and complex collaborations, is often not needed. Most artifacts are already online these days, so the artifact model gets much less use. The physical environment is no longer a single place—an activity is continued throughout the day, wherever the user is, so there’s not one physical environment that matters. And in a world that is increasingly multicultural and characterized by remote work, cultural influences are diffuse—more easily represented within the Affinity Diagram. All of the Traditional Contextual Design Models can be useful depending on the project. And for some we have developed variants which we have found useful. But in our projects now, our focus has shifted largely to the newer models, the Affinity, and the Sequence Model.

We discuss the Affinity Diagram in Chapter 6, Experience Models in Chapter 7, and the Traditional Contextual Design Models in Chapter 8. We introduce each model, how to collect data, interpret it, and consolidate the data to build the model. We also discuss when each model is most useful.

To see the longer discussion of the original Contextual Design Models go to http://booksite.elsevier.com/9780128008942 where text from the first book is available for reference.

Why do graphical representations work? Unlike a textual language, graphical representations let you take in a whole picture at once. A textual language must be read and parsed; this is not only a difficult chore, but the information has to be taken in sequentially, one idea at a time. Given reasonable methods for handling complexity, a picture can be scanned and taken in as a whole. A picture is a better external representation than a page of text—it’s easier to see what you are talking about. A picture reveals overall pattern and structure by showing each part in relationship to the whole. This is critical to creative work and design. Once a team understands the target activity in the context of life, they can identify inventions and interventions that make sense for the people and the project goals. Without a coherent understanding of the practice, each need or problem stands alone and can only drive single-feature solutions. It’s hard to see when a solution to one problem creates new problems elsewhere—just as automated phone systems solve the problem of giving quick answers to standard questions but make it difficult to get to a live person to deal with nonstandard situations. A diagram supports systemic thought and makes it possible to create a coherent design response.

Each Contextual Design model represents one face of the practice in a coherent graphic. Multiple models allow the team to synthesize the whole practice by systematically looking across multiple models. This reveals the entire practice in an organized way. People won’t overfocus on the Sequence Model’s steps when they have the Day-in-the-Life model showing the whole life context. They won’t worry only about supporting the tasks of the activity when they have the Identity Model reminding them of core motives and attitudes. They won’t forget that the activity is embedded in real relationships and collaborations when they have the Relationship and Collaboration model. Multiple models provide a digestible view of the complexity of the user’s world.

For these reasons, we use graphical models to capture knowledge about the users’ life and practice. They provide a shared focus on an activity which gives the team an external, concrete form to record and communicate what they saw on user visits. As long as users’ practice remains insubstantial and invisible, there’s no good way to share what you learned or to check that your design really accounts for the practice you discovered. Models make concepts concrete, creating a physical artifact the team can talk about and touch. Teams can use them to share with stakeholders, other interested teams, and each other as a record of what was learned and as a way to focus design thinking.

By providing a coherent, synthetic view of the practice, Contextual Design models give design teams effective ways to handle qualitative data. Any qualitative technique such as Contextual Inquiry produces huge amounts of detailed knowledge about the user. This knowledge is critical to product design but isn’t amenable to reductive statistical techniques: you can’t take the average of 20 interviews to identify the “typical” user. Graphical models provide a coherent way of structuring all this detailed data, revealing the underlying structure and experience, eliminating irrelevant detail, and bringing important aspects into focus.

In themselves, the models represent a significant deliverable for user researchers, UX designers, and product teams. They remind the team of what they saw in the field; they evoke users’ practice and help team members who were not present envision users doing the activities; they are the source of any needs analysis, the origin of new design ideas, and a statement of the real world of the users. As such they are the arbitrator of argument about what the users are or are not doing or feeling.

But most importantly, because they are physical, able to be interacted with, they drive design thinking. They are the way teams move toward a more transformative, more systemic product concept. Insight comes when brilliant designers are immersed in the world of the users as represented by the models. Design for life is easier with the life represented physically. And team buy-in is helped when the team builds the data themselves and uses it to drive design.

So if a product can address the needs and delight a whole user population, it’s because aspects of the activity are similar across all users: common structure, strategy, and intent; common motives, values, and experiences. A design responds to the common approach associated with the target activity while allowing for individual variation among people. But how can we discover these common aspects? How do we recognize them among all the surface differences in how people act and feel? And how do we represent the common aspects of life so a design team can respond to them?

We do it with data consolidation, but people often have a hard time believing it works. It is common, for example, to hear vendors of the productivity tools we all use say, “We have millions of users, and they all use our product differently. There is no one office user.” They put themselves at a standstill—there’s no way to go on to understand those aspects of the activity which are common. There’s no way to find the common tasks and motives which, if they were better supported, would give a product a market advantage. There’s no way to see the common flow of activity which a suite of products and apps could successfully support.

It isn’t just vendors who say that all their users are different. People are invested in being unique, and the first thing that users often say is how different they are from everyone else. But much of the detail that makes people different is not relevant to designing a product for a market—the common pattern, structure, and experience related to a target activity; it is this common pattern, structure, and experience that make generic software possible.

For example, when we first studied configuration management, we found that some companies made it a very formal process, with people who have the job title “Configuration Manager,” who decided what went into a configuration and made sure it got built and tested. These days, small companies value minimal process, continuous integration, and frequent release. In a startup company with web-delivered software, we found the engineering manager walking around to people saying, “Remember we go live with the new features tonight! Lisa, make sure your stuff is integrated. Anil is testing now. Joe, keep your stuff on its own branch—we’ll integrate it tomorrow.”

The first organization recognized the role and formalized it as a job; the second didn’t recognize the role formally but made sure someone was responsible for performing it informally. The role is part of the common work structure of the market; the different ways of assigning the role as a job are differences of detail. A product could be structured to support both types of organizations, though it might have to be packaged and marketed differently to deal with the customers’ different attitudes. Whether we like it or not, given any target activity for workers or consumers, the variation in how and why people do things the way they do, the technology they use, the concepts they operate from, the things they manipulate to get things done, simply doesn’t vary all that much. This is at the root of why a small population of well-selected users can characterize markets of millions.

And what if the data can’t be consolidated?² Contextual Design models show teams how to address a market strategically, segmenting the market based on similar practice. If the practice and experience is common, it can be represented in a single set of consolidated models. Where the models identify differences—such as different cultures—they show how the product must be packaged or sold differently to different groups of people. But when one set of models cannot represent all users, it shows that there is not one market. It shows that the structure of the activity in the two contexts is likely too different for a single product to address.

Data consolidation and the thinking process behind it are the key to getting a reliable, actionable view of the market. Products serve whole markets, but we can only find out about users by talking to them one on one. Consolidation brings the data from all users together into a single, coherent view, showing common patterns without losing the key variation across users. The challenge of consolidation is to do explicitly, on purpose, and externally what is usually tacit, haphazard, and internal: develop a sense for a whole target population from particular instances and events.

All consolidation is the result of induction, reasoning “from the particular to the general, from the known to the unknown.”³ The goal of consolidation is to generate new insights about users, their behavior, and their experience. You can’t develop new insight by applying existing rules and concepts to the data—all you’ll ever discover is more detail about the things you already know. The consolidations we build in Contextual Design use induction to bring together many instances from individual interviews, discovering structure hidden in detailed observations. In this way we can reveal new concepts, patterns, and insight relevant to characterizing the market for a target activity.

Quantitative techniques make data manageable through data reduction—for example, by looking just for the top findings—which hides the richness of the actual data. Contextual Design doesn’t reduce the findings—it synthesizes the individual observations into higher-order insights. Synthesis through inductive reasoning simplifies the complexity of the data and makes it approachable. To get this insight we start by consolidating data from multiple users at the same time. This ensures that the team is faced with enough data to see patterns and develop new insight. The volume of data forces the need for structure and challenges the team’s entering assumptions about what the themes are. If we organize the data by a priori assumptions and categories, we will not discover insights we haven’t already thought of. This is the power of inductive reasoning: to group instances together into meaningful elements to reveal core elements, experiences, and patterns. This creates new insight.

Because the structure is built up out of detailed observations, consolidations naturally accommodate variation among users. Examining users one by one, designers might have seen only random differences; but bringing many users together through inductive reasoning reveals how differences may be variations on a theme. If one person prefers to write an outline before starting a paper and another just talks out her ideas, we can understand that these are different ways of clarifying thought before starting to write. New variants in user data can be recognized and positioned within the consolidation structure—so someone who wrote lots of different rough paragraphs and then went back to rewrite them can be recognized as achieving the same intent of clarifying his thoughts but in yet another way. Variations exist within a larger structure of understanding. Consolidation through inductive reasoning provides a way to help the team think about complex data without tossing out the complexity.

Consolidation is a process of inquiry: looking at details from specific users and asking how each detail has meaning for the project and fits with observations from other users. When the key insights bubble up from individual observations, we then label the groupings in the voice of the user. Though it’s applied differently for each kind of model, this same thinking process is used in all model consolidations. When done as a team, a consolidation design meeting acts as an immersion experience: team members who participate in consolidating the data interact with it intimately and learn the user’s world.

Contextual Design’s consolidated models synthesize the complexity of qualitative data into a set of graphical representations revealing a big picture of the target market. The consolidated models focus and drive design action through ideation, by communicating the insight to a team tasked with invention.

In the days when developers were the primary team members, they were the source of insight and had to do their own synthesis. They loved the Traditional Contextual Design Models because all the detail was available, unfiltered but organized into models similar to those they used for data representation. They did not want—and often did not trust—the emerging user researchers to do this for them. The Affinity, which everyone loves, is a simple hierarchy, organizing the actual data points into a structure that gives access to the detail. The Flow Model looks like the bubbles and arrows of dataflow diagrams; developers could transfer their inquiry skills from data modeling directly into understanding people. The Sequence Model focuses on specific tasks; task analysis and flowcharts were also known forms. Once they were into the idea of models of human behavior, it was easy for them to use the models to organize user data. Gleaning the meaning of the models was their job.

But the user experience field has grown into a profession with university degrees and many user-facing job types. Technology has changed so that products support less technical users. Consumer products and websites have technology built into them. As a result, teams doing requirements and design now tend to be composed of content experts, UI designers, user researchers, information architects, product managers, marketers, editors, and more. Developers and technical architects are less often a primary part of the team collecting and organizing data. They may be part of ideation based on the data, but they no longer dominate ideation.

This new population of designers is not used to complex data representations such as dataflow diagrams. They looked to us to simplify and focus the findings. And this is true for managers as well. The desire to see and manipulate all the data gave way to the need to structure the data to reveal in a single glance the most important patterns and insights of the data collection team. The Decision Point Model, a variant of the Cultural Model, grew out of that effort; it shows the influences on people when making decisions for purchase or in life. Data captured in the Flow Model evolved to focus more on work groups, core roles, and discrete process—eventually emerging anew as the Collaboration Model. The Physical Model, when used to represent cars and homes, became enriched in layout, color, and story content. Over time, we began changing the original models to better match the needs of modern cross-functional design teams.

When setting out to design the models needed for the Cool Concepts, we also looked at which models best stimulate design thinking. This was easy to do because during the Wall Walk (described in Part 3), designers write ideas on sticky notes and put them on the model that sparked the idea. If a model collected few ideas, it was clearly not getting into the minds of the designers and was not driving product concepts. So our measure of success of any model became the number of design ideas it collected. The Affinity Diagram has always collected the most design ideas so we looked at its attributes to get insight when designing the new models. Other models, though still beloved by many developers and designers, did not pass the design idea test. This included many of our original Contextual Design models, including the Sequence Model. People value it for guiding scenarios, but it rarely stimulates new product concepts.⁴ When Personas⁵ become popular and we added them into our processes, we noticed that although they provide stories which helped focus the team, they too failed the design idea test. And the Flow Model was simply too complex for many people to approach. So our goal was to create models that were so approachable that they would naturally drive design thinking.

We designed and redesigned the new models, iterating them with teams until they stimulated design ideas in good numbers. By introducing these new models and the new approach to building them, we saw a huge change in the quality and scope of the design concepts that teams generated. The new consolidated models when used during visioning pushed teams to consider the whole life in the way we intended. Teams naturally generated design concepts to deal with the user’s whole life and motives.

This evolution revealed the absolute necessity for and power of communication design. Effective design depends on the UX professional’s ability to communicate the user data and insights in a way that is comprehensible by the people in the design process. Communication design, the intentional creation of artifacts that communicate user data, is a necessary design step and an important skill for all UX professionals.

At this writing, Contextual Inquiry has been taught in universities for well over two decades. UX groups are now a standard part of technology companies. But the creation of UX groups tasked with research means that all the insight and deep knowledge about users tend to be locked in that group. Transferring not just knowledge but insight, understanding, and a feel for the user’s world is the first step in creating a bridge between data and design. One of the greatest challenges for UX professionals is how to drive data into the ideation process; how to ensure that the lives of the users actually impact design thinking in the large. This is the single biggest question we get from UX professionals—how to get the product team to design from the user data.

The consolidated models of Contextual Design V2 are designed to help teams internalize the world of their users. The principles of good communication design are built into the model consolidations so that you can implement them easily. Designing the communication is critical to successful ideation because it is at the center of the bridge from data to design action. Communication design has its own set of principles that make it work; we’ll illustrate these as we discuss the consolidation process. Here is an overview:

The new Experience Models were designed with these principles in mind and include guidelines on color, whitespace, number of graphical elements, text length, and writing voice. Feel free to copy and use what we have done with your design teams. The Traditional Contextual Design Models have also been adapted to communicate more powerfully. The Journey Map⁶ that we and many people use is an example of communication design.

Each model implies that certain type of data must be collected at the field interview and captured during the interpretation session. We will introduce these processes as we describe the models. But note that modeling is integrated with data collection and interpretation—it’s not a separate process done on its own. Models are initially created during the interpretation session. As the interviewer retells the story, modelers listen for the relevant data elements and capture them in the model.

Capturing models in the interpretation session make it possible for the team to describe and analyze aspects of the user practice in a concrete, shared, tangible way. They also automatically teach the design team how to see more when in the field.

Once the team has conducted 12–16 interviews do a preliminary consolidation. Build the Affinity Diagram and whichever Contextual Design models you select. If the project plan calls for 16 interviews or less, this consolidation is final. Otherwise, this preliminary consolidation lets the team reset focus for the remaining interviews and dive deeper into areas that look weak. After interpreting the remaining interviews, the team rolls the data into the existing models, makes appropriate changes, and prepares the final graphical representation. All graphical models and the affinity are put online and printed in large format so that they can be hung on the wall for ideation.

In the modeling chapters we describe the data collection, interpretation, consolidation, and communication design practice for each model. But first let’s look at building the Affinity Diagram.