Workflow Diagram Icons: Explain Steps, Decisions and Handoffs

Write the process before arranging the artwork

Describe the main route as short verb phrases: Create draft, Submit for review, Review draft and Publish approved version. Then list the exceptions separately. A reviewer may request changes; an author may withdraw a draft; a publishing step may fail. This written outline makes missing transitions easier to spot than a collection of attractive cards does.

Assign each step an owner and an outcome. Submit for review belongs to the author and produces a pending review. Review draft belongs to the reviewer and produces an approval or a request for changes. Keep these definitions beside the diagram while designing it. If two nodes have the same title but different owners or outcomes, clarify their wording before searching for two different icons.

Use icons to identify nodes, not to invent notation

Choose a small vocabulary: a document for the draft, a person for the reviewer and a publication symbol for the released result. Keep step labels in text. Use a distinct decision node for the approval question instead of adding an unexplained check to one connector. Label the outgoing branches Approved and Changes requested so the route does not depend on the viewer decoding a shape.

The Mermaid flowchart documentation distinguishes nodes, edges, directions and labeled connections. You do not need Mermaid to apply that separation: the process structure should remain legible when the decorative artwork is removed. If your organization already uses a formal modeling notation, follow its documented conventions instead of introducing a competing icon vocabulary for gateways and events.

Make exceptions and handoffs visible

Lay out the main route in a single reading direction. Add the request-for-changes loop with enough space to see where it returns. If a connector crosses several cards, revise the layout before adding more styling. A larger arrowhead does not repair an ambiguous endpoint. Keep labels beside the connection they describe, not floating midway between several possible routes.

Show an ownership change through an explicit lane, heading or short owner label. For example, group author steps separately from reviewer steps, while keeping the same icon size in both groups. Add an exception only when it helps explain the intended process. A diagram for onboarding a new colleague may need the common correction loop; an implementation specification may also need timeout and retry behavior. State which level of detail the diagram covers.

Keep a text equivalent with the diagram

For a web diagram, provide a nearby explanation of its meaningful sequence and branches. W3C's complex-images tutorial recommends a complete text equivalent for information-rich images such as diagrams. A short label like Approval workflow identifies the picture but does not explain its decisions or loops.

Use the written process from the first step as the starting point. Update it when the diagram changes, and include the same ownership names and outcomes. For a presentation, make sure the process can also be explained coherently in the delivered material. Do not assume that the visual proximity of two icons communicates a handoff to everyone, or that an exported diagram automatically preserves an accessible reading order.

Test the route before polishing the style

Ask a reviewer to trace one successful submission and one returned draft without help. Then choose a coherent set from Tabler, Lucide or Iconoir. Match the icon treatment to the diagram's density. Use stronger color for a documented state or emphasis, not as decoration on every node. Keep the source diagram editable so labels and routes can evolve together.

• Every step has a verb, an owner and an understandable outcome.
• Decision branches are labeled where the route splits.
• Loops return to a clear destination without hidden crossings.
• The diagram and its text explanation describe the same process.
• Icons remain useful cues when viewed at the final delivery size.