Do decision points have to be diamonds?

The diamond is the conventional shape and the reason is pure legibility: anyone reading the chart immediately knows a branch starts here. For a private sketch a rectangle with a note works, but for anything shared, keep the diamond.

How many nodes can one flowchart hold?

There is no hard limit, but readability degrades as you add nodes. A practical rule is no more than about fifteen nodes on one view; beyond that, split into a main diagram plus sub-process diagrams that expand individual complex nodes.

What is the difference between a flowchart and a swimlane diagram?

A flowchart tracks sequence only. A swimlane diagram adds ownership: each lane belongs to a role or system, and where a node sits shows who is responsible. When handoffs across teams are the real problem, swimlanes communicate that better.

What if I find a logic gap after drawing?

Rerun the layout pass and focus on whether the decision branches cover the exceptions. A second effective check is to walk an uninvolved colleague through it and have them repeat the process back — wherever they hesitate is where the diagram is still ambiguous.

How to Draw a Flowchart: Six Steps from Blank Page to Final Diagram

A flowchart answers one concrete question: what are the steps, who does each one, and which path is taken under which condition. It does not need to be pretty — it needs to leave nobody asking "and then what?". This is the sequence we use for scoping requirements, writing proposals, and handing work over.

Decide what question the diagram answers

Before drawing anything, write one sentence: what should this diagram answer? Which steps does an order go through, how do we debug an outage, or how many days can an approval take? The answer sets the resolution. The same process becomes a three-box summary for a manager and a thirty-box specification for an engineer.

For decision makers: keep it under seven nodes, keep only the real gates
For builders: every action must map to a specific person or system
For your own thinking: allow a messy first pass, dump every node then tidy

Fix both ends first: start and end

The skeleton of any flowchart is its endpoints. The start node names the trigger ("user submits the form", "refund request received"); the end node names a concrete final state ("order created", "ticket closed"). Nail both and the middle stops expanding forever.

A common defect is several starts or several ends bundled together. Multiple end nodes are fine when branches genuinely terminate differently, but each one should say which state it is — not a row of identical "End" boxes.

Start nodes hold a trigger, never an action
End nodes hold a resulting state, not the word "done"
Differentiate terminator shapes from the action rectangles

List the actions in order, ignore layout

Turn the middle into a plain list, each item starting with a verb: collect requirements, check stock, create the order, send the notification. Do not position anything yet. Layout comes last; doing it early means burning time nudging arrows instead of thinking about logic.

Write each action as verb plus object, avoid empty words like "handle"
One action per box — split anything that is really two steps
Mark which steps are automated and which need a human
Note steps that could run in parallel, but do not draw them yet

Add decision branches and label the arrows

Once the linear pass is done, find the places where the path can diverge — those are the diamonds. The condition lives inside the diamond, and the outgoing arrows must say what each branch means. The most common mistake is labelling arrows "yes" and "no" without stating what the question was.

Label outgoing arrows as condition plus outcome, for example "stock available → create order"
A decision needs at least two outgoing arrows; one arrow means the diamond is redundant
Loops such as "retry on failure" must return to a specific node, never float loose

Clean up the layout so it reads top to bottom

Only now arrange things. Keep the happy path on one straight line and push branches to the sides instead of letting them loop back across the diagram. If arrows cross repeatedly, splitting into a main diagram plus a sub-process diagram usually beats forcing everything onto one sheet.

Pick one direction — top to bottom or left to right — and stay with it
Align nodes of the same level; even spacing visually signals shared depth
One colour for the happy path, another for exception branches
Annotate key nodes with duration, owner, or system name

If the order still looks scrambled, drag nodes into roughly the right place in the editor and let the connector route orthogonally for you — far less work than hand-placing every arrow.

Exporting and collaborating

A flowchart rarely lives in one place. It gets embedded in docs as a raster image, dropped into slides, and handed to a colleague who needs to keep editing. Keep one editable source file and export from it each time, rather than maintaining two copies that inevitably drift apart.

Documents and chat: a raster export is universally viewable
Anything that will be enlarged: a vector export stays sharp
Handing over to a colleague: export a format that can be edited again

Frequently asked questions

Do decision points have to be diamonds?: The diamond is the conventional shape and the reason is pure legibility: anyone reading the chart immediately knows a branch starts here. For a private sketch a rectangle with a note works, but for anything shared, keep the diamond.
How many nodes can one flowchart hold?: There is no hard limit, but readability degrades as you add nodes. A practical rule is no more than about fifteen nodes on one view; beyond that, split into a main diagram plus sub-process diagrams that expand individual complex nodes.
What is the difference between a flowchart and a swimlane diagram?: A flowchart tracks sequence only. A swimlane diagram adds ownership: each lane belongs to a role or system, and where a node sits shows who is responsible. When handoffs across teams are the real problem, swimlanes communicate that better.
What if I find a logic gap after drawing?: Rerun the layout pass and focus on whether the decision branches cover the exceptions. A second effective check is to walk an uninvolved colleague through it and have them repeat the process back — wherever they hesitate is where the diagram is still ambiguous.