Diagram Creation: 5 Vital Questions for Success

Do you know what unites novelists writing books, marketing specialists crafting promotions, and us, who create diagrams? It’s the fear of the blank page! ‘Where do I start?’ is the very first and often the most frustrating question for diagram developers. Without an answer, one might procrastinate, staring at an empty draw.io canvas for hours.

In this article, we have gathered five crucial aspects that one should consider before creating a diagram. Investing time in this preliminary research can significantly reduce the number of iterations in the diagram development process.

1. Process scope

What is the scope of the feature that needs to be explained with a diagram? This is the most essential question to ask yourself before opening draw.io. Because at this point, you not only figure out the initial and final points of the process, but also decide whether or not explaining the process with a schema is a good idea in the first place.

Sometimes, the route between START and END drastically depends on multiple external and internal conditions piling up with each next step of the process. For example, the number and nature of tasks in a process may vary depending on whether or not User is logged in to the system, what information about User is stored in the database, what User’s settings and preferences are, and many other factors. So, instead of growing an unreadable tree of conditions in one diagram, it’s better to find all possible combinations of the factors and provide a separate atomic scenario for each combination (not necessary in the form of a schema).

NOT RECOMMENDED

RECOMMENDED

Another benefit of the latter approach is that you can concentrate on those cases that are of interest to your target audience. For example, you can concentrate on the most common scenarios for Users or, on the contrary, on corner cases that are not evident but have to be processed in the system.

The nature of a process may not actually require diagramming. Imagine, you are approached with a task to create a schema that would explain a flow of creating a specification for a new feature. And according to the requestor’s requirements, the schema is supposed to answer the following questions:

• Who is responsible for creating a specification?
• What are the steps needed to create a specification?
• What input documents should be used in each of the steps?
• What are the output artifacts of each step and where they should be stored?
• Whom to address questions?

Even though diagrams have an exceptional power to deliver a message, especially when it comes to explaining processes and procedures, in this particular case, a simple step-by-step instruction with steps as headlines and a paragraph for each question that needed to be answered is just enough:

2. The target audience

Who is the target audience of a diagram? What problem does this audience have that the diagram is supposed to resolve (or at least help to resolve)? Do they use diagrams and schemas in their work regularly and are they comfortable to read them? And if no, it’s another reason why you might not need a diagram.

When figuring out your target audience’s profile, you will be getting the following useful input:

• the level of proficiency in reading diagrams: you create a diagram to explain a process to someone, not to pass an exam on UML or BPMN. If your target audience does not find reading diagrams so appealing, keep them simple – avoid uncommon elements and add clarifying comments where needed.

• the language to use in diagrams: sometimes it’s OK to use jargon in technical documents and diagrams, in particular. If it’s the language that your target audience knows and uses daily, why not?

• the access to the diagram: the type of the diagram, its orientation (vertical or horizontal), the minimal font you should use, … These and other nuances hugely depend on how your target audience will interact with the diagram – on a big screen, a tablet, or a mobile device.

Additionally, knowing your target audience will help to identify the main focus, primary and secondary actors of the process, and the level of detail that you should provide in the diagram.

3. The main focus of the process

The golden rule of any diagram is to have one main focus. To figure it out, ask your target audience “What is the primary objective of the target audience that the diagram should help to achieve?” And don’t accept broad answers like “The team doesn’t understand how the process goes” or “We need an overview of how to work with Invoices”. Such requests are too vague, and a single diagram cannot address them effectively! There should be one specific sore spot, one aspect of the process where the team struggles the most, and this pain point will be the main focus for the diagram.

Here are some examples of valid target audience’s goals:

• “An Accountant should be able to fill in an Invoice from scratch and send it for approval”
• “A Developer should understand what information is saved to what tables in the database in each stage of the Invoice lifecycle”

When you have the main focus in mind,  it acts as a filter throughout the diagram development process. For example, if you’re unsure whether to include information about database interactions in a diagram designed for Accountants, ask yourself, ‘Will this information assist my target audience in achieving their goal?’ If not, it should not be part of the schema.

4. Primary and secondary actors

Depending on the target audience and the main focus of your process that you’ve figured out in the previous steps, you are going to define who are the primary and secondary actors. For instance, an Accountant responsible for creating, filling in, and submitting an invoice may serve as the primary actor, while a software product (System) that validates, stores the invoice in the database, and sends it to some destination may be one of the secondary actors. And vice versa, depending on whether you explain the process to accountants focusing on their responsibilities and tasks or to software developers who are about to maintain the system.

There can be more than one primary actor, and there are always multiple secondary actors. However, if you find several primary actors, ensure that they are from the same target audience and share similar interests in the diagram. In our example, it would be inappropriate to include both the System and the Accountant as primary actors in the schema because they have different needs and understandings of the process. The nature of their activities is distinct, resulting in two main focuses, which is undesirable. On the other hand, a Financial Controller who participates as an approver at various stages of the invoice lifecycle can be considered another primary actor because the nature of their interaction with the document is similar to that of the Accountant. In this case, your target audience encompasses not just one role (Accountant) but an entire department (the Financial Department).

To illustrate the difference, let’s examine two diagrams representing the Invoice lifecycle. The first one covers only those activities that the Accountant performs throughout the lifecycle. When they send the Invoice for approval to the Financial Controller, it doesn’t matter what happens next in the process (what the Financial Controller checks, who else is involved, etc.) until the document returns to the Accountant with a status – Approved or Rejected. So, the main focus of the diagram is on the role of the Accountant.

In the second diagram, the same Invoice lifecycle is presented but from the perspective of the Financial Department. There are three roles – Accountant, Financial Controller, and CFO – each of whom interacts with the Invoice at some point. In this case, what exactly happens with the document in each lane matters.

Diagram 1

Diagram 2

A logical question that follows is whether you should create two diagrams when you have different target audiences for the same process. The answer is ‘Yes’. The downside is that it will require twice as much time. The good news, however, is that both diagrams will provide valuable information to their respective groups, earning you double the appreciation for the job.

5. The level of detail

Different target audiences may require varying levels of detail for specific stages of the same process. For example, an experienced Financial Controller won’t need extensive explanations on how to approve an invoice. In contrast, a junior member of the Financial Controlling team will appreciate seeing the Approve Invoice activity represented not as a simple task, but as a sub-process with atomic tasks, such as Consolidate Date, Reconcile with POs (Purchase Orders) etc.

Another example pertains to Developers as the target audience. If the system is to be developed from scratch, it’s advisable to present the Verify Invoice activity as a sub-process with a separate sub-diagram containing all technical details. However, when the system is already established, and everyone on the Development Team is well-versed in how the verification process functions, with no anticipated changes within the diagram’s scope, a task block is sufficient.

In summary, here are the key takeaways before you dive into diagram creation. First, define the scope of your process, ensuring that a diagram is the right tool for the job. Next, know your target audience inside out, from their diagram-reading proficiency to their preferred language and access devices. Third, identify the main focus of the process; pinpoint that one critical pain point your diagram should address. Then, determine your primary and secondary actors, keeping them aligned with your target audience and their specific interests. Lastly, tailor the level of detail to suit your audience’s needs, whether it’s high-level overviews or intricate sub-processes. By embracing these five considerations, you’ll craft diagrams that truly resonate and communicate effectively with your intended viewers, making your investment in the process worthwhile.

Want to dive deeper into the world of draw.io? Access our linktr.ee page to follow us on social media and learn how others use draw.io, as well as pick up some helpful tips and tricks.