A problem that crosses departments arrives as a pile of complaints that don't agree. Sales says production is late, production says orders change, billing says nobody tells them. An affinity diagram groups everything into themes so you can see the shape of the problem before choosing what to investigate.
Where it comes from
The affinity diagram is also called the KJ method, after the Japanese anthropologist Jiro Kawakita, who developed it in the 1960s to organize field notes. It's one of the seven management and planning tools.
How a bot helps
Give a bot the interview notes, emails and tickets from every department. It writes each observation as one short card, tagged with its source, and proposes groups. The tagging is the important part: when one theme comes only from one department, that's worth knowing.
Then people rearrange the groups. The bot's first grouping is a draft. The people who know the work will merge, split and rename groups, and that discussion is half the value.
An affinity diagram isn't a diagnosis
A big group means many people said it, not that it's true. "Orders change after entry" might come up twenty times and turn out to be rare in the records. Each theme becomes a question to test with data: a check sheet, a reconciliation or a walkthrough.
On the bots' own work
Run it on a month of feedback to a bot team: every correction, complaint and "that's not what I asked". Themes like "uses stale files" or "too long" point to the skill to fix.
When to use it
At the start of a cross-department investigation, after interviews, or with a large pile of feedback. Light.
Where bots differ
A bot will produce neat themes with confident names, and it can merge two different complaints because they use similar words. Keep every card's source and wording, so people can check what went into each group.
Sources: Affinity diagram (KJ method).
Back to Engineering tools for bots.
Short outline
Affinity diagram: short outline
What it's for
An affinity diagram turns many observations from several sources into themes, keeping each card's source and wording. The themes are questions to test with data, not conclusions.
Columns
| Column | What goes in it |
|---|---|
| Card | One observation, in close to the original words |
| Source | Who said it or where it came from, and the department |
| Date | When it was said or recorded |
| Group | The theme it sits in |
| Theme name | A short statement of what the group says |
| Sources in the theme | How many departments contributed |
| Test | How the theme will be checked against data |
| Owner | Who runs the test |
Steps, each with its "done when"
- Collect the observations. Done when every source is gathered and listed, and each department that touches the problem has contributed.
- Write one card per observation. Done when each card holds one observation in close to the original words, with its source.
- Draft the groups. Done when every card sits in one group, and cards that fit nowhere stay in a "loose" group.
- People rearrange and name the themes. Done when the people who know the work have reviewed the groups, and each theme has a name in a sentence.
- Turn each theme into a test. Done when every theme has a check against data and an owner.
Common mistakes
- Treating a big group as proof.
- Rewording cards until the source's meaning is lost.
- Accepting the bot's grouping without people rearranging it.
- Themes that come from only one department, unnoticed.