10 rules to make better diagrams

10 rules to make better diagrams
Brief:
Diagrams are created in many projects to illustrate ideas, express structures and describe relationships and interactions. Good diagrams speak for themselves.
But making a clear and informative diagram is never an easy job, miss use of diagrams not only make the users confuse, some times even leads to misunderstanding.
This article will explorer the means can be used to make diagrams clean and expressive.
Printer friendly is also a big concern of this document, especially for gray scale printing.
Diagrams for small party brainstorm may not need to align to rules and standards, thus not the topic of this document.
Contents:
1. Choose the right diagram type and align to the standard
Each type of diagram is defined to describe a certain type of information, e.g., UML diagrams are used to draw software structure and ER diagrams are used to design databases.
Know what type of diagram to use is important. Each type of diagram has defined a set of building blocks can be used which represents certain aspects of the problem domain. Don’t mix building blocks from different kind of diagrams, doing that not only will be hard to maintain, but also break the common understanding between people about the standard diagram definitions.
It might be alright if you just use the diagram with few people to exchange ideas, but if the diagram is to be used formally, pay some time to learn the standard usage of your diagram, because each diagram is also the language in the problem domain.
2. Divide the diagram into regions and plan the landscape
Problems are by nature layered, divide the diagram can add different levels of views of the system to the diagram. Whenever possible, divide the diagram in regions according to their logical groups. This could be done by identify application tiers, internal/external systems, application components or even departments of the organization.
Regioning your system also helps to plan the landscape and make the diagram easy to implement and maintain. You can use borders for different regions to separate them from each other. When applicable, add a light fill to the region can further make the diagram look better and make the boundary clearer.
Rules to divide diagrams:
o Make small groups, try to keep less than 10 items in each region
o Make internal regions for large item set
o Outer regions should have heavier borders than internal ones
o Use cloud or simple package to identify regions that is not main concern of the system
o Fit the whole diagram in a out most region can improve readability
3. Carefully use of colors
Too many colors may look good, but are also easy to raise misunderstanding, you cannot assign a meaning for each color, and then all the color cannot express meaningful information to the users.
Carefully choose the colors and define the meaning for each. When used for decoration, try use lighter colors and reuse it across the diagram.
Keep in mind that colors are different when printed, for most mono color printers at least. So keep these users in mind and avoid using too many colors. Snapshots will lose most of the color information when printed, so don’t rely on colors to tell things if the target users will be using the printed version.
Guidelines when using colors:
o Different colors may appear the same in gray scale rendering/printing.
o Only few gray scales can be identified by human eyes.
o Blue and yellow appears light while red appears dark in gray scale rendering
o Use dark and light colors together to emphasis the contract
o Use colors to group objects
o Whenever applicable, define the meaning for colors of each building block
o Carefully use black and white. Keep the diagram neat makes it look more professional.
o Define a palette, if using VISIO or other diagramming tools, tracking the colors used.
o Screenshots lost color information when printed
4. Define the meaning for lines and arrows
Lines and arrows are used to connect different part of the system. It should describe how the parts are to be connected or interact.
Use different weight to describe the importance or granularity of the connection. E.g. use lighter lines for inter-component connections and heavier ones for inter-tier connections.
Other concerns when using lines and arrows:
o If text is attached to the line, make sure the user know which line it attach to
o Use patterns for lines if the connections can be categorized
o The direction of arrows is important to understand relationship between items. Make sure you have them right.
o Don't mix straight lines and curves; try use straight lines when ever applicable.
o When using segmented lines, try to keep distance between them
o When using lines for connection, make sure they can just reach the item it connect to
5. Categorize fonts and use few of them
It’s good habit to use a short list of fonts and define the meaning for each. Like the web designers using CSS. Don’t miss-use fonts. Too many pretty-looking fonts might put together to form an ugly diagram.
Styles of fonts are also expressive. Here are some common agreements on styles:
o Keep the text in the building block it belongs to
o Use the same font for text in the same level
o When using lines, align text to the lines
o Use bold for captions
o Use lighter font for descriptions
o Use italic for actions and interactions
o Use a unique font for codes & comments
o Use commonly used fonts, or ship with the document the font used
6. Don’t rely on text to tell the story
Use the least words in diagrams. Diagrams are expressive by nature, and users are supposed to focus on the highlights of the diagrams. Long text will draw the users’ attention away and make the diagram less readable.
If long text need to be added, try use a comment block first and if more information are needed, add a link to an external document.
7. Avoid unintentional overlap and line cross
Keep all the items of the diagram clear and clean. Unintentional overlap and line cross will decrease the readability of the diagram.
Overlaps are intentional made sometimes, for example, in an inherit relationship with the base class and multiple derived classes in UML class diagram. But for most other cases, try avoiding them.
Some rules for overlap control:
o Objects of the same level are not allowed to overlap(except for lines and arrows)
o Lines might have overlapped beginning, but if they have arrows at the end, avoid arrow overlap
o Regions stand for boundaries, don't overlap them for any reason
o Text overlap is prohibited for any reason
o Overlap in a colorful diagram may look good, but after printed it might loss information
8. Put clear legends and sync to the content
Whenever you have a definition for your building blocks styles, put legend for the styles on the diagram, this will sure help the users in understanding your diagram. If you have styles for different types of building blocks, list them in different legends and add a short description near it.
Note: if no legend provided, the styles are considered to have no meaning except for readability.
Keep the legend synchronized with the diagram is another key for diagrams. Always update the diagram and legend at the same time.
9. Choose a simple and expressive title
The title can take up to more than 1/10 space of the diagram; carefully choose a simple and expressive one. It should highlight the intention of the diagram.
Normally put it on top or bottom of the diagram.
10. Test the diagram
Test the correctness and readability of the diagram before send it to the user. It will affect how the users understand the problem. Wrong diagrams are worse then no diagram at all.
You can test you diagrams in the following ways:
o Review the diagram personally, make sure everything is correct
o Ask someone to review, make sure the diagram is readable and expressive
o Print it, check for information lost
Don't send the diagram before test passed
Summary:
This article states the ways can be used to make better diagrams, but the rules are not limited to diagrams. Style sheets and presentation slides also involve these techniques and can benefit if the rules are kept in mind.In fact, whenever provide some document for readers, it will worth the time to carefully refactoring the document for correctness and readability, because save each reader a minute may worth using hours.