Design Method: Affinity Diagramming

UW > iSchool > Informatics > INFO-440 > Affinity Diagrams
- - - - -

Affinity Diagrams

2 October 2002

Affinity diagramming is a very simple method for organizing a complex body of information. Here is the basic process:

Divide your material up into ideas. Write the ideas on strips of paper, PostIt notes, or index cards.
Working in a team, assign the ideas to groups. Invent labels that stand for the contents of the group. The labels should refer to general concepts.
If a group contains more than 4 or 5 ideas, you should break the group up into two smaller groups.
Continue working with the material until all of the ideas have been grouped. Normally, you should not have a 'miscellaneous' category.

Background

For background reading, turn to the section on affinity diagrams in Contextual Design by H. Beyer and K. Holtzblatt (pp. 154-163). You may also want to seek out examples from the Web, including

Dey Alexander: Affinity Diagrams. Retrieved September 25, from http://deyalexander.com/resources/affinitydiagrams.html
Decision Process Guidebook: Affinity Diagrams. Retrieved September 25, from http://www.usbr.gov/Decision-Process/toolbox/affinity.htm.

Theory

Affinity diagramming provides a method for inductively generating categories from large body of information. More to be added...

Example

As an instructor, I wanted to get to know my students and what they wanted to learn. At the same time, I wanted to show students that affinity diagramming, while quite simple, can be a very effective method for understanding a body of material.

At the first class, we carried out a greetings exercise. I asked students to list three things they wanted to learn in class and name their favorite information system. Then, students took turns talking about what was important to them about information system design.

After class, I took these index cards away. The challenge was to organize this information and to develop an understanding of the common themes.

Below is the process I followed. To follow along, click on the images on the left.

How could I organize the data on these thirty index cards?

My first step was to rip the index cards into smaller strips. Each strip had a single concept on it. Some example concepts:

I want to learn good technologies for designing information systems;
I want to learn about different design methods;
I want to learn about the process of designing;
I want to learn techniques for building a system that meets as many human needs as possible;
I want to learn about Jakob Nielsen.

As I began to do this, I grouped the strips into piles. And, I labeled two of the piles, "Process" and "Methods".

Notice that I used different colored paper to identify the category headings. I wanted to make sure that my concepts were clearly different than the students' ideas. Thus, I used green labels

As I continued to do this, more groups emerged. I labeled these groups as well. Notice that at this stage many strips do not belong to any groups.

Here is a close up of four categories. You can see that some of the strips have yellow highlighter. I used the highlighter to show what appeared to me to be important terms or phrases. For whatever reason I worked from left to right on the whiteboard.

As I continued to study the strips, more and more strips did not fit into the existing categories. I didn't worry about that too much. I knew that as I became more familiar with the material, new category labels would come to mind.

Notice the ruler in this picture. I used the ruler to rip the index cards into strips.

I decided that I needed to break some of the original categories into subcategories. I did this because I did not want too many strips to be in any one category. And, I felt that subcategories helped to explain the data effectively. I didn't have to use subcategories but they just seemed to be appropriate. I used yellow paper to indicate these subcategories.

I decided, for example, to divide the 'usability' bucket into three subcategories: 'Theory', 'Practice', and 'Inspection Methods'. These subcategories seemed to best capture the ideas on the index cards.

This picture shows the final result: All the cards are ripped and organized, and I've taped the strips to the whiteboard so that I can easily move it around. I did this work alone in about 2hr.

Doing this individually is a very significant weakness because I brought tacit, unvoiced and un-discussed, biases to the categorization process. When a colleague, David McDonald, walked by this became obvious.

David asked "Why is this strip in the category 'Oddities'?" The strip read "I want to learn about Jakob Nielsen?" Other strips in this category included:

I want to learn what David H. thinks is important enough to teach;
I want to balance myself using only my thumb and forefinger.

I explained that I put the strip in that category because I could not see how an idea about Jacob Nielsen was relevant to the course. After all, we were using his textbook! (By the way, I didn't throw the strips aside because I have learned: Never, throw data away -- you never know when it will be useful.)

David, however, immediately pointed out that it was an important idea and suggested the category "People &History of design". Once I heard David say this, it registered immediately. I wondered why I didn't invent this category on my own and decided that the main reason was that I am very familiar with Nielsen's writings.

I fell into the trop of approaching the data from my point of view rather than the students' point of view. After fifteen years of experience in interactive system design, I still catch myself "designing for myself rather than the audience".

The lesson: Whenever possible carry out affinity diagramming in a cross-functional group. Multiple perspectives are crucial.

Follow-up

Below are the categories that came out of the affinity diagram. I learned that students were interested, particularly, in some areas. These are noted with an asterisk(*). Where possible, material will be added to the class sessions to cover these topics.

Applications
Applicability
Assessment
Communication
Guidelines
Human needs
Issues
Methods
	Effective
	Efficient
Process
	Practical
	Holistic
	Tricks*

Project management*
Prototyping*
	How-to
	Role in design
People & design history* 
Oddities
Outcomes
Requirements
Usability
	Theory
	Practice

You may use this material for educational purposes but please cite this source. To make comments, please contact David Hendry (dhendry@u.washington.edu).

Information School, University of Washington: Contact Information.