Diagram arrangements

Aesthetics matters!

For a number of years I did quite a lot of teaching — computer systems analysis and design, and also data modeling and database design. During the classes the students and I constructed a lot of diagrams of various kinds.

In my classes I tried to impress upon my students the importance of the arrangement of their diagrams. The layout of a diagram conveys important information about the basic structure of the domain — application, database, process, or whatever — that is being diagrammed. Aesthetics matters!

Here are some examples that illustrate that point. All of these diagrams are structurally identical. They all contain the same number of nodes, connected in the same way. But they are arranged differently, and the different arrangements tell very different stories about the basic structure of the domain being modeled.

Example 1. The domain is basically tree-structured, hierarchical.


Example 2. The domain has two basic parts. Each part is almost self-contained, with a very limited interface between the two parts.


Example 3. The domain is basically a sequence of parts. Some of the parts have sub-parts.


Example 4. Here is an example of how not to diagram a domain.

If your diagram looks like this, you need to untangle it. Make it tell a clear story about the basic structure of the domain.


Some tips about diagram arrangements

1. Try to avoid having connector lines crossing other connector lines.

2. Your diagram should have a clear flow or direction:

  • left to right
  • top to bottom
  • center, radiating out to edges

Diagrams that represent processes (e.g. process flow diagrams) have a natural flow based on the sequence in time of the processes being represented. The flow of the diagram nodes in space should reflect the succession of the processes in time. And it should be consistently in one direction: left to right, or top to bottom, or center toward periphery.

When diagramming static domains that don’t have a natural temporal flow (e.g. class diagrams, entity-relationship diagrams, database diagrams), the diagram’s direction of flow should be from the most important nodes (entities/classes/tables/modules) of the application toward the less important nodes.

Put the most important nodes at the beginning of the flow — at the left, top, or center of the diagram. Their position on the diagram helps to draw the viewer’s attention to them, and indicates that they are the important nodes in the domain.

3. If rule 1 (no crossing connector lines) conflicts with rule 2 (natural flow), rule 2 takes precedence.

Avoiding crossed lines is desirable, but the most important thing is that the nodes of the diagram have a clear, natural flow.

In developing a database design diagram, you might be tempted to put database lookup tables (reference tables, mapping tables, translation tables) at the center of the diagram. After all (you think), the database design contains many foreign keys that reference the lookup tables, so putting the lookup tables at the center of the diagram will avoid a lot of crossed lines.

True… but still not a good idea! The lookup tables are simply part of the mechanics of database design. They are not of core importance for the business application for which the database is being designed. They belong at the edges, or the bottom, of the diagram

4. Switching your diagram from portrait mode to landscape mode (or vice versa) may make it easier to create a diagram with a natural shape.

Some diagrams are naturally tall and narrow (like example 2) while others are naturally short and wide (like example 3). Take advantage of the printer’s ability to switch between portrait and landscape mode.

About empty space

The most common mistake I see is to try to arrange a diagram so that it fits on a single sheet of paper, rather than arranging it to show its natural structure. The result often looks like example 4.

Do not do this!

The most important rule of all (because it is so often violated) is: Once you have a nice clean diagram that tells a clear story about the domain, do not rearrange it so that it will fit on one page.

Keep the size of your nodes fairly small. This will increase the amount of empty space on your diagram.

Don’t try to use all available space on the page. You want empty space in your diagram. Empty space gives you room in which to arrange your nodes in a way that has an obvious structure that tells a clear story.

If your diagram is too big to fit on one printed page:

  • Arrange it for printing across multiple sheets of paper.
  • Print it on a larger size sheet of paper.
  • Shrink the size of your nodes.
  • Split the diagram into two separate diagrams, and use off-page connector symbols to link the diagrams. A diagram like Example 2 is a good candidate for this technique.
  • Decompose your single diagram into a set of hierarchically decomposed diagrams (like the old dataflow diagrams of structured analysis).

If necessary, to avoid a lot of connector lines crossing all over the diagram to get to one lookup table, draw duplicate nodes representing the same lookup table on your diagram. Position them so that you can minimize crossed lines and so that they are in keeping with the direction/flow of the diagram.

This entry was posted in Software Development and tagged . Bookmark the permalink.

One Response to Diagram arrangements

  1. Kenny Meyer says:

    I loved this class 🙂 .


Comments are closed.