Building an Affinity is inductive reasoning at its purest. The basic process is to put up one note, then for everyone to look at the notes in their hand for others that seem to go with it. When found, additional notes are added to the group. There’s no need to justify why they go together. But we do push for a certain kind of “affinity”: Two notes have an affinity if they are saying similar things about the user’s life as it relates to the design focus of the team—the notes express a similar intent, problem, or issue. So deciding if notes go together is the result of an inquiry into the meaning of the words on the note to understand the practice issue they represent. When it’s not clear how to interpret the words, the team can appeal to the interviewer to check whether an interpretation is valid.

Here are some examples of using the data captured on a note to infer meaning for the practice. Each example gives some of the context (which the team would be aware of) and shows how to look at the data from a particular focus and see implications for redesigning the practice and technology. If these insights occurred to team members during the Interpretation Session, they would be captured in separate notes; otherwise the Affinity process gives the opportunity to consider the data again. These notes are all taken from interviews with people planning vacations.

This note discusses a particular feature of a travel site’s UI (Orbitz), but it’s hiding an implication about travel planning. When thinking about her vacation, the user isn’t committed to a particular departure and return date. Those might change depending on the trip, the price, and other factors. And in fact, many decisions in vacation planning are tentative, dependent on other aspects of the vacation working out. Any tool we build needs to take this flexible, uncommitted attitude toward planning into account.

This note suggests values and experiences associated with identity—the mother’s attitude and by implication the traveler’s own. The notes in an Affinity relevant to values and how we see ourselves will group together to reveal themes. This section of the wall will both reveal these values and will also be relevant data to create identity elements, described in Chapter 7. Here it suggests that being adventurous is valued by both mother and daughter—and it reveals that the mother would like to encourage the daughter to do what she could not. As the team looks for the meaning and key ideas in the notes, they can group like notes together. The meaning a team reads in a note and the way they group them are driven by the project focus. The above notes could be taken in different directions—features in cars, finding restaurants, providing search functionality. But put together, they point toward one of the Cool Concepts (in fact, they are where the concept came from). Together, they suggest “Think for me”—give me what I’m looking for without asking me, without search, and without setup. Grouping them this way across domains reveals the higher-level principle.

Now we collect notes with similar themes together and give them a label representing the insight suggested by the group. A good group label states the issue that holds all the individual notes together. It is a succinct phrase that summarizes the content of the group. “Different ways of finding nearby things” would not summarize the content in the above example; it would just say what you could learn by reading the content. Including “without having to ask” states the key principle; the individual notes give examples of this general statement. The data in the individual notes below the label supports the statement in the label. If the label is good, it reveals the distinction important for design. The label is the synthesis of the detailed data—now there is no need to read the notes. The label is sufficient. So a good label matters.

A good group label is written as though the user was talking to the designer; direct, immediate language has more impact than third-person language. The label is not a sentence; it is succinct declarative personal message from the user. When the labels use the user’s voice, the whole wall speaks directly to the design team—the labels are a central communication device. Here are some examples of good first-level labels, all revealing how travel planning supports relationship between people:

First-level groupings such as the above are themselves collected into higher-order groups. The result is a hierarchical structure that breaks the data about the user into manageable chunks. We use green sticky notes at the highest level, which describe a whole area of concern. Under this, pink labels describe the specific issues which define that area of concern. Blue labels describe each aspect of the issue. And the individual notes under the blue labels describe the instances illustrating the blue label. When well written, the labels tell a story about the user, structuring the problem, identifying specific issues, and organizing everything known about that issue. The labels represent the new information in an Affinity. All labels are written in the voice of the user.

We limit each first-level group to four to six notes to force the team to look deeply and make more distinctions than they would otherwise be inclined to. It pushes more of the knowledge up into the group labels. Remember your findings are in the labels—they are what will drive design thinking. A pink label can contain up to eight blue labels, and a green label might have six to eight pink labels. Bigger groups than that mean there’s not enough structure to see what’s going on quickly.

When complete, each green section tells a story about the users’ life. It raises the distinctions relevant for the project focus, revealing what matters. In this way, the labels synthesize the findings and drive design thinking. For example, here is a section of an Affinity describing how travel supports the Cool Concept of

This section of the Affinity brings together data from many users and many situations to tell the story of travel and the experience of challenge. When sharing the data or reviewing the wall yourself, you might read it like a story: “People see travel as a challenge, and that’s a good thing. It gives them a sense of accomplishing personal goals, furthering their interests, and growing as a person. And overcoming the challenges of travel is fun and meaningful in itself. I’m proud of what I did and want to share it with my world.” Each pink label names an issue which is described by the blue labels underneath it, so that each section of the Affinity tells a coherent story about part of the practice, and the whole wall brings together all issues and observations to tell a single story about the user population.

Labels in the Affinity bubble up from the data. Together they tell the story of the practice and life of people in the market. The data, as always, represents detailed information about the target activity. But with the introduction of the Cool Concepts, the data now also represents detailed data about the life, use of mobile devices, identity, and motives of people. And the Cool Concepts also focus the team in

So to be sure that the team pulls together the data needed for the Contextual Design Experience Models and ideation techniques, we need to raise up issues of design for life. To do this, before building the Affinity, we suggest the team start with a set of preliminary green labels related to Cool Concepts. These are placeholders which can be changed later by looking at the data grouped into that section. All of the green labels talking about the target task bubble up naturally. We do not recommend predefining green labels for the primary task—that won’t help the team break their preliminary assumptions. But by using initial labels associated with the Cool Concepts, we help the team recognize this important data and bring it together. Below are the green labels we suggest to ensure a design for life focus.

These placeholder labels allow the related data to find their way together more easily. A team might not have all Cool Concepts in their project focus; if so, they will only use the preliminary green labels that are relevant for them.

Affinity building reveals the core process of consolidation: look at individual observations and group like data from different users. Bubble up key distinctions relevant for design. Label the distinctions at multiple levels of abstraction—in the Affinity, the blue labels reveal detailed distinctions, and the pinks show key aspects of one overall theme or story area represented by the green label. Let the groupings emerge through inductive reasoning to reveal new themes, aspects, and distinctions. Present the whole in a structure that’s easy to understand and walk. For the Affinity, this structure is a simple hierarchy.

You can read a good Affinity from beginning to end to see every issue in the practice and everything the team has learned so far, all tied to real instances. There’s no better way to see the broad scope of the problem quickly. And it’s also the first example of the process of consolidation.

For any group process, people need to know the rules of engagement; they benefit from a clear structure to guide getting the collaborative work done. We saw how Contextual Design provides such a structure for the Interpretation Session; we also provide a clear structure for the Affinity and other team tasks as well. Here are the basic steps to building the Affinity.⁴

During Affinity building we encourage quiet, one-on-one discussion between team members. This process is an opportunity to explore the data together and bounce ideas for labels off each other. Working in

There is no need for consensus before creating or changing a label or grouping. But if a pair gets stuck on their part of the wall, they can ask others to come in to help. Never stop and have a whole-team discussion on any part of the wall! Let two or three people make a quick decision and move on. Working in parallel, the wall will naturally shift to better reflect the themes that matter for your project. Green label sections become separate areas of work; move people around the sections so multiple minds consider each part. Ownership of a part is a problem, not a goal.

Doing the work in pairs helps move people from thinking in buckets (all notes with the term “hotel” on them get tossed in one group) to thinking about the practice. Moving from section to section to stay fresh lets people review each other’s notes and labels for clarity, rightness for that group, and to see that a story is being created. When people can’t agree on where a note should go, they talk about what underlying issues they see. When people don’t understand a note, they go back to the list of notes from that Interpretation Session or to the interviewer to ask what happened in the interview. If a note seems to have two points, cut it in half or write a second note. Remember the Affinity will never be “perfect.” Perfection is not a goal; structuring the data so it is useful to drive design thinking is. Everyone should be able to look at the resulting wall and see how it addresses the project focus and any business issues.

To help manage the team we put strict boundaries on disagreement, just as we did in the Interpretation Session. Team members may draw different meanings from the same note. A note might fit into an existing blue group or might be used to create a new one. In that case, create a new group and a new distinction. More insight is better. Rarely do you need the note in both places; if you already have two good notes in a group you don’t need a third—use it elsewhere to push new insight. A note might fit into several existing groups—in that case, just pick the weakest grouping and beef it up by adding the note to it. If a team member has an insight from the Interpretation Sessions but doesn’t have the notes to support it, it’s up to them to find the supporting data first (the notes may have been buried in other categories) and then write the label to support it. But most of all, remember that no one note is critical.

Building the Affinity in a few days creates a team event that binds the team together and is also important for creating new insight. Building smaller Affinities more quickly or building up one Affinity over time lets team members incorporate each piece of data into an already existing structure of understanding before having to deal with the next; this leads to assimilation of each point instead of promoting a paradigm shift. With the above process, in a single day the team has to face a whole new way of looking at the users’ world.

Building a 1500-note Affinity is exhausting, so knowing how to handle disagreements and individual differences is key. It’s an entire day of reading and conceptualizing hundreds of separate bits of data and matching them with other bits of data. It’s like a combination of Concentration, the memory game, and translating Shakespeare into Latin: the words on a note have to be interpreted to translate them into the underlying practice issue; then the note has to be matched with the note you saw 5 minutes ago and you know is on the wall somewhere. Everyone’s working at once, moving back and forth along the wall, discussing notes with each other, and yelling general questions to the group at large (“Who interviewed U4?”).⁵

Some people will be overwhelmed when the first notes are going up with no labels, and others will love it. But the people who hate it find that their overwhelm evaporates when they have one piece of the wall to label. Now the task is bounded, and they can focus on putting in structure. Some people will be great labelers and others will be able to find groups but won’t write good labels. Working as a group means the team can lean on the strengths and work around the weaknesses of individuals. No process will feel comfortable to everyone all the time. But if people know what to expect and what to do, we find they can deal with it.

When the team is done, they have a single structure representing all their user data, which organizes their knowledge and insight and gives them a basis for design. And when they see it finished—then everyone gets excited!

Once the Affinity is built, structured, and labeled, it is time to ensure it is really ready to be used in an ideation session. Because teams always love the Affinity, it is our gold standard for learning what really works for communication design. So let’s look at its attributes. Just as the Affinity teaches the inductive thinking process needed for any consolidation, it illustrates principles of good communication design.

Meaningful structure: A meaningful structure is one that can be used, understood, and consumed quickly by anyone walking up to the model. A hierarchy such as the Affinity presents is the most familiar structure for information across all professions. How you organize that hierarchy is critical for success. The Affinity structure contains the overall story of the practice and life of the target population. Read top-down, it presents the story in sections, or chapters, denoted by the green labels. So the Affinity presents the key issues of the market in digestible chunks. A person can read through one green label grouping and only focus on what that group is trying to say. This helps focus design thinking and generates targeted design ideas. The green label says “Look here, think about this—now what will you invent to deal with my issues?”

Each green is composed of chunks too—the pink groups—and so on. Each chunk is a call for design thinking. When information is chunked well within an overall framework (like the Affinity hierarchy), people know how to approach complex data without overwhelm. The green labels lead the reader through the data, creating natural stopping points such as “chapters” in a story. It invites but circumscribes the design problem to something manageable. Any good communication design must have a recognizable structure that chunks information while it moves a reader systematically and naturally through the full story represented in the whole model.

So what makes a good Affinity? We provide metrics on size so that the chunks don’t get too big. We put the greens in a sensible order so people can move through them without disrupting their understanding of the big picture. To use it, anyone can start anywhere—but no matter where they start, the flow from panel to panel will end up telling the whole story.

The labels, and language of the labels, are critical too. If they are too long, people have to stop to parse them, disrupting their flow. If they are too categorical, they force the reader into the notes, again disrupting the flow. If there are just too many words on a label, they can’t be easily and quickly scanned. To simultaneously get the big picture and the detail, the data must be read like a novel, moving through it quickly so that the mind can be free to generate ideas while reading. Anything in the way of fluid movement through the data gets in the way of design thinking.

The last step in creating the Affinity is to check that the size and order of groupings are correct, that the most important themes are revealed, and that the labels are short, succinct, and invite immediate understanding.

Story language: People are wired to tell and consume stories. We write our stories on steles, on cave walls, in novels, in newspapers. We share stories as examples of larger principles. Although we can abstract, we naturally know how to consume content in the form of a story. And when we see an abstract concept, we naturally generate stories (or examples which are themselves stories) to tell ourselves what the abstraction means. So if we want people to internalize the data easily, we’d better use story language.

A framework for understanding provides a set of abstract concepts which organize understanding. But without story examples—real-life examples of how that concept plays out in life—abstract concepts alone will not drive design thinking. Or worse—the concept, without story, invites us to make up stories to fill in the blank. This drives designers to lean on their own life experience, not the market data. The most powerful way to drive data into the mind of designers is to find the organizing concepts through inductive reasoning and then illustrate them—tell their tale in story form.

The labels in the Affinity simultaneously organize and name the core concepts and tell their story. They are constructed in first-person language expressing the users’ experience. Because they are deliberately short, declarative, and succinct, they are easily consumed. In this way the designers learn the core concepts through story language in the voice of the market. And it’s all tied to the actual data, available to flesh out the concept.

The story language used in the Affinity Diagram invites design thinking and drives designers away from design from the “I.” It provides a way for readers to quickly immerse themselves in the life of the users just by “walking the wall” as we will discuss in Part 3.

A Way In: A wall-size graphic of complex data can be overwhelming. Since our goal is to invite the readers to engage with the data, we need to build a “way in” right into the structure of the graphic. Every consolidated model must guide the reader through the data by its structure and layout. Every consolidated model provides a big picture of one aspect of the users’ lives. But we cannot swallow it whole—we must move through it linearly, or at least one piece at a time.

The Affinity Diagram provides a natural Way In through its groupings. Every green label defines a coherent part to be dealt with. The hierarchical structure tells people that blue labels define pink labels and pink labels define green labels. The flow from one green to the next guides movement through the model—and lets those who are looking for one favorite part to find it at the green level. The way in is clear.

The Way In is not defined by structure alone. The story language also invites inquiry and pulls the reader through the story. The Affinity hierarchy—well designed and labeled—is a great way to represent discrete observations in an accessible way. But other models show other views of the practice. The structure of a practice is not best represented in a hierarchy. In the next chapters we will talk about each model’s structure and how to create a Way In for them.

Interaction: Even the best designed graphical representation of data doesn’t communicate by itself. If passed around as a big document, readers might glance over it or think it looks cool—but will they really engage with the data? Will they use it? Will it drive design thinking? To be sure that the data get into the design, you must push designers to interact with the data—to think about it, manipulate it, dialog with it, and respond to it. So support for this interaction must be built into the communication design of any model.

The Wall Walk described in Part 3 is the step where we ask people to engage with the data by giving them an activity to do while they move through the model. Reading alone does not ensure they are using the data for design. We must create a link between the data and design to be sure that it gets in to the mind of designers.

If designers are asked to write design ideas in response to the labels in the Affinity, they naturally start designing from data. If we tell them that a more systemic, better, idea is one that responds to a pink or green label, addressing a whole theme, they naturally move away from one-off ideas responding to individual notes. And it doesn’t hurt if it creates a little competition to get the most, and most systemic, notes up.

People need something to do besides read when they engage with data. We build engagement into the process and into the structure of the model for all the consolidated models, as we describe below. But there are lots of ways to create interactive activities that drive designers into the data.

Communication design is at the core of bridging the gap between data and design thinking. So create a meaningful structure, use story language, define an obvious way in and a process for interaction. Once you have done that you are ready for ideation.

The Affinity Diagram is a fabulous teaching tool for your team. It teaches induction, how to structure information, how to raise up distinctions, and how to manage complex information. And when done well, it is an excellent communication design. Now we turn to the other models to learn how to build them and how they also can drive design thinking.