Flowchart: What It Is, Which Shapes to Use, and How to Build One

A flowchart is a picture of a decision. Not of a process — a numbered list does processes perfectly well — but of the points where the next step depends on an answer. Everything below assumes that distinction, because it is the one that decides whether your diagram is worth drawing.

Live interactive diagramUse the player controls to follow the steps

5 Whys on the outage — chain to countermeasurePlaying silently in this guideWatch with narrationOpen in editor

What a flowchart actually is

Formally: a directed graph where nodes are actions or decisions and edges are transitions. Practically: a map of every path work can take, drawn so someone who was not in the room can follow it without you.

The notation dates to 1921, when Frank and Lillian Gilbreth presented the "process chart" to the American Society of Mechanical Engineers. ANSI standardised the shapes in the 1960s, ISO 5807 followed in 1985, and that vocabulary is still what people recognise today. It has survived a century because it encodes one thing extremely well: branching.

If your process has no branches, you do not need a flowchart. You need a numbered list, and it will be read more often.

The shapes, and what each one promises

Shape is meaning, not decoration. A reader who knows the notation reads the geometry before the words, so a wrong shape actively misleads. Six carry almost every real diagram:

• Stadium (rounded) — Start / End. Exactly one start. Every path must reach an end; a branch that stops mid-air is the commonest real defect, and it is always the path nobody wanted to think about.
• Rectangle — Process. Something happens. One entry, one exit. If a rectangle has two exits it is secretly a decision.
• Diamond — Decision. A question with mutually exclusive answers, every one of them labelled. A diamond with a single exit is not a decision, it is a step wearing the wrong shape.
• Parallelogram — Input / Output. Data crossing the boundary: a form submitted, a report produced.
• Cylinder — Data store. A database or file the flow reads or writes.
• Double-struck rectangle — Predefined process. A subprocess defined elsewhere. This is your pressure valve: when a chart passes roughly twenty shapes, lift a section out behind one of these and give it its own diagram.

Diagramium's flowchart palette also carries document, delay, manual operation, manual input, display, preparation and off-page connector. Use them when they say something true. Three shapes used consistently beat nine used loosely — an unfamiliar shape makes a reader stop and decode instead of read.

Why draw one at all

Three returns, in the order they usually arrive:

• It exposes the branch nobody had decided. Most processes are documented for the happy path and improvised for everything else. The act of drawing forces the question "and if they say no?" — and that question, asked early, is the whole value.
• It replaces repeated explanation. A process living in one person's head costs that person a conversation every time someone new needs it.
• It makes disagreement visible. Two people describing the same process in prose can sound identical and mean different things. Drawn, the difference is a line in the wrong place, and you can point at it.

When to reach for one — and when not to

Use a flowchart when the answer to "what happens next?" is it depends. Reach for something else when it is not:

• The argument is about ownership, not logic → a swimlane. See clarifying ownership and handoffs.
• Order and timing between systems matter → a sequence diagram.
• You are measuring an operation end to end → a process map. See mapping a business process.
• Every branch is a question with fixed answers and no loops → a decision tree.
• The thing has states rather than steps — draft, published, archived → a state machine.

Who actually draws these

• Business analysts — current-state documentation before a system change, where the rework loops are the finding.
• Engineers — algorithms, retry and error handling, and the exact path of a bug during a postmortem.
• Operations and compliance — approval routes that must be auditable, where an unlabelled branch is a finding.
• Product and support — triage and escalation rules that need to be identical across a team.
• Educators and adult learners — any explanation with a "if this, then that" in it.

Flowcharts you can open and edit

Real templates from the gallery, across HR, retail, health, civic process and engineering. Open one, rename the boxes, and you have your own — no account, and it saves to your device rather than ours.

Building one in Diagramium

1. Start from a template, not a blank canvas. Most processes are a variant of one already drawn; renaming is faster than inventing.
2. Lay the happy path top to bottom first. No branches yet. If the spine is not clear, no amount of branch detail rescues it.
3. Add decisions, and label every exit. Drag from a shape's port to connect; connectors route around other shapes on their own, so you are not nudging elbows by hand.
4. Press ⌘K to insert without hunting — shapes, icons and components from one search box.
5. Put the reasoning in a step note. Notes are per step and travel inside the document, so the "why" is not stranded in a chat thread.
6. Press Present. The chart reveals itself one shape at a time. This is the fastest audit of your own logic there is: the step you cannot narrate is the step you have not thought through.
7. Export for the audience you have — PNG or SVG for a document, GIF or video for a channel where nobody clicks links, or the project file to hand someone the editable original.

Design decisions that separate a good chart from a wall of boxes

• One direction, chosen once. Top-to-bottom or left-to-right. Mixing them makes readers hunt for the thread.
• Colour carries one meaning at a time. Exception paths or owning team — never both in one chart.
• Break at about twenty shapes. Past that, comprehension falls off a cliff. Lift a section behind a predefined-process shape.
• Labels under about six words. Long text forces wide boxes, wide boxes force long connectors, and the layout unravels.
• Verb-first step text. "Send the contract", not "Contract". A noun hides who does the work.
• Let the rejection paths be ugly. The instinct is to tidy them away; they are the part the reader needs most.

Common mistakes

• The diamond with one exit. If there is no second branch it is not a decision, it is a step.
• Boxes that are really documents. “Policy” is not a step. Either it is an action, or it belongs in a note.
• Silent failure paths. Every real process has a rejection, a timeout or an error. A chart with only the happy path is wrong in its first week of use.
• Modelling the org chart instead of the process. If you find yourself drawing departments, you want a swimlane.
• Detail nobody asked for. Field-level validation belongs in a spec, not in a chart someone reads in thirty seconds.
• Loops with no exit condition. A rework arrow with no stated way out promises an infinite process.

The checklist

Run this before you share it.

1. Exactly one start; every path reaches an explicit end.
2. Every decision has labelled branches covering every real answer.
3. Shapes are used consistently, and there are no more kinds than you need.
4. Steps read verb-first and name the actor where it is ambiguous.
5. Rework loops state how they terminate.
6. Under about twenty shapes, or split behind a predefined-process shape.
7. No connector crosses another where a re-route would avoid it.
8. You can narrate every step aloud in Present without stopping.
9. Exported in the format the audience will actually open.