TL;DR

• A process illustration works when a reader can follow it without the surrounding text: one direction of flow, one shape per step type, and no more than seven steps.
• Four shapes carry almost every process diagram — a stadium for start and end, a rectangle for a task, a diamond for a decision, an arrow for direction.
• Split anything longer than seven steps into two linked diagrams. Comprehension drops off well before the process itself gets complicated.
• Ship process diagrams as SVG so the labels stay sharp when someone zooms in on a phone.

A process illustration has one job: let someone understand a workflow faster than reading the paragraph that describes it. If the diagram needs the paragraph, it has failed.

Most workflow diagrams fail for the same three reasons — too many steps, inconsistent shapes, and arrows that cross. All three are avoidable before you draw anything.

Here is the five-step method, the shape vocabulary it depends on, and the layout choice that does most of the work.

The four shapes that carry every process diagram

These four are near-universal conventions. Using them means your reader spends attention on the process rather than on decoding your notation.

Keep them flat and unadorned. Diagram shapes are the clearest case for the flat style's discipline — solid fills, one stroke weight, no gradients — set out in how to create flat illustrations.

Five steps to build one

1. Write the steps as verbs first

Before opening any tool, list the process as short verb phrases: "submit request", "review budget", "approve", "notify requester".

If a step will not compress into two or three words, it is probably two steps wearing a trenchcoat. Split it.

2. Fix the start and the end

Name the single trigger that begins the process and every state that ends it, including the unhappy ones — rejected, cancelled, timed out.

Diagrams that only show the successful path are the most common form of workflow fiction.

3. Choose a layout that matches the flow

• Linear chain — a fixed sequence with no branching. The default, and correct more often than people expect.
• Circular loop — anything that repeats: review cycles, sprints, retention programmes.
• Branching tree — decision-heavy routing where paths genuinely diverge.
• Swimlanes — when the point is who owns each step rather than what happens next.

Drawing a repeating process as a straight line is the single most misleading choice in this list. It hides the loop, which is usually the thing worth showing.

For processes that move through physical space or system layers, an isometric projection shows three sides at once and stays measurable, which a flat box diagram cannot do.

4. Label at two levels

Give every box a two-or-three-word verb label, and put the detail in a caption or legend underneath rather than inside the shape.

Boxes sized to fit their text produce ragged, unbalanced diagrams. Keep the boxes uniform and let the labels stay short.

5. Test it without the text

Blur the labels, or show it to someone unfamiliar with the process, and ask them to describe what happens. If they cannot trace the path, the structure is wrong and no amount of styling will rescue it.

This is the same squint test that governs any illustration — we cover the wider version in the six-step illustration workflow, where you thumbnail the composition six times before committing to one.

Keep it under seven steps

Seven is a practical ceiling, not a law. Past it, readers stop tracing the path and start skimming shapes.

• Collapse adjacent steps owned by the same person into one box.
• Push exceptions out into a second diagram rather than branching four ways.
• Split by phase — an overview diagram of three phases, then one detailed diagram per phase.

Use colour to carry meaning, not decoration

Most process diagrams are over-coloured. Every box a different shade tells the reader that the colour means something, and then it turns out it does not.

A three-tier system covers almost every case:

• One neutral — grey or off-white for ordinary steps, which is most of the diagram.
• One accent — reserved for the critical path, the bottleneck, or whatever the diagram exists to draw attention to.
• One muted warning tone — for failure and exception states only.

If a reader has to consult a legend to know what a colour means, the colour is doing too much work. Shape carries the grammar; colour carries the emphasis.

Check the diagram in greyscale before shipping it. Anything that stops making sense without hue will also stop making sense for a colour-blind reader or on a black-and-white printout.

Five mistakes that make a workflow unreadable

• Crossing connector lines. Almost always a layout problem, not an unavoidable one. Reorder the boxes until the lines untangle.
• Decision branches that vanish. Every diamond needs both paths resolved — rejoining the main flow or reaching a genuine end state.
• Boxes sized to their text. Uniform boxes with short labels; ragged boxes signal that the labels are too long.
• Mixed flow directions. One diagram, one reading direction. An arrow doubling back should be an explicit loop, not a shortcut.
• Unlabelled arrows out of a decision. If a diamond has two exits, both need their condition named.
• Implied parallelism. Two boxes drawn side by side read as simultaneous. If they actually happen in sequence, stack them.

Most of these come from drawing the diagram while still working out the process. Settle the logic in a list first, then draw it once.

Exporting a diagram that stays readable

Process illustrations are the worst possible candidate for a low-resolution raster export, because the failure mode is unreadable labels rather than a slightly soft image.

• SVG — the default for web. Text stays crisp at any zoom level and the file stays small. Building the diagram as real vector shapes is covered in how to make vector illustration files.
• PDF — for anything printed or embedded in a deck.
• PNG at 2× dimensions — only where SVG is not supported, such as some email clients.

File weight is worth caring about here: images account for roughly 50% of a typical webpage's total weight, which we break down in SVG vs PNG for web illustrations.

Add data once the structure works

A process diagram becomes an argument rather than a description the moment you attach numbers to it. Only do this after the layout is settled.

• Cycle time per step — how long the work itself takes.
• Wait time between steps — usually the larger number, and usually the one nobody has measured.
• Volume through each branch — what percentage actually takes the exception path.

Put these in small labels beside the boxes rather than inside them. Wait time in particular tends to reframe the conversation, because slow processes are far more often queueing problems than working ones.

Where Illustrations AI fits a diagram

Worth being straight about this one: a generator is the wrong tool for the diagram itself. Boxes need to sit at exact coordinates and labels need to be readable text, and no image model does either reliably.

What it is good for is everything around the diagram:

• The section or hero illustration that introduces the process before the diagram explains it.
• Spot icons for each stage, generated in one style so the set matches.
• The empty and error states the process produces — the paths people forget to design for.

Generate those in one style so the whole page reads as a system, then build the diagram itself in Figma. Each option takes under 20 seconds and carries full commercial rights, so the supporting art costs a fraction of the diagramming time.

Draw the process you actually run

Map the real workflow, including the rejected path and the step everyone skips. A diagram of the idealised process is decoration; a diagram of the actual one is a tool.

Write the verbs, fix the endpoints, pick the layout, label short, then test it blurred.

Generate the visuals around your diagram free — under 20 seconds per option, full commercial rights, no credit card required.