Drawing Diagrams – Best Practices

One of the aims of modeling is to present complex issues at such a level of abstraction that will allow us to understand a given aspect of the problem. When in the organization models are prepared by several, a dozen people it is worth to determine two things: the principles of modeling and aesthetics of diagrams.

Modeling rules will tell us what and how we document, what notation we will use. Aesthetics of diagrams is to establish certain rules that will allow you to analyze diagrams faster and easier. We are more efficient when we work according to a common set of standards and guidelines, even if these tips are not perfect. It’s like talking in the same language – it’s easier to understand and maintain models created on the basis of effective tips and having commonly used descriptions. Models built according to the same rules improve internal communication – in the team and external – with partners and clients, reducing the possibility of misunderstandings. Tips for modeling aesthetics also save time by limiting stylistic choices, allowing you to focus on creating diagrams.

I allowed myself to collect a few recommendations. In the description, the term pictogram is used interchangeably with the name of the diagram element. Here are the recommendations:

Avoid intersecting lines. Two lines intersecting the diagram can be misread. If you cannot avoid crossing the line, draw one so that it “jumps over” the other so that the difference between them is clearly visible.

Avoid oblique or curved lines. Straight lines, drawn horizontally or vertically, are easier to track visually. If you have a mesh mechanism in the modeling tool, apply it. Placing pictograms on the diagram in such a way as if their center was at the point of the grid makes it easier to connect the bubble only by means of horizontal and vertical lines.

Draw pictograms with consistent dimensions. The larger the element in the diagram, the more important it seems. If you do not want to get this effect, try to make sure that the pictograms have a uniform size. Note that using some of the modeling tools in the diagrams, they automatically change size depending on their content, so the size of the elements may be out of your control.

Leave empty spaces. These are free spaces between the modeling elements on the diagram. If there are a lot of elements on the diagram, it may be difficult to distinguish to which pictogram and line the given label is assigned, which reduces the readability of the diagram. Sometimes, if you use the modeling tool, you can be encouraged to reduce the amount of empty space to be able to print the diagram on one page. Take care not to reduce the usability of the diagram – it is sometimes advisable to stick two pieces of paper together to maintain readability.

Arrange the diagram from left to right, top to bottom. In the west, people read from left to right and from top to bottom. If the diagram has a starting point from which it should start, such as the initial state of a state machine diagram or the beginning of a business process, place it in the upper left corner of the diagram and start from there.

Show only what you need. Diagrams with too many details are hard to read because there is too much going on. One of the practices is to present the model in a simple way, so that the diagram contains only key information and does not contain anything irrelevant.

Avoid esoteric descriptions. A diagram containing many mysterious symbols, abbreviations, etc., instead of focusing on 20% “descriptions of the essence of the matter”, which in 80% deal with the matter, may be difficult to read.

Make small diagrams. It is usually better to make several diagrams with different levels of detail than one, a complex diagram that shows everything. A useful rule is that the diagram should not have several, a dozen pictograms, because the amount of information that a human being is able to process at one moment is limited.

Focus on content rather than on appearance. Do not spend a few hours rearranging the layout of elements and lines to improve readability. The best approach is to concentrate first on the contents of the diagram – it does not have to be perfect when working on it. Once you are satisfied with the level of its accuracy and decided that it should be so, then you can devote some time to refine its appearance.

Establish effective naming and stick to it. This ensures consistency of the model and  increases its readability. Even better, if consistent and recognizable terminology is used in your diagrams. This is especially true for business-oriented diagrams, which should also involve people interested in the project.

The list, of course, is not complete. It is worth for each team to establish its modeling principles. This is important especially in those teams, in which diagrams describing similar issues drawn by two people are diametrically different – especially in terms of the number of pictograms used.

If you use other good modeling practices in your work, I encourage you to share them in a comment.

More from my site

  • Partially Done Work In the previous posts, I discussed the tasks and the board in Kanban. In order to be productive, you must focus on one task at a time. Kanban facilitates this process and defines the term […]
  • Tracking of Relationship Between Requirements An important aspect of requirements management is the ability to trace the relationships between requirements and other artifacts (including other requirements). The ability to track […]
  • Implementation of the Methodology – Selection of a Modeling Tool In many companies there is a discussion about formalizing the software development process. Spontaneous creation of diagrams by broadly understood analysts and designers does not build […]
  • Impact Mapping In my practice I have met many times the situation in which the change was implemented in accordance with the maxim of King Julien " Quick, to the volcano, before we all come to our […]
  • Levels of Business Architecture and Business Process Modeling In the previous article of Modeling Business processes in the software development process, I described the meaning of modeling business processes. In my opinion, business processes […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top