Mastering the Language of Process Diagrams: DOs and DON’Ts

Technical Writing champions the use of plain English: monosyllabic short sentences, active voice, and everyday words. Diagrams have their own austere dialect, a language of symbols, arrows, and shapes, often constrained by a limited lexicon. Yet, despite its utmost linguistic limitation, this language excels in enhancing the clarity and effectiveness of procedural schemes.

This article is a practical overview of the Language of Process Diagrams – its grammar, syntax, vocabulary, and the writing system.

The ‘No articles’ rule

In diagrams, we don’t have to worry about the correctness of using ‘a’, ‘an’, and ‘the’. We don’t use them at all. Why not? Here are some reasons:

• to keep diagrams clear and concise: diagrams are visuals that aim to convey concepts quickly and efficiently. Adding articles can introduce unnecessary textual clutter, making the diagram less clear and concise.

• to save space: in diagrams, space is limited, and every element should serve a clear purpose. Including articles may consume valuable space that could be used for essential information.

• to keep focus on key information: articles are used to specify or refer to particular instances of nouns. In diagrams, the main focus is often on categories or relationships between elements rather than individual instances. Articles can divert attention away from the main points.

The two-word pattern for conditions

In process diagrams, conditions are represented with diamonds, and diamonds can accommodate much less text than rectangles and parallelograms. Therefore, it’s advisable to employ a two-word pattern for conditions.

Aside from space efficiency, here are some other benefits the two-word pattern gives:

• Universal Understanding: the format is language-neutral and hence accessible to a broad audience, including those with different language backgrounds or varying levels of expertise.

• Improved Scannability: readers can quickly scan a diagram and identify conditions without needing to decipher complex sentence structures or lengthy descriptions.

• Adaptability: the two-word pattern is versatile and can be used in various types of diagrams, from flowcharts to decision trees, making it a practical choice for a wide range of visuals.

Present Simple as a universal tense

In storytelling, we use the present simple because it serves to engage the audience, create vivid imagery, and clarify the sequence of events, making the narrative more compelling and relatable. Since diagrams are a form of visual storytelling, the rule applies here as well.

Why can’t we use past and future tenses or the gerund form? Diagrams are supposed to be time-neutral and focus on the logical flow of a process rather than when actions occur. Past and future tenses can introduce a temporal aspect that may not be relevant or necessary for the diagram’s purpose. Gerunds can make it unclear whether an action is in progress, completed, or about to be initiated. This ambiguity can confuse readers and hinder their understanding of the process.

You may use either the third person singular form of verbs (for ‘he’, ‘she’, ‘it’ pronouns) or the third person plural form (for ‘they’). For consistency purposes, it’s better to  choose one option and use the same form for all actors of your diagram. For example, if User performs tasks and is referred to as ‘they’, then other actors of the schema (System, Department X etc.) should also be referred to as ‘they’.

Mention actors once

In process diagrams, most often there are multiple actors – User, System, Department X etc. They are represented with swimlanes, and each swimlane indicates the activity scope of the corresponding actor. In other words, all tasks, transactions, and other activities are performed by the same “swimmer”:

Therefore, there is no need to mention the actor in each task. It saves space for more valuable information, and you don’t irritate the reader with repetitiveness.

But what if in a diagram, there is only one actor? For instance, a diagram that illustrates how User logs in to a system (only from User’s perspective). In this case, we can either mention the actor in the title of the diagram (option 1) or add the actor in the very beginning of the schema instead of a starting point (option 2).

One semantic unit per task

Space efficiency is one of the key principles of diagramming. But sometimes it may not work to your advantage. For instance, you have two atomic tasks – Save Invoice (to database) and Send Invoice (to Customer). Even though you can use them in one sentence to explain the process in a presentation, in a diagram, there have to be two separate tasks. Because if they are combined into one, your readers won’t understand whether these tasks are performed in parallel and are independent (even if the Invoice isn’t saved to the database, it’s still sent to the Customer), or they are sequential and dependent (without saving to the database, sending the Invoice to the Customer is impossible).

The rule of thumb is to have one semantic unit per task. And if your Subject Matter Expert uses two semantic units in one sentence, it should immediately trigger your curiosity to find out the causal relationship between these units.

Avoid synonyms

While an extensive vocabulary may be seen as an advantage in the realm of literature, it can be counterproductive in technical documentation. Users turning to technical documents are often in need of quick and practical information. They aim to understand, execute, or troubleshoot a process without the involvement of third parties. When synonyms abound, they must navigate through a labyrinth of various interpretations, risking misunderstanding and potential errors.

Reducing ambiguity through consistent terminology is the path to enhancing the user’s experience, making their journey from inquiry to comprehension as smooth and direct as possible.

Jargon and abbreviations are allowed

If jargon terms and abbreviations are known and understood by your target audience, they are not just allowed, but even welcomed to be used in diagrams. As a person who may not be familiar with specific acronyms and concepts of the field, you feel this urge to explain them to the letter. But, in fact, people in the industry will grasp the idea immediately when seeing a specific abbreviation because they deal with it on a day-to-day basis.

Though, following the best practices of Technical Writing, it’s recommended to have explanations for such terms and abbreviations (to have them as separate articles and provide links to the articles in the diagram).

Exceptions

Any language has exceptions, and the Language of Process Diagrams is no exception. Here are some scenarios where we can circumvent the straightforward and austere rules mentioned above:

1. Complex Processes: In exceptionally complex processes, you may find it necessary to use articles (e.g., ‘a’, ‘an’, ‘the’) to provide additional clarity. However, this should be done sparingly and only when the benefits of added clarity outweigh the potential for increased complexity.

2. Legal or Compliance Requirements: Some industries or fields have specific legal or compliance requirements that dictate the use of certain terminology or wording in diagrams. In such cases, it is essential to adhere to these regulations, even if they contradict typical diagram language rules.

3. Unique Audiences: If your target audience is highly specialized and comfortable with specific jargon or technical terms, you may consider using these terms in your diagrams. However, always provide explanations or links for the benefit of those who may not be as familiar with the terminology.

4. Visual Aids: Diagrams can sometimes serve as visual aids in presentations or training materials. In these cases, you might use different language conventions to engage and educate your audience effectively, even if they deviate from standard diagram language rules.

5. Multilingual Diagrams: In situations where diagrams are intended for a multilingual audience, flexibility in language usage is crucial. You may need to adapt the language to accommodate the various languages your audience understands.

The essence of Language of Process Diagrams lies in simplicity and minimalism. It champions the notion that complexity should yield clarity without compromising the comprehensibility of a diagram. The heart of this language beats with the rhythm of efficiency, where every element serves a distinct purpose, guiding readers towards understanding.

At the same time, the beauty of this language is its adaptability. While we uphold the values of simplicity, we’re not confined to a static set of rules. Instead, it’s a dynamic dialogue, open to evolution based on user feedback and the ever-changing demands of technical communication.

Find out more

You can read the rest of Kate’s blogposts in the series here:

1. Mastering the Language of Process Diagrams: DOs and DON’Ts
2. Multidimensional Flowcharts: Simplify Complex Diagrams at Your Fingertips
3. Navigating BPMN Gateways: Making Sense of 69 Options
4. Diagram Creation: 5 Vital Questions for Success