From sticky notes to structure: turning brainstorms into diagrams

Most brainstorms end the same way. The wall is covered in sticky notes, everyone agrees it was a productive session, somebody takes a photograph, and the photograph is never opened again. The ideas were real. The structure that would have made them usable never got built.

Getting from a pile of notes to something a team can act on is a separate piece of work from generating the notes, and it has its own steps: clean the notes, cluster them, name the clusters, find how the clusters relate, and then choose a diagram that fits what you found. This article walks through each step and then follows one real-world brainstorm from mess to finished diagram.

Diverge first, converge second

A brainstorm has two phases that want opposite behaviour. In the divergent phase you want quantity: every idea on a note, no judgement, no discussion of whether it is right. In the convergent phase you want the reverse: grouping, choosing, discarding and committing.

Sessions go wrong when the two are mixed. Someone writes a note, someone else says "we tried that", and the room quietly stops writing anything risky. Or the group tries to organise as it goes, and the first three notes set categories that every later note gets squeezed into.

• Diverging: one idea per note, written large enough to read from two metres, no comments on anyone else's notes, a fixed time limit.
• Converging: start only when the writing has stopped, work with the notes on the wall rather than from memory, and expect to argue about meaning.
• Between them: a short break. It is a useful signal that the rules have changed.

Prompts like these are useful when a group stalls. They are not categories for clustering later, and it is worth keeping them out of the convergent phase so that the real themes can emerge.

Clean the notes before you group them

Ten minutes spent tidying the raw notes makes clustering much faster. Read every note aloud, one at a time, and apply three rules.

1. One idea per note. "Slow sign-off and unclear briefs" becomes two notes.
2. Rewrite anything vague. "Comms" means nothing next week. Ask the author what they meant and write that: "Client hears about delays from us too late".
3. Stack duplicates rather than removing them. Three notes saying the same thing is information: it is a point several people raised independently.

Cleaning also quietly fixes a fairness problem. Notes written in a hurry by quieter participants are often the terse ones, and a terse note tends to get ignored during clustering. Reading every note aloud and asking its author what they meant puts each idea on equal footing before any grouping starts.

Clustering by affinity

Affinity grouping means moving notes that seem to belong together into the same area of the wall, without deciding the categories first. The categories come out of the notes. This bottom-up direction is the whole point, because predefined categories tend to reproduce the team's existing assumptions.

• Start with any note. Put the next note near it if it feels related, or somewhere else if not.
• Do the first pass quickly and, if possible, in silence. Debating each placement turns clustering into a meeting.
• Let people move each other's notes. If a note moves back and forth, take it out and discuss it later; it probably means two things.
• Keep an orphans area. Notes that fit nowhere are not failures; occasionally one of them turns out to be the most important idea in the room.
• Watch cluster size. One enormous group usually contains two or three themes. Split it before naming anything.

Naming the clusters

A cluster without a name is just a pile. The name is where the group decides what the notes in it are actually saying, and it is worth more care than it usually gets.

The common mistake is to name clusters with a topic: "Website", "Communication", "Process". Topic names are true of every note in the group and say nothing about any of them. Name the cluster with a statement instead, ideally one someone could disagree with.

A useful test: read the name, then read three notes from the cluster. Each note should sound like evidence for the name. If one does not, it is in the wrong cluster or the name is wrong.

Finding relationships between clusters

Named clusters are a decent output on their own. But the decision about which diagram to draw depends on how the clusters relate to each other, and that is the question most sessions never ask. Lay the cluster names out on a clean area and look for five kinds of relationship.

Two questions help when the relationships are not obvious. For any pair of clusters, ask: if we fixed this one, would that one get better? A yes suggests cause, and a concept map or a process map. Then ask: does this one have to happen before that one? A yes suggests sequence. If the answer to both is no for most pairs, the clusters are probably parallel themes under a shared heading, and a mind map will hold them well.

Often more than one relationship is present. Pick the one that matters most for what the group needs to do next. If the next step is fixing a broken process, draw the sequence. If it is deciding what to work on first, draw the roadmap. You can draw the other later.

If you cannot find any relationship between the clusters, they may be genuinely independent. In that case a ranked list of named clusters is the right output, and drawing a diagram would add structure that is not there.

A worked example: why do our projects overrun?

A twenty-person design agency runs a forty-minute session with eight people from client services and delivery. The prompt is "Why do our projects overrun?". Fifteen minutes of writing produces about sixty notes. Here is a representative sample, as written.

• brief changes after kickoff
• too many reviewers on client side
• estimates are optimistic
• nobody owns the timeline
• client sign-off slow
• we start before contract
• comms
• staging site access takes days
• feedback from people not in kickoff
• design rounds unlimited
• dev starts before design final
• Friday handoffs
• we don't say no

Cleaning takes ten minutes. "Comms" turns out to mean that clients only learn about delays at the weekly call, so it is rewritten. "Client sign-off slow" appears five times and is stacked. "We don't say no" is split into "we accept scope changes without re-estimating" and "we agree to deadlines in the pitch".

Silent clustering produces six groups and three orphans. One group is too large: it holds everything about the client's side and splits naturally into "who gives feedback" and "how long sign-off takes". After discussion the clusters are named as statements:

1. We agree deadlines before we know the scope
2. Work starts before the contract and access are in place
3. Success criteria are never written down, so the brief keeps moving
4. Feedback comes from people who were not at kickoff
5. Sign-off has no deadline and no named approver
6. We absorb scope changes instead of re-estimating

Now the relationships. Laid out in a row, it is obvious that the first three clusters all describe the period between contract and kickoff, and that the last three are consequences of what was or was not settled in that period. Undefined success criteria lead to moving briefs; an unclear list of stakeholders leads to feedback from strangers. There is a sequence, and a cause running along it.

So the group draws a process map of how a client project should start, with each problem cluster attached to the step that would prevent it. Three of the six clusters land on steps the agency currently skips.

The orphans are worth a last look. "Friday handoffs" turned out not to belong to the overrun question at all; it was a separate complaint about working patterns and went on a list for another conversation. That is a normal result. Not every note survives into the structure.

Finally, the fixes. Writing down success criteria, naming an approver and setting a sign-off deadline are three changes of different sizes. The group puts them on a simple Now, Next and Later roadmap so it is clear which one starts on Monday.

Notice that the session produced two diagrams, not one, and neither is a picture of the sticky notes. The process map answers "where does it go wrong?" and the roadmap answers "what do we do about it, in what order?". Both are small enough to read in a minute. The sixty original notes survive only as the photograph, which is exactly where they belong once their content has been absorbed into the structure.

Common mistakes

• Clustering while ideas are still being written. The first groups set the categories and later notes get forced into them.
• Starting with categories. If someone writes "People, Process, Tools" on the wall before clustering, the session will rediscover those three words.
• Topic names for clusters. A cluster called "Communication" cannot be acted on. A cluster called "Clients hear about delays too late" can.
• Drawing the diagram type the team always uses. A team that lives in roadmaps will draw a roadmap of a broken process. Choose from the relationships, not from habit.
• Keeping every note. The diagram should contain the clusters and the relationships, not sixty sticky notes in boxes. Individual notes can go in an appendix or a photograph.
• No owner for the output. Someone should leave the room responsible for drawing the clean diagram, ideally the same day.

Doing this in DiagramDock

The sticky-note stage works best on a wall or a table, with paper. DiagramDock is for what comes after. A mind map is the quickest way to type up named clusters with their notes underneath (Tab for a child, Enter for a sibling), and it is often worth doing even if the final output is a different type, because it gives you a tidy record of the session. From there, the process map, concept map, roadmap and timeline types each have their own palette, and frames let you group areas of a larger diagram and step through them as slides in presentation mode when you take the result back to the team. Everything is stored locally in the browser, which suits a session full of frank notes about clients.