The sad news about product design is that it requires people to make and ship products. Products, systems, cars, medical devices, games, even apps—all require the work of many coordinating people. First, we have the development team; then add in marketing, product management, and testing; top with user-centered design roles: user interface, user research, user experience, visual design, and industrial design; and add planners, business analysts and all the managers and stakeholders. All these people have something to do with defining requirements and translating those requirements into design, specifications, and an implementation.

All these people need a shared understanding of both the user needs and the solution. Achieving a shared understanding isn’t “nice to have”—achieving a shared understanding is about shipping product that delivers value in a reasonable timeframe. Products 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 Brain” theory of product development. Why? Because as soon as multiple people are expected to coordinate to deliver, they must operate from shared understanding to do their jobs effectively. No “One Great Brain” can ever do it all. Product development is always about people acting together and in parallel based on a common understanding of the problem and the solution. In the end, no matter what we wish or hope:

This organizational challenge—the need for a shared understanding—underlies many of the techniques used in Contextual Design.

Contextual Design solves the problems of people working together through the techniques of CD itself. CD fosters a shared understanding in many ways throughout the process. But it starts with these elements:

• Use a cross-functional team to do the work
• Interpret the data together
• Model the data to reveal the work practice
• Ground solution ideas in structured customer data

Tower of Babel “Now the whole earth had one language and few words. And as men migrated from the east, they found a plain in the land of Shinar and settled there. And they said to one another, ‘Come, let us make bricks, and burn them thoroughly.’ And they had brick for stone, and bitumen for mortar. Then they said, ‘Come, let us build ourselves a city, and a tower with its top in the heavens, and let us make a name for ourselves, lest we be scattered abroad upon the face of the whole earth.’ And the LORD came down to see the city and the tower, which the sons of men had built. And the LORD said, ‘Behold, they are one people, and they have all one language; and this is only the beginning of what they will do; and nothing that they propose to do will now be impossible for them. Come, let us go down, and there confuse their language, that they may not understand one another’s speech.’ So the LORD scattered them abroad from there over the face of all the earth, and they left off building the city.’ Therefore its name was called Babel, because there the LORD confused the language of all the earth; and from there the LORD scattered them abroad over the face of all the earth.” (Genesis 11:1-9)

Cross-functional teams capitalize on multiple perspectives

Every person involved in product development comes to the job with their own personal experiences. We each see the world from our own point of view, filtered by our unique history. So when we look at user data or user needs, it’s like we are carrying around our own personal flashlight that shines light on the things we think matter, leaving everything else in darkness. Marketing people naturally see trends, themes, and motivations. Developers naturally see the possibility of function (“fix this”) and data structures. Usability testers tend to see problems. UI-type professionals see the interaction and graphic design detail and how pages and function is laid out. Data modelers see data and business people see business problems. And so it goes.

We each have our personal focus based on our lives and our professions. It’s this focus that drives what we see in the world and what we think matters. Herein is the problem—we don’t actually live in the same world of experience. And yet our various points of view matter to the ultimate success of the product.

Deming, the quality guru, held that to deal with this problem we need to walk in one another’s shoes. He recommended that people rotate through jobs in a company. But this is time consuming. More importantly, different people have different skills and interests—they aren’t necessarily interested in trying out all the jobs just to be able to see through others’ eyes. Beneath Deming’s idea is that if people can have the same experiences they are more likely to have respect for others’ points of view.

Inspired by Deming, Contextual Design starts with a cross-functional team. Not to oversee the project; not to review direction; but to actually do the work together for a limited period of time. One interesting lesson we learned is that shared understandings don’t come from typical corporate meetings—and they don’t come from doing HR team-building activities together. Shared understanding comes from doing real work together in situations where individual expertise informs the work but doesn’t guide it; where each person comes to the activity as an equal.

We start this process by immersing the team in the user’s world. There is nothing more powerful than going to the field—and there is nothing more leveling than going to the field. In the field, people get a visceral experience of their users’ lives. This immersion always opens eyes and reveals things no one ever thought of. And because each member of a cross-functional team comes at this experience from their personal focus, each team member will see different things. This is good—because the team as a whole sees more than any one person could.

But it is unwieldy to have all members of the team troop around in the field together so they all see at the same time. Sending everyone out to the field together wastes time and money. But worse, it’s hard for the user to behave naturally with five people watching!

Instead we created the interpretation session.

Interpretation Sessions naturally bring perspectives together

The Interpretation Session is a structured meeting that helps create a shared understanding across a team and overcomes the boundaries of individual points of view. Team interpretation sessions bring the design team together to hear the whole story behind each interview and capture the insights and learning relevant to their design problem. Through these structured discussions, the team captures issues, draws work models, and develops a shared view of the needs of the one customer whose data is being interpreted.

During this process something magical happens:

“Capture that,” a marketing person says. “That’s important!” “What’s important?” thinks the developer. “Oh, they are looking at brand!” “Capture that,” the developer says. “What?” the marketing person thinks. “Oh, I see, they are seeing how data is used from multiple applications!” “Can you believe that horrible interface—there are so many layers,” the UI guy says, watching the user struggle to get to the desired place. “Oh!” the other team members say. “Yes, I see!”

When a team is focused on the same data they can hear each other react to the data from different points of view. In this context the different perspectives become tangible and real because they are situated in the real life data of the user.

In CD an interview is interpreted within 48 hours. This ensures the quality of the data recorded, requires no preparation for each session, and ensures the team doesn’t get overwhelmed by reams of data to interpret at once. But quick interpretation turn-around also requires the team to alternate continuously between collecting data and interpreting it. As a result each interviewer’s point of view continuously expands through participation in the interpretation sessions. When they return to the field to collect more data they bring this new larger perspective to the data collection itself. As each team member learns how to see from multiple points of view, the data gets richer. The team creates a shared understanding of the data and the meaning of the data without trying.

The interpretation session with a cross-functional team naturally shapes a larger common perspective and builds buy-in to the data findings. Even if every developer or product manager can’t be on the team (we like to keep it to 4-6), if each constituency has someone they respect on the team, they are more likely to buy-in too. Plus we encourage visitors, one or two at a time, to interpretation sessions spreading the experience more broadly. In a people-centered business—and all design processes are people-centered—this saves time.

Work Models make the intangible tangible—and sharable

If I ask you for a cup you can pick it up and hand it to me. But if I ask you for your understanding of the users’ practice—what can you point to? A list of needs is not the practice; a feature list of design ideas to support those unarticulated needs is certainly not the practice. How does a team get a shared understanding of what the user is really doing so they can redesign it with technology—even if that redesign obviates the need for the activity altogether? Hidden in the real-life practice are human needs, pointers to potential delighters, the basic intents and organizational challenges that people face day-to-day. A shared understanding of the practice focuses design innovation discussions—and implicitly cautions the designer against breaking what works while improving the practice.

Any practice is more than a set of issues. Any practice has structure—it hangs together to achieve an intent. A list of issues is a good start. But a user’s roles and responsibilities; their collaboration within their workgroup; the process they work within; the values they share or conflict over; the physical environment they organize—none of this is revealed by issues and discrete task descriptions. Any practice bigger than a single function is complex and must be understood from several points of view.

To solve this problem—and to create a tangible artifact to represent the team’s shared understanding of the existing practice—in Contextual Design we capture work models.

The sequence model is equivalent to a task analysis. It shows each step required to perform a task in sequential order. A sequence model represents the activities of someone who will use the system. The sequence model also shows the breakdowns in the practice (as do all the models). The consolidated sequence models become the basis for redesigning the steps of the activities.
The flow model depicts people’s responsibilities and the communication and coordination required to support the work. The flow model reveals the actual human process used by a workgroup or individuals within an organization irrespective of time or order. When consolidated, the flow model is the key model for finding the core workgroups to support and for redesigning processes—both formal and informal.
The cultural model reveals the influences on a person, a group, or an organization, whether external to the company (such as law and regulations) or internal company policies (standards). It reveals the cultural milieu in which the product will have to succeed. When consolidated the cultural model is the key model for identifying the value proposition for the system and revealing influences on buying behavior.
The physical model shows the physical layout of the work or home environment and the constraints it imposes on the design. The physical model captures the footsteps between places, the role of distance, and the use of space. It shows the way people physically structure their work environment and work space. The physical model captures the structure and flow of work as it is manifest in space. When consolidated, the physical model can reveal both how to redesign work within the space and also how to support work online that was previously manual.
The artifact model shows how artifacts are structured and used during the performance of tasks. The artifact model is key when a team is trying to take a paper artifact, like a medical record, and put it online. Analysis of existing artifacts identifies their intent, usage, structure, and information. Artifact models merge with physical models for designs for automobiles or technologies in the home.

Work models are diagrams that represent the structure of human activities. Individual work models are captured by team members during each interpretation session: relevant data is recorded in each diagram as it is revealed during the retelling of the interview story. Contextual Design uses five work models in addition to capturing key issues. Each model represents a different aspect of practice. Taken together they reveal both the data and how the user activities hang together to get the work of life accomplished.

Diagrams are a normal part of a developer’s world. Whether it is a data model, an object model, a process diagram, or any of a thousand other modeling techniques, developers have been using drawings to show different aspects of a system since programming became a separate discipline. Making the abstract tangible is a natural part of everyday team design. If you watch teams at work you will see, as Lucy Suchman did in her classic work, that team work is supported by artifacts—people hang over them and focus their talk by looking at them and updating them and pointing at them. (Suchman, L., Plans and Situated Actions, Cambridge University Press, Cambridge, 1989.) Collaboration is always focused by and on the artifacts that represent what the team is trying to do.

So since we wanted to make the aspects of user work real, we needed something real to represent it. Data models represent data—they don’t represent human behavior and experience. Other modeling formalisms represented other aspects of system development. None revealed user practice explicitly. Since we wanted to foster a shared understanding and a shared conversation about the behavior of people we needed an artifact to represent user practice directly. That is what work models are: a way to capture the data that reveals the structure of practice, and something tangible that can be used to focus a design conversation.

The work models along with personas and the affinity diagram, a hierarchical chart that shows the core issues across a market or population, focus the team on a shared set of artifacts representing the team’s tangible representation of what the people they are designing for do. And because the data is tangible—the data is also reusable—the team can come back to it again and again during the design process.

More than 20 years after we first developed them, we still use these five “faces of work” to characterize the practice. We pick the models relevant to a project; no one has time any more to do them all. Each model brings its own point of view into focus and challenges the team to think from that point of view. Each work model, just by using a diagram to communicate, helps the team become aware of the structure of that part of the practice. Work models help the team’s conversation get real because the user data is made real in the diagrams. And this saves time.

Immersion in structured user data focuses the solution

To have a shared understanding of the user needs and the direction for a design solution, the team needs to move beyond the experience of any single user. An interpretation session makes the life of one user real and captures that user’s data. But to foster a team conversation about a market or user population we need to make the market real and tangible too.

Consolidation of the work models and issues brings data from individual customer interviews together so the team can see common pattern and structure without losing individual variation. Consolidated work models bring together each different type of work model separately, revealing common strategies and intents while retaining and organizing individual differences. Consolidated work models help the team step out of the details of an individual case to see the larger pattern of user activities as revealed across cases and people.

Consolidation results in one diagram for each type of model. Taken together, the consolidated models represent the practice of the whole market that is studied. Because consolidated models organize work practice into coherent and meaningful chunks, the team is able to see, capture, and think about very complex and rich information.

Imagine a room. On one wall is the affinity diagram, with all the users’ issues laid out in an organized way. On another wall is a flow model showing all the roles and relationships, and collaboration relevant to your project. On another wall are a set of key tasks in the consolidated sequence model. On another wall the cultural, physical, and artifact tell their story. And finally personas are hanging flip-chart sized on the last wall. This is your world of the customer—this is your data—externalized and available for the team to walk and discuss, ready to stimulate design ideas and design conversation. And yes—it is also available on-line to use and reuse throughout your project.

The most important resources on a team are the team members. Their perspectives will focus your design solutions. Their conversations will focus the definition of the problem and the direction of the solution. By providing the team structured data to immerse themselves in and a team process to interact with it they will naturally come to a shared solution.

One favorite story comes from a large multi-national company. Five different groups in the company needed to work together to produce a new product line. The design team who used contextual design took their affinity and consolidated work models from group to group gathering stakeholders in each to walk the data and generate solution ideas. As you might guess, the insights from the data and the solutions generated did not differ much from department to department. After all, it was the same company and all departments were in the same general business—and the data was the data. The groups were able to align their direction and get a winning solution out the door, just through structured data immersion and discussion.

Structured customer data allows for immersion and discussion time and time again—whenever needed. And immersion in structured data gives teams the reflection and discussion time they need when forming ideas for solutions. Structured data focuses these discussions on the customer because the customer data is right there in their face, on the wall and on-line. And we find that teams do indeed return to it over and over.

Immersion in the world of the customer during field interviews makes the customer real to the designers who will create solutions for them. Interpreting as a team shares this story and allows for first reflection and insight. But immersion in the whole of the users’ universe—as represented by the consolidated data—forces that big picture view that can drive a more complete solution.

If a team starts from the same data they are more likely to generate a shared understanding of the challenges and solutions—and that saves time and arguments.

All of business is the business of people working together

Any product development process or methodology must deal with the reality of people working together. If the people who have to work together don’t have a shared understanding of the problem, they will not generate a coherent solution. Without a shared understanding it is hard for a team to ship on time:

How many times have you found yourself arguing about requirements two weeks before you are supposed to ship? How many times have you pushed out your ship date because you are still arguing about what is necessary to build? How much time have you spent in meetings trying to come up with the real problems and solutions? How many methodologies have you tried on the way to getting your organization to get to a shared understanding? How many products have you shipped that the users didn’t like because you didn’t have an accurate understanding of their problems? How much frustration are you living with?

Hidden within Contextual Design are many kinds of structured design meetings meant to help teams work together effectively. But creating a shared understanding starts with a cross-functional team going out into the field to gather and interpret the data as a team. With consolidated work models and a process for team immersion in the data a team will develop a shared solution.

Sprinkle in additional stakeholders as ride-alongs on the field visits. Let others, who will be involved in creating the solution, participate occasionally in interpretation session. Invite extras who will have an opinion to help build the affinity. Bring them all to data immersion events.

Tangible customer data is the most powerful way to align your team. If you are honest about the time you really spend reaching agreement—you’ll find that Contextual Design can reduce team contentiousness, produce a better result, and speed your time to market.