Dialogue Mapping

From Faster Than 20


Dialogue Mapping is an inclusive, visual facilitation process that creates a diagram or "map" using the IBIS grammar that captures and connects participants' comments as a meeting conversation unfolds. It is an outstanding tool for building shared understanding and shared language. It is especially effective with highly complex or wicked problems that are wrought with both social and technical complexity as well as a sometimes maddening inability to move forward in a meaningful and cost effective way.

Although you can use a whiteboard to do the mapping by hand, it is typically done with Compendium projected on a large shared display.

Here's an example: Dialogue Mapping examples

Jeff Conklin created this process and is the authority on its practice. More information is available from CogNexus Institute] and also from his book, Dialogue Mapping: Building Shared Understanding of Wicked Problems. Jeff also does regular workshops and trainings. To understand the philosophical underpinning of the technique, read Jeff's excellent post, "About that Chart: Embracing the Reality of How We Learn."

See Dialogue Mapping and Issue Mapping for a discussion of the symbiotic relationship with Issue Mapping.

Dialogue Mapping is closely related to, but not equivalent to the Compendium methodology. However, Compendium is the best tool for Dialogue Mapping right now.

Sample Maps




Learning to Dialogue Map

  1. First things first, learn IBIS. Dialogue Mapping is a visual representation of the IBIS grammer. You can use IBIS to map a conversation using simple post-it notes once you've mastered the grammer. When using IBIS to map a conversation, focus on pulling out the key questions, even when they are not framed as questions by the participants. This is one of the true values of IBIS.
    1. Jeff Conklin recommends the following progression for becoming fluent in the IBIS grammer
      1. Privately map out a problem you are working on personally (job? new car? move?)
      2. Have a 'meeting' with a friend about a problem you both care about and map out the conversation
      3. Watch a TV sitcom and map out the 'issues' in the plot
      4. Watch a TV news analysis show and map out the discussion of the issues (Hard!)
      5. Analyze a newspaper or magazine article
      6. Privately map the group dialogue when you attend meetings
  2. Once you're comfortable with the grammer of IBIS, you can download Compendium and start using the computer software to support your dialogue mapping.

Best Practices

It's all about the questions. Our goal with the framing of the questions is to be generative. For more on the grammer and how to structure the dialogue, see IBIS. On this note:

Avoid Yes or No Questions

Translate yes/no questions to non-yes/no questions, with the question itself being proposed as an idea.

For example, instead of, "Should we give clients access to admin tools?", rephrase it to, "What kind of access should we give clients?" That opens up the possibility of thinking outside the box.

Map Management

Arrange a list of nodes vertically as much as possible. This eases the creation and organization of the map.

When should you create a new idea versus using a node's detail? A good rule of thumb is, if people are going to talk about it, make it an idea.

It is easy to get too caught up with creating linkages between nodes. You can get too caught up with the formalism of the process. It's nice on one level when participants get stuck this way, because that means they are following closely enough to point these things out. However, it's important to make it clear that the purpose of dialog mapping is to capture enough linkages to paint an accurate picture, not to comprehensively link every related node.

Situations where this seems to commonly occur: linking arguments to ideas. It's not necessary to link an argument next to every idea it applies to, nor is it necessary to make every con a pro to the opposite idea. The map is to be considered in its totality by humans. As for making pros cons to opposite ideas and vice versa, not doing so does a better job of capturing the spirit of the discussion. A half-full glass is equivalent to a half-empty glass, but it's nice to capture whether the group was optimistic or pessimistic.

Worrying about making sure everything is connected results in two problems. First, the maps grow large and complicated, and are difficult to navigate. Second, it makes it difficult to determine where to put an item. If it's not obvious, create a new question or map, or leave the idea hanging by itself. If you have to ask yourself, "Where the heck would that fit in?", and you can't come up with the answer quickly, no worries — just put it by itself. You may find throughout the converation that its proper place becomes apparent, or you may find that its proper place develops around it due to its isolated existence.

Left-Hand Move

Take Breaks

Strategy / Culture Bicycle

Dialogue Mapping in disguise.

Random Notes

These are various notes Eugene has taken over the years. Needs heavy refactoring. Feel free to ask for clarification; that will force me to refactor.

Need better locality when editing! Different maps with transclusions a form of locality. However, want to also support locality via views, rather than partitionining into multiple maps.

An IBIS moment: Was brainstorming with Justin in front of the Dialogue Map, and he noted how hard it was to randomly brainstorm, because the questions on the screen forced him to focus his thinking in one direction. That's exactly why it's there!

Dialogue mapping is a good way of catching repetition on mailing list discussions. People tend to make the same argument multiple times, sometimes even in the same e-mail! Part of this may be because people don't read other people's e-mails carefully. When I caught this on the Web Services map, I compressed multiple points into one. For example, some of Paul Prescod's bullet points.

Shared space, in theory, prevents repetition from occurring. However, I've noticed while facilitating meetings that people will continue to repeat a point, even if it is clearly noted on the shared space and if it is brought to the attention to those people. In some circumstances, you want to emphasize that point, perhaps by putting it in its own map, because it is clearly an important point. In other circumstances, you want to direct the person's attention to the point, and move on. Some people just want to be heard very badly, and being recorded on the map isn't enough for them.

Sometimes, it's better to refactor than to transcribe. On xml-sig@python.org, Rich Salz claimed that "SOAP with attachments" was one of the good things about SOAP. A long thread challenging this claim ensued, resulting in Rich conceding people's complaints and clarifying his idea. Rather than attempt to capture that thread, I simply refactored the map. In a real-time meeting, it probably never would have come to refactoring. The point would have been clarified before it was put on the map. An example of participants refactoring the discussion is Rich's point about SOAP transporting arbitrary XML.

In some cases, you do want to capture the traceability. There was a whole thread about whether or not HTTP is RPC or not. In the process of laying out the arguments, the two parties -- Martin v. Loewis and Paul Prescod -- ultimately agreed that HTTP is an RPC application. I found this discourse important to capture because it was an example of ontological development over an e-mail discussion, which was important to future collaboration and hence, important to trace.

Sometimes, people's responses to questions are completely irrelevant or illogical. In a real-time session, you can facilitate this. In a mailing list discussion, it's difficult (and more prevalent). That's okay, though. Mapping the responses -- however illogical -- may highlight what the discourse may obscure, which may lead to the participants realizing the flaws in the responses. I've seen this on numerous occasions. For instance, mapping the OHS open source discussion, it became clear that Eric Armstrong equated "open source" with "no funding opportunities." That may in fact be a characteristic of many open source projects, but it is not a truism, and hence, the logic to his arguments were inherently flawed.

Mapping online discussions tends to be more tedious than mapping live meetings. Part of this is due to poorly integrated tools. However, there are two characteristics of asynchronous meetings that make this so. First, it's harder to facilitate asynchronous disharmony. (However, if you can build a map into the system that people are constantly seeing and checking, that could in theory help. This is the basis for my methodology.) The problem is that it's difficult to bring the map to people's attention, or to facilitate online discussions in general. Second, people have a tendency to have one-on-one discussions over public mailing lists. People also do this in face-to-face meetings, but again, you can facilitate that. So what do you do about those one-on-one discussions? Do you map them? It depends. If it's substantive discussion, not just a series of inside jokes and wry comments, then yes, of course you do.

Graphical depiction shows you things that an outline view does not. For example, spatial clustering of nodes. It's an important technique, where people are clustering concepts without knowing how to label those clusters. Not maintaining the clusters by flattening the view is a significant loss of semantic information.

See Also