In an earlier post on the Qualities of an Architect, I wrote
From architecture and design to strategy and roadmaps, effective visual media for both technical and non-technical audiences helps avoid costly misunderstanding. Pictures may be worth a thousand words, but they are also worth hundreds of thousands of dollars when they help ensure constant alignment and common understanding between stakeholders. Words can often be misconstrued, misunderstood, or missed altogether, but a discussion over a picture is almost always more memorable and effective at creating a shared understanding.
Diagrams are truly invaluable in any discussion of a complex topic. But we all know that diagrams can take on a life of their own, being consumed before a discussion takes place (e.g., as preparatory material) and after the discussion is long over. Unfortunately, a poorly-constructed diagram can easily, though unintentionally, mislead and be misconstrued. Here are a few quick tips to improve the effectiveness of your diagrams as a means of communication.
1. Speak the Language of Your Audience
A picture is simply a tool, used to say something to somebody. Every diagram you build should embody a specific message to a specific audience. Ensure that the language of the diagram is intelligible to that target audience. In my experience, UML diagrams are great for conveying detailed design information to a technical audience, but they almost never convey anything meaningful to a management audience. Rebuilding a UML diagram to speak to a non-technical audience is worth the time and effort. The “design language” of the diagram should be as intuitive as possible for the target audience. In the same vein, be mindful of abbreviations, acronyms, and detailed technical names. For example, a component named 802.11 Driver may be more clearly labeled Wi-Fi Support for a non-technical audience. Alternately, a developer audience may prefer to see more detail, such as 802.11a/b/g/n Driver.
2. Minimize the Visual Noise
Thinking about the desired message to be conveyed by the diagram, evaluate every element of the diagram with a critical eye. Does each element support the intended message? Or does it distract from the message? Is it critical information, or superfluous? The latter should be eliminated, or at least minimized. Many times when adapting a technical architecture diagram for a non-technical audience, I have combined multiple important, but largely irrelevant, elements into one general “component” to reduce the visual clutter of the overall diagram while maintaining the context of the salient elements. You can also use lighter shapes of gray to retain yet underemphasize important related, but not central, contextual elements.
Remember that a diagram which is trying to say everything at once will likely say nothing at all.
3. Simplify the Connections
Many diagrams use connectors – usually lines – to denote relationships between discrete elements. Think about what the relationships are, which ones are important to the intended message, and make those clear and concise. Arrow heads, for example, add to the conceptual complexity of a diagram. If every connector on your diagram has an arrow head at both ends, delete the arrow heads altogether – they are not adding useful information. If you must use arrow heads, make them as small as possible (but still visible, of course).
If at all possible, arrange the elements and connectors to avoid crossing. Consider overlaying the connectors from multiple elements to a single other element. This can be especially effective with connectors which use right-angled bends. Use different line styles to indicate different types of relationships between elements. But again, only include distinctions for those relationships which are important to support your intended message.
4. Be Consistent
Use shapes (rectangles, ovals, boxes, etc.) to mean something, and then be consistent in applying those rules. Mixing shapes for no reason, or for no pertinent reason, makes a diagram harder to comprehend. Our minds most often assume that different things mean something different – work with that, not against it.
Be consistent with shapes, borders, connectors, labels, fonts, font styles, alignment of shapes and text, etc. Decide on a look and feel and apply that consistently across the diagram. Eliminating unnecessary differences will increase the comprehension of your audience.
5. Use Color With Purpose
Color is often seen as an exception to the consistency principle. A colorful diagram is a more engaging diagram, right? Well, not necessarily. Color can be very effective at supporting your diagram’s message when it is used with purpose. Otherwise it adds to the complexity and visual noise. Different colors should mean different things, and that applies to shape fills, borders, labels, and connectors. Define a color scheme and apply it consistently.
Colors can be used on roadmaps, for example, to distinguish past, present, and future elements; facts and plans versus assumptions and alternate plans; or to distinguish between business, market, technology, or talent concerns. Colors can be used on architectural diagrams to indicate system layers; existing versus in-work versus planned components; component development teams, suppliers, or partners; quality status; etc.
I have found that color is very effective when used to describe specific aspects of a diagram in turn. I will often introduce a monochromatic diagram, and then show subsequent versions with specific elements colored in turn as they are discussed. Note that not all font colors display well on all fill colors. A black font, for example, will almost never display well on a red background; use a white font instead. Change the font color with the fill color as needed to maintain clear legibility.
Bear in mind that any diagram communicated electronically (as opposed to printed) may be printed in color or grayscale. It may be worth a little extra effort to ensure that your color choices are distinguishable enough in grayscale to still convey the intended information. When including color meanings in a key or legend, use the color itself (e.g., in a small, filled shape) instead of simply the color name to aid with grayscale print, or poor-quality color printers, projectors, and monitors.
6. Include Appropriate Metadata
At the very least, every diagram should have an accurately descriptive title. State, as succinctly as possible, the purpose, scope, or message of the diagram. The title should be clearly visible and, aesthetically, considered part of the diagram itself. Other helpful information to consider showing on any diagram includes the following:
- The author or owner (person, team, business unit, etc.) of the diagram will serve as a point of contact for consumers who receive this diagram out of context, or who may have questions or input. A listed owner also implies responsibility and accountability for the message and information in the diagram, which tends to promote higher quality work.
- Including the date and version (if applicable) of the diagram helps to further specify the context in or for which the diagram was created.
- A key or legend should be included if there is more than one shape, connector, color, etc. with specific meanings. Not all diagrams require a key, but many can benefit from one nonetheless. Again, imagine someone looking at this diagram with no context. What is implied or unstated which can be easily clarified in a key?
- Restrictions, or acceptable use labels, are required by many companies, especially if the diagram includes proprietary information or intellectual property. You and your team should be familiar with the legal requirements of your organization. Full compliance, even on “minor” diagrams, helps to build the habit and broaden awareness.
- Include a status indicator when applicable. These will vary based on your organization’s processes, but may include monikers such as Draft, Reviewed, Approved, etc. If your approval process requires sign-off, add a signature line and include the required signature and date as part of the picture itself.
It is important that the metadata does not overwhelm the diagram itself. The title, the restrictions, and the key should stand out (and relatively in that order), but the rest should be cleanly understated. A classical architectural blueprint is an example of this principle, where metadata is included in neat boxes along the edges of the diagram.
7. Get Feedback!
Finally, realize that you as a creator will develop an emotional attachment to your diagram that will cloud your judgment of its efficacy. Show it to someone! Get some honest input as to whether or not the picture is conveying what you think it is. Ask what is confusing or unclear. Be sure to get input from someone with a similar situation, background, or viewpoint as your intended audience.
Please share other tips below!