Start with the question the diagram answers
A diagram is worth drawing when it answers a question faster than prose can. “What are the main parts and how do they connect?” is a different question from “What happens, step by step, when a user presses the button?” and each deserves a different picture. Before drawing, write the question in one sentence and decide who will read the result. A diagram for a newcomer needs fewer details than one for a maintainer, and trying to serve both in a single picture often serves neither.
This article is general guidance. For drawings that form part of a regulated or contractual deliverable, follow the standards and conventions that apply to your industry and country.
Common diagram types and what they show
- Block diagrams show the main parts of a system as boxes and the connections between them as lines or arrows. They suit overviews, such as a sensor feeding a controller that drives an actuator. They show structure, not timing or detail, and they work best when each box has one clear job. The related idea of system boundaries decides which things sit inside the drawing and which are outside it.
- Flowcharts show a sequence of steps and decisions. Boxes describe actions, diamonds usually mark yes-or-no questions, and arrows show the order. They suit procedures, algorithms and fault-finding paths.
- State diagrams show the conditions a system can be in and the events that move it from one to another. They suit anything with modes, such as idle, running and fault.
- Sequence diagrams show messages exchanged between parts over time, reading from top to bottom. They suit interactions between software components or between people and systems.
- Schematics and wiring diagrams show electrical connections using standard symbols. They have their own conventions, which readers expect to be followed.
- Mechanical drawings show shapes and dimensions, again under established conventions for views, tolerances and notation.
- Sketches are rough drawings made quickly to think or to explain. They are valuable, and need not be polished, but should be labelled as informal if they are shared.
Picking the wrong type is a common source of confusion. A block diagram with arrows that sometimes mean “data flows” and sometimes mean “happens next” is trying to be a flowchart as well. When that happens, draw two diagrams.
Keep each diagram to one level of detail
The most reliable way to make a diagram readable is to limit what it shows. A diagram that mixes high-level subsystems with individual connectors and part numbers forces the reader to switch levels constantly.
- Draw an overview with a handful of boxes, perhaps five to nine, and put the detail of each box in its own diagram.
- Use consistent granularity: if one box is a whole subsystem, the box beside it should not be a single wire.
- Cut anything that does not help answer the question, even if it is true.
If a diagram does not fit on one page at a legible size, it is usually showing too much.
Layout that helps the eye
- Flow in a consistent direction. Left to right or top to bottom is the usual convention. Avoid arrows that loop back across the whole picture where you can.
- Align and space boxes evenly. Tidy alignment signals structure and makes gaps and groupings obvious.
- Minimise crossing lines. Rearranging boxes often removes crossings entirely. Where lines must cross, make it clear that they do not connect.
- Group related items. A labelled outline or shaded region around a set of boxes shows that they belong together, for instance everything inside one enclosure.
- Use arrows deliberately. An arrow should say what travels along it or what the direction means. If connections are two-way, show that.
Labelling and symbols
Every box and line should be identifiable without guessing. Label boxes with short, specific names, such as “Temperature sensor” rather than “Unit 3”. Label connections with what they carry, such as signal names, data types or media, where this matters. Use the same name for the same thing everywhere, in the diagram, the text and the code.
Where conventions exist, follow them. Standard electrical symbols or flowchart shapes are understood by many readers, which saves explanation. If you invent notation, add a small legend that explains line styles, colours and shapes. Do not rely on colour alone to convey meaning, since printing in black and white or colour-vision differences can hide it. Pair colour with labels or line styles.
Add a title, a date or version, and the name of the author or owner somewhere on the diagram. A drawing detached from its context becomes unreliable quickly, because readers cannot tell whether it is current.
Check it with a reader
The author sees what they meant. A fresh reader sees what is drawn. Show the diagram to someone who was not involved and ask them to explain it back to you. Misreadings point at what to fix. This is a useful step before one of your design reviews, where unclear diagrams can consume the time that should go to the design itself. The same is true in technical presentations, where a diagram may be on screen for only a minute and has to be understood quickly.
Keeping diagrams maintainable
Diagrams go stale as easily as text. A few habits help.
- Prefer tools whose source files can be stored with the project, so that diagrams can be changed, compared and versioned like other material. Text-based diagram formats suit this well, though a conventional drawing tool is fine if its files are kept under control.
- Keep a single authoritative copy and link to it rather than pasting pictures into many documents.
- Record the date and owner, and review diagrams whenever the thing they show changes. A picture that disagrees with the system is a source of stale documentation, and is often more misleading than none.
- Keep editable sources, not only exported images.
A simple checklist
- Does it answer one clear question?
- Is it at one level of detail?
- Can a reader tell what each box, line and arrow means?
- Is the flow direction obvious and the layout tidy?
- Does it have a title, a date and an owner?
- Has someone else read it and understood it?
A clear diagram is rarely the most detailed one. It is usually the one where the author decided what to leave out.