Software companies aren't the only organizations that lean on diagrams to help explain complex systems. Many businesses and government departments use diagrams to explain their different processes.
The Department of Defense, for instance, is diagram-mad. Literally, if you take some generals' word for it. A few years back, two diagrams from within the DoD made it into the mainstream media, one even onto the front page of the New York Times. They were used as examples of Powerpoint-gone-mad, where overzealous bureaucrats and engineers were swamping soldiers with pointless diagrams that one general simply labelled “stupid.”
In reality, these diagrams were anything but. They were astoundingly complex, and to the layman seemed pointless. But to the experts, they were perfectly understandable.
As software becomes more complex, this is a problem that any engineer can run into. The urge can be to dumb down to appeal to the widest possible audience. But as these diagrams show, no matter the complexity of your subject, they work as long as you and your audience have the right information and context.
The first diagram that drew ire was one that showed the life cycle of defense equipment and materiel, pithily titled “Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System.”
The second one was an overview of the military strategy in Afghanistan. It seems even more spaghettified:
As one general put it when seeing this diagram, “When we understand that slide, we’ll have won the war.”
Both of these drew criticism. It's not difficult to see why. If we go through our Top Ten Pro Flowchart Tips, these are failing on a number of levels:
Size Matters: A flowchart is most useful when it fits on one page (or screen). Even when you fullscreen these, parts are still very difficult to read. The Integrated Acquisitions Technology and Logistics Life Cycle Management diagram is actually a three-foot wall chart.
Be Consistent: A flowchart will look more professional if you use consistently sized and spaced shapes. In both, arrows lead everywhere, and boxes or text seem to be placed wherever there is remaining space.
Get Hyper:One common flow chart blunder is to overload the diagram with too much information.Er, yep.
Take it off: Are you sure you need borders around all of your shapes? What about drop shadows and gradient fills? The Afghanistan Stability slide is minimalist in its styling. The same cannot be said of the life cycle management diagram. Gradients galore!
Key Master:Some flowchart symbols are self-explanatory. Other shapes are less easy to decipher. Make sure that you’re communicating clearly by including a symbol key. Again, the stability diagram provides some understanding of the color scheme. The life cycle management diagram not so much.
Initially, it seems the ire is justified. These are bad diagrams. But you, and the readers of Wired and NYT are missing one vital thing: Context.
The first diagram drew so much displeasure that it was updated to this in 2014:
Unless you are involved in any part of the process. Here are some of the comments under the post announcing the release of the new version, from the people who actually needed to use it:
The new wall chart is beyond inadequate. I frequently referenced the old wall chart and was looking forward to the promised update. Compared to the previous chart, this one is a blank page. It is NOT useful. Please, please reconsider.
As a Systems Engineer, this new chart is a step backwards. The prior Wall Charts were a convenient single-source reference for the timing, inputs, and outputs of almost all acquisition related technical processes, reviews, and reports. While some made fun of the systems engineering “V’s” in the bottom half of the chart, to a good DoD Systems Engineer they provided a strong foundation for the scheduling and expected products of our activities.
If this chart is designed to be a replacement for the old, it is totally inadequate. Most of the useful information in the old chart is gone.
Beyond useless. I continue to use the old one, both personally, and when explaining process to clients.
Ouch. Those aren't good reviews. To the naive viewer, the revision is better. But to the expert viewer, it lacked the detail and nuance that made the diagram worthwhile. Instead of having something they could use, they now just had a lot of blue-gray space (though at least the gradients had gone).
When people scoffed at this in Wired, they lacked context. They weren't the audience for the diagram, so just saw it as a large collection of poorly-colored, poorly-organized boxes. But a systems engineer navigating defense acquisitions could immediately find all the information needed on that chart.
The demolition of the “Afghanistan Stability” graph also lacked context. The complex diagram that was splashed across the New York Times was a single slide of a 30 slide presentation. As David Liu of SD Wise, a blog about system dynamics, puts it:
Yes, a causal loop diagram can seem overwhelming without explanation. So is any engineering diagram without explanation. But if you are a System Dynamics practitioner, you would know that the creator of the slide would have provided additional slides that explained the diagram in detail. The full set of draft slides actually provides sufficient explanation to avoid confusion.
If you look at the entire deck, the slides preceding and the slides following this one help dive deeper into individual areas, and isolate important loops:
This is a tightrope. Sometimes your diagrams will be confusing for an audience, even an educated one. But, contrary to popular belief, both these castigated examples show that it is possible to build a complex diagram about a complex topic and for it to work.
To help you do so, here are 3 quick tips you can use.
1. Listen to your audience
It seems odd that no one at the Defense Acquisition University asked vendors, engineers, or colleagues whether they found the initial Life Cycle Management diagram useful and wanted it changed. If they had, the answer would've obviously been a resounding “no!”
Your diagrams are made for a specific audience. It doesn't really matter what anyone outside that group of people thinks about the diagram. As long as it gets your ideas across to your product managers, marketers, or other engineers it can be as complex as needed—within reason. When you present to them, ask for feedback—what was clear? What wasn't? Then iterate on that until you are able to present the knowledge you have in a way that transfers that knowledge.
2. Don't be afraid of your complexity
General McMaster, then Commander for Planning in Afghanistan and now National Security Advisor, was a confirmed hater of the Afghanistan Stability slide, and Powerpoint in general. Talking to the New York Times, he said, “It’s dangerous because it can create the illusion of understanding and the illusion of control. Some problems in the world are not bullet-izable.”
But in criticizing the diagram, he's actually shown its strength. When you look at it, you get the opposite of the illusion of control. With so many variables you actually get the feel for the complexity of the situation. This goes for any diagram. If you are talking about a complex idea, such as software, the diagram needs to contain that complexity to actually help the audience.
3. Keep it together
The Afghanistan Stability diagram was lambasted in isolation. When you go through the other 30 slides in that deck, you see how each of the individual components fit together. But this was lost in the takedowns in the NYT and Wired.
If your diagram requires extra information, then you have to follow one of our Top Ten Pro Flowchart Tips—Get Hyper. If it can't all fit on the page but is still important, then link through to other documents. Very few people are printing out flowcharts anymore. They can be smart documents that contain more information underneath. That way everything always stays together. That is, until it's printed on the front page of the New York Times.