How to make a flowchart: a practical guide

A flowchart is a picture of a process: what happens first, what happens next, and where the path splits. Done well, it lets someone understand in thirty seconds what would take a page of text to explain. Done badly, it’s a tangle of boxes nobody wants to read.

This guide walks through a method that works for almost any process, from onboarding a new customer to a hiring pipeline. You don’t need special software or training. You need a clear start, a clear end and the discipline to keep each box doing one job.

When a flowchart is the right tool

Flowcharts are best for processes that have a sequence and at least one decision. If your process is a straight line with no choices, a numbered list is usually clearer. If it’s mostly about who is responsible for what, a swimlane diagram may serve you better.

A flowchart earns its place when:

• people keep asking “what happens if…?” about a process
• a process has exceptions that are easy to forget
• you’re handing a process to a new team or a new hire
• you need to spot where work gets stuck or repeated

Step 1: Decide the scope

Every useful flowchart answers one question. Before you draw anything, write that question down. For example: “How does a new customer get set up, from the moment they sign up to the moment they complete setup?”

That sentence gives you three things:

1. The start: a new customer signs up.
2. The end: the customer completes setup.
3. What’s out of scope: how the account is billed, for instance.

If you can’t write the question in one sentence, you probably have two flowcharts.

Step 2: List the steps in plain words

Write the process as a list, in the order things happen. Use short phrases that start with a verb:

• Receive the new sign-up
• Send a welcome email
• Check their plan
• Decide whether it’s a team plan
• Book an onboarding call
• Share the setup guide

Don’t worry about branches yet. The goal is to get every step written down. It helps to walk through one real example from start to finish, because real cases surface the steps people forget to mention.

Step 3: Find the decisions

Now look for the points where the path splits. Decisions are usually hiding in words like if, unless, depending on or otherwise. In the example, there’s one: is it a team plan?

Write each decision as a yes/no question. “Check their plan” is a step; “Is it a team plan?” is a decision. Yes/no questions keep the branches simple: two arrows out, each clearly labelled.

If a decision has more than two outcomes, either split it into a chain of yes/no questions or make sure every outcome arrow has a clear label.

Step 4: Use the standard shapes

You only need four shapes for most flowcharts:

Shape	Meaning	Example
Rounded rectangle (oval)	Start or end	A new customer signs up
Rectangle	A step someone does	Send a welcome email
Diamond	A yes/no decision	Is it a team plan?
Arrow	The direction of flow	From one step to the next

Sticking to these four keeps the chart readable by anyone. Extra symbols for documents, databases or manual input exist, but most audiences won’t know them. Use them only if your readers do; flowchart symbols and what they mean covers the full set.

Step 5: Lay it out

Arrange the flow so it reads in one direction, top to bottom or left to right. A few layout rules make a big difference:

• Keep the main path straight. The most common route through the process should run down the middle. Exceptions branch off to the side.
• Avoid crossing lines. If two arrows cross, move a box. Crossings are the main reason flowcharts look confusing.
• Label every branch. Every arrow leaving a diamond needs a label, usually yes and no.
• Join branches back up. If two paths end in the same step, draw both arrows into one box rather than repeating it.

In the onboarding example, the “yes” branch goes left to Book an onboarding call, the “no” branch goes right to Share the setup guide, and both rejoin at Customer completes setup.

Step 6: Write labels people can scan

Inside each box, use three to six words. Start steps with a verb (“Check their plan”, not “Plan checking”). Phrase decisions as questions that end with a question mark.

If a step needs more explanation, put a short note beside the chart or in a linked document. A box that needs a paragraph is usually two steps, or a step that belongs in a different diagram.

Step 7: Check it with a real case

Pick a real example and trace it through the chart with your finger. Then pick an unusual one. Ask:

• Does every path reach an end?
• Is there a step where people actually stop and wait that the chart doesn’t show?
• Would someone new to the process know what to do at each box?

The best check is to hand the flowchart to someone who does the work and ask them where it’s wrong. They will usually find one missing step and one decision that’s more complicated than it looks.

Step 8: Handle loops and waits

Real processes rarely run straight through. A document goes back for changes, a request waits for a missing detail, an approval is refused and resubmitted. These loops are often the most useful part of the chart, because they are where time disappears.

Draw a loop as an arrow that returns to an earlier step, and label it with the condition that sends work back: “Details missing”, “Changes requested”. Route the return arrow around the outside of the main path so it doesn’t cut across other boxes.

Two habits keep loops honest:

• Say where the loop rejoins. Work sent back for changes may restart at the beginning or only at the review step. The arrow should land on the exact box where work resumes.
• Show waits that matter. If a step regularly sits idle for days, such as waiting for a supplier or a signature, give it its own box (“Wait for signed form”). A chart that hides the wait hides the delay people complain about.

If a loop can repeat without limit, ask whether the process needs a stopping rule, such as “After two rejections, escalate to the team lead”.

Common mistakes

Too much on one chart. If your flowchart has more than about 15 boxes, consider splitting it. Show the overview on one chart and detailed sub-processes on others.

Mixing levels of detail. “Onboard the customer” and “Click the invite button” don’t belong on the same chart. Keep every box at roughly the same level.

Unlabelled branches. A diamond with two unlabelled arrows forces the reader to guess.

Dead ends. Every path should reach an end, even if that end is “Hand over to account manager”.

Using flowcharts in presentations and documents

A flowchart in a slide deck has less room than one on a wall, so simplify it further:

• Show only the main path and the one or two decisions that matter for the audience.
• Use the same colour for every step and a contrasting colour for decisions.
• If the process is long, reveal it in stages across a few slides rather than shrinking it to fit one.

If you would rather not build the slide from a blank page, a set of flowchart slide templates gives the main path and its decisions a layout already sized for a screen.

In documents and wikis, place the chart near the text that explains it, and give it a caption that says what question it answers.

Keeping a flowchart current

A flowchart is only useful while it matches how the work is done. Processes drift: a new approval step is added, a tool changes, a team takes over a task.

Give every chart an owner and a date. Put “Owner: Customer success lead. Last checked: March” in a small note at the bottom, so readers know who to ask and how old the picture is. Review it when the process changes, not only on a fixed schedule, and keep the plain-words list from Step 2 beside the chart. Updating a list and redrawing from it is quicker than editing a tangle of boxes.

A quick template to start from

Next time you need a flowchart, start with this outline:

1. Question: what does this chart answer?
2. Start: what triggers the process?
3. End: what does “done” look like?
4. Steps: a verb-first list, in order
5. Decisions: each written as a yes/no question
6. Check: one normal case and one unusual case

With those six things written down, drawing the chart is the easy part. That’s also exactly what you’d describe to DiagramsPro: write the process in plain words, and the layout follows. Once the diagram is ready, you can drop it into a full deck built with Presentations.AI.