How to Create a Flowchart: Step-by-Step Guide with Examples

To create a flowchart, write the process out as a plain list of steps, mark the points where the answer changes what happens next, then convert each line into a shape — a rounded box for the start and the end, a rectangle for an action, a diamond for a decision — and join them with arrows in the direction the work actually travels. Label every line leaving a diamond. That last step is what turns a drawing into a chart someone who was not in the room can follow.

Live interactive diagramUse the player controls to follow the steps

Employee onboardingPlaying silently in this guideWatch with narrationOpen in editor

What this diagram shows

1. The chart starts at a rounded terminator: Offer accepted.
2. Two sequential actions follow — HR sends the welcome packet, then IT provisions accounts and equipment.
3. A diamond asks: remote or on-site? This is the only branch in the chart.
4. The remote branch ships equipment and runs a virtual orientation; the on-site branch sets up a desk and runs an in-person orientation.
5. Both branches rejoin at a manager 1:1 and team introduction.
6. The chart ends at a second terminator: a 30-day check-in is scheduled.

When a flowchart is the right choice

A flowchart is a picture of branching. If your process is a straight line of five steps, a numbered list beats it — shorter to write, easier to update, and it survives being pasted into an email. The moment the next step depends on an answer, a flowchart starts paying for itself.

Two situations where it is clearly the right tool:

• A decision flow. Onboarding that differs for remote and on-site hires; a release that either ramps or rolls back. The value is in showing both futures on one page.
• A process with gates. A month-end close, an approval that can be rejected at three points. People need to see where a request can stop, and what happens when it does.

If you can renumber the steps and nothing breaks, you have a list, not a flowchart.

How to create a flowchart in seven steps

1. Name the trigger and the finish. "Starts when a candidate accepts; ends when they pass the 30-day check-in." Without both, the chart grows sideways forever and no reviewer can tell you when it is done.
2. List the steps in plain sentences. No shapes yet, no tool yet. This is the stage where you discover the process is not what anyone thought it was, and it is much cheaper to discover it in a list than on a canvas.
3. Mark every point where the answer changes what happens next. Those lines become diamonds. Everything else is a rectangle. If nothing in your list qualifies, stop — you have a checklist, and drawing it will not add anything.
4. Lay out the happy path in one straight line. Top to bottom, or left to right; pick one and hold it for the whole chart. A reader should be able to follow the normal case without ever leaving the spine.
5. Hang the branches off that spine. Exceptions go to one side. When the exceptional path is drawn as prominently as the normal one, the chart misleads people about what usually happens.
6. Label every branch. Yes / no, approved / rejected, in stock / backordered. An unlabelled fork asks the reader to guess, and they will guess wrong about half the time.
7. Trace every path to an end. A step with no way out is a bug in the process, not just in the picture — which is exactly the kind of thing drawing it is supposed to surface.

Steps one to three are the work. Four to seven are transcription, and they go quickly once the list is honest.

The symbols you actually need

The shapes were standardised by ANSI in the 1960s and internationally in ISO 5807:1985, which is still the vocabulary readers recognise. Four of them carry almost every chart:

• Rounded rectangle (terminator) — where the process starts and ends.
• Rectangle (process) — an action. Label it verb-first: Send the offer, not Offer.
• Diamond (decision) — a question, with one labelled line leaving it per answer.
• Parallelogram (input/output) — data going in or a document coming out, when that is genuinely part of the story.

The standard covers a good deal more, and the editor's shapes panel carries them — document, predefined process, preparation, manual input, manual operation, delay, display, loop limit, off-page connector. You rarely need them, and reaching for one you cannot explain costs more clarity than it buys. For the full set and what each one means, see the guide to flowchart symbols and their meanings.

A worked example: employee onboarding

The diagram at the top of this page is a real one, and it is worth walking through because it is almost the minimum viable flowchart — eight shapes, one decision.

It opens on Offer accepted and runs two actions that always happen in the same order: HR sends the welcome packet, then IT provisions accounts and equipment. Then the single diamond: Remote or on-site? The remote branch ships equipment and books a virtual orientation; the on-site branch sets up a desk and books an in-person one. Both rejoin at the manager 1:1, and the chart terminates on a scheduled 30-day check-in.

What makes it worth drawing is precisely that fork. Written as prose, the two paths become two paragraphs that drift apart the first time one of them changes. Drawn once, with both futures visible on the same page, nobody has to maintain two documents — and the rejoin makes it obvious that the difference is temporary rather than a permanently separate process.

Examples you can open and edit

These are editable diagrams, not screenshots. Open one and move a branch to see the connectors re-route around the shapes.

Building one in Diagramium

Open the flowchart editor and work straight on the canvas.

1. Drag a shape in from the left panel, or click it to drop one on the canvas.
2. Drag from a port on a shape's edge to another shape to connect them. Connectors route around shapes that are in the way rather than cutting through them.
3. Type to label. With a shape selected, just start typing — the label editor opens on that keystroke.
4. Label the branches by selecting a connector and setting its label in the inspector.
5. Press Present to reveal the chart one step at a time, which is far easier to talk over than a finished page.

The flowchart editor is canvas-only — there is no text syntax for it, and the Text tab is hidden rather than offering something that would not work. Text input is available for sequence diagrams, org charts, mind maps and sitemaps.

When it is finished, Present plays it step by step with a note per step; exports are PNG, SVG and PDF without an account, and animated SVG, GIF and video with a free one.

Best practices

• One altitude per chart. "Recruit the candidate" next to "Click Save" makes a chart feel arbitrary. Pick a level of detail and push anything finer into a sub-process.
• Verb-first labels, under six words. A shape is a caption, not a sentence.
• Keep the happy path straight. If a reader has to follow a branch to understand the normal case, the layout is wrong.
• Two exits from a diamond, usually. Three is fine when the answers are genuinely distinct; five means the question is really several questions.
• Draw what happens, not what should happen. If you want to propose an improvement, draw the current process and the proposed one as two charts. Merging them produces a document nobody trusts.
• Re-read it as a stranger. Every diamond labelled, every path ending, every shape earning its place.

Common mistakes

• Unlabelled decision branches. Fix this first; it is the single most common defect in charts that reach review, and nothing else matters as much.
• Every shape a rectangle. If decisions are not diamonds, the reader has to read every label to find where the process forks.
• Arrows in every direction. Backward arrows should be rare and meaningful — a rework loop, not a layout accident.
• A path with no ending. Trace each branch to a terminator before calling it done.
• Exotic symbols used decoratively. A cylinder that does not mean "stored data" teaches the reader that the shapes are meaningless, and from then on they read none of them.
• Charting a process nobody agrees on. The diagram will be argued with rather than used. Settle the disagreement in the list, at step two.

Related diagram types

• If the interesting part is which team does each step, use a swimlane diagram — the same flow, split into lanes by owner.
• If you are describing an end-to-end business workflow rather than one procedure, see process flow diagrams, and flowchart versus process map for which of the two you need.
• If several participants exchange messages in order, draw a sequence diagram instead.
• If one object moves between states, a state machine is more precise.
• If you need formal, executable process semantics — typed events, gateways, message flows — the notation to reach for is BPMN, specified by the OMG as BPMN 2.0.2.

In short

A flowchart is worth the effort exactly when a process branches. Get the list of steps right first, keep the normal path straight, label every fork, and make sure every path ends. Seven steps, and the hardest three happen before you open an editor.

Questions people actually ask

What are the seven steps to create a flowchart?

Name the trigger and the finish; list the steps in plain sentences; mark the decision points; lay the happy path out in a straight line; hang the branches off it; label every branch; and check that every path reaches an end.

Which shape do I use for a decision?

A diamond, with one labelled line leaving it per answer. Two answers is typical. Three is fine if they are genuinely distinct; more than that usually means the diamond is hiding several separate questions.

Should a flowchart run top to bottom or left to right?

Either, as long as you are consistent within one chart. Top to bottom suits a procedure someone follows in order; left to right suits a process with distinct stages.

How detailed should a flowchart be?

Detailed enough that someone unfamiliar could follow it, and no more. If a step needs branches of its own, give it a sub-process rather than inflating the parent chart.

What is the difference between a flowchart and a process map?

Scale and audience. A flowchart shows the logic of one procedure including its branches; a process map takes a wider view of an end-to-end business process, its stages and the handoffs between them. Diagramium has a separate process map editor for the second, and there is a full comparison in flowchart vs process map.

Can I create a flowchart from text in Diagramium?

No — the flowchart editor is canvas-based. Text input works for sequence diagrams, org charts, mind maps and sitemaps.