Visual Thinking and BPM
- March 22, 2012
- 1 Comments
While at SXSW I attended a session titled “Shut Up & Draw: A Non-Artist Way to Think Visually“, which any BPM practitioner could have related to. Sunni Brown, Jessica Hagy, and Dan Roam ran the session, and had some great ideas to take away. I jotted a few notes:
- Visual Thinking as language – as something you need to have literacy in. It doesn’t matter the quality of the line drawing, but how effective it is for communicating.
- Visual Thinking isn’t “art” – with ART you want to be ambiguous – leave things open to interpretation by the viewer. with visual thinking, you want to be explicit – eliminating ambiguity in key ways.
- Perfection isn’t the point – communication is the point. You can explain concepts with a picture that are actually very difficult to explain in words – such as the difference between rotating and revolving…
- We lack visual literacy, but we need this literacy much as we need to be code literate or product design literate – or literate in the traditional reading and writing sense.
- Why? Information density of drawing is really high compared to explanation. Imagery shows you complex information, but simply – like a fantastic filter or lens.
- As an example of effective drawing, they discussed the Laffer curve (drawn on the proverbial napkin) that has impacted tax policy for the next 40 years.
- I didn’t check references on this, but they also claim that we might be the only mammal where our brain has different form and function on the two halves – one half good at breaking things into discrete pieces, and one half really good at bringing the picture together into a whole. I’ve not heard it explained this way before, but I recall learning about the brain’s key innovations being twofold: 1) to generalize, and 2) to discriminate. Sounds pretty similar.
Another really interesting point they made was that drawing is an extremely effective way to convert someone to your point of view – to convince and explain. They even cited a scientific study – which ironically used no pictures to explain their point…
But I found this last point about resolving disagreement resonates with another post I read on 37signals, which concerns giving a new idea a few minutes to sink in before disagreeing.
Richard has spent his career thinking about these problems. He’s given it 30 years. And I gave it just a few minutes. Now, certainly he can be wrong and I could be right, but it’s better to think deeply about something first before being so certain you’re right.
There’s also a difference between asking questions and pushing back. Pushing back means you already think you know. Asking questions means you want to know. Ask more questions.
Combining “withhold judgment for a few minutes” with “draw me a picture” is a fantastic way to understand how you and someone else disagree. And once you have a picture, you can modify the picture to show them how you look at the same set of facts differently, or how you are applying the same philosophy but seeing different facts… It’s very effective.
How does this relate to BPM? It should be obvious – but drawing pictures of processes isn’t just about executing them – it is about explaining the ideas. Eliminating ambiguity – not ALL ambiguity, but key ambiguities that can lead to process failure.
And I can already hear some of my BPM colleagues saying “sure, drawing a picture of the process is great for discovery or explaining, but when it comes to executing – disaster!”
Not so. Think of the uses of these BPMN (or other diagramming) pictures at execution time. When you find a “bug” in the process, you can look at the picture of the implementation and understand it. If you need to fix something that you understand from a process perspective, you can follow an unambiguous diagram, to find the context for the process problem, and drill into the details. And our minds tend to remember shapes and space better than lines of code. There’s a familiarity with a process diagram that develops over time that you retain long after you would have forgotten the structure of code.
So go ahead and critique BPMN and other process diagramming techniques – try to improve them. But don’t think that drawing processes has no value – drawing is a pretty effective communication tool.