On the use and abuse of Technology and its Management from the perspective of an academic at UCL specialising in Project Management, Systems Engineering and Space Science/Technology.

Tuesday, July 18, 2006

When do you use a proper diagram?

It's like I keep saying, it depends. If you want to tell people about something, and don't want no argument, you should probably draw it up neatly in a language they understand.

Visual grammars are somewhat mysterious though, as the following example will I hope show.

If you want to work something out visually, a modeller is going to want to use a live, computer-based representation of their problem. The richer the better as far as a modeller is concerned. They are happy to learn the details and spend days playing with the configuration of the diagram. Being a proud sort, they will bring it to the meeting and say look at this, play with it. I've seen instances of this where the above-average-intelligence audience have been interested in the problem, wanting to contribute, but have been struck dumb by the strangeness of the notation. Uh dunno, you do it mate report back when it's finished. Next Agenda item please.

Tragic. The investment in learning visual language is never made properly.

That's why I like stealthy visual grammars, that emulate the anything goes world of the flip chart and sticky note. They are much more amenable to debate and contribution.

If you want to involve people in a group, you need a visual language that's approachable by them. You can't just say "oh it's UML, get with it", you have to make allowances.

Take a look at Nick Duffill's these two diagrams from the Beyond Crayons blog (also refers to Patrick Mayfield's little article on visual mapping in Systems Thinking).

See how in Nick's comparison, the second diagram looks more rigid, and less likely to be argued with. He also makes the point that the tree-like diagram obviously goes somewhere (the Outcome) rather than its wiggly predecessor.

Incidentally, he calls these Open Systems and Closed Systems but I don't think that nomenclature is quite right. He's referring to whether the system state evolves as a whole or whether things keep going forever. Essentially one diagram shows forces, and no state, and the other shows some forces, and a big change of state. Different objects, as well as a different grammar.

Very often these models are faulty on first presentation, but somehow the apparently finished state - signalled by the neat lines - is off-putting. The reaction could be "that's a bad model take it away" rather than "you missed this bit out HERE let me fix it".

No comments: