Flowcharts 101: How to Read and Draw Them From Scratch

What Is a Flowchart?

A flowchart is a picture of a process. It takes something that usually lives as words or code or a string of if-then statements in someone's head and lays it out visually — a sequence of shapes connected by arrows — so that a person can read the whole thing in seconds. Flowcharts are one of the oldest diagram types in computing (industrial engineers were drawing them before electronic computers existed), and they have survived because they are the closest thing the world has to a universal language for "how things happen".

A complete flowchart answers three questions for a reader: where does this start?, what happens at each step?, and where does it end? The shapes change meaning, the arrows show the direction of flow, and the whole thing reads from top to bottom or left to right like any other document.

This article teaches you to read and draw flowcharts from scratch. We'll cover the five shapes every flowchart uses, the rules for wiring them together correctly, two worked examples, and the mistakes beginners always make. By the end you'll be able to turn any process — from your morning routine to a user-login flow — into a clean, publishable flowchart.

Why Flowcharts Are Worth Knowing

Flowcharts solve a specific problem that plain text can't: they let a reader see every branch of a process at the same time. When you describe "the checkout flow" in a paragraph, the reader has to hold all the conditions in their head — "if the coupon is valid… if the card declines… if the address is international…" A flowchart puts every branch on the page at once. The reader sees all the paths together and understands the whole shape in a single glance.

Three situations where flowcharts are the right tool:

• Explaining a process to a non-technical audience. Managers, designers, customer-support teams — anyone who does not read code — will parse a flowchart in seconds where a code snippet would stop them cold.
• Planning before you write code. Every non-trivial algorithm is easier to design on paper than in your editor. Drawing the flowchart surfaces the edge cases you'd otherwise forget.
• Debugging a gnarly "why did this happen?" Walking through a flowchart with a real input is often faster than stepping through a debugger, because you can see the whole graph at once.

They're also easy. There are only five shapes to memorize, and you already know three of them.

The Five Core Shapes

Every flowchart is made from a small vocabulary of shapes, each with a specific job. Learn these five and you can read any flowchart, anywhere.

A quick guide to each:

• Terminator (oval or pill): marks where the flow begins and where it ends. Every flowchart has exactly one Start and at least one End. Don't skip the terminator — readers need to know where to put their finger first.
• Process (rectangle): one action the system performs. Write it as a short imperative verb phrase: "Save the file", "Charge the card", "Send confirmation email". One box, one action. If a process box has more than one verb in it, break it into two boxes.
• Decision (diamond): a question with a yes/no answer. The decision always has two (or more) arrows coming out, and each one is labelled with the answer it represents. Never leave a decision arrow unlabelled — the reader has no way to guess which branch is which.
• Input/Output (parallelogram): data flows in (a user fills a form, a file is read) or out (a report is printed, a message is sent). Use this shape when data crosses the boundary between the system and something outside it — a user, another system, a disk, a network.
• Connector (small labelled circle): a shortcut between two places in the diagram. If an arrow would have to cross the whole page to reach its destination, break it into two connector circles with the same letter (e.g., A → A). Use connectors sparingly — overusing them makes the diagram hard to follow.

One more thing counts as a shape: the arrow. Arrows carry the flow from one box to the next. An arrow has a direction, and flowcharts that don't read top-to-bottom or left-to-right almost always have an unclear arrow somewhere.

The Four Rules Every Flowchart Follows

You can break these rules, but the diagram becomes harder to read each time you do. Think of them as defaults — follow them unless you have a specific reason.

1. Exactly one Start. If you draw two Start ovals, a reader doesn't know where to begin. Always merge beginnings into one entry point, even if the process has multiple triggers (list the triggers as text outside the box).
2. At least one End. A flowchart without an End leaves the reader hanging. If the process truly loops forever (a server event loop, a polling job), mark that explicitly with a labelled loop back to the Start.
3. Every process box has one arrow in and one arrow out. If a box has two arrows coming out that aren't a decision, it means the action has an implicit branch — pull it out into a diamond.
4. Every decision has two labelled arrows out. "Yes" and "No", "Pass" and "Fail", "< 18" and "≥ 18" — whatever the two (or three, or four) answers are, each outgoing arrow needs a label. Unlabelled decisions are the number-one beginner mistake.

The Decision Diamond, Up Close

The diamond is the one shape that makes flowcharts more powerful than a linear bullet list. It's worth understanding well.

A few details that matter in practice:

• Phrase the question with a clear yes/no answer. "Payment succeeded?" is a good decision label. "Payment status" is not — it leaves the reader guessing what the branches mean.
• More than two branches are allowed. If an answer has three cases — "small", "medium", "large" — the diamond can have three outgoing arrows, each labelled. Don't chain diamonds ("Is it small? If no, is it medium?") unless the actual logic really does check one after the other.
• Arrows can merge back together. After both branches of a decision finish their work, they often continue with the same next step. Draw both arrows into the same box. The diamond is a fork; nothing says the fork has to stay forked.

Your First Flowchart: Making Coffee

Let's draw something simple before anything complicated. The process: you wake up, you decide if you want coffee, and if you do, you make it. Then you get ready for the day.

Step by step:

1. Start.
2. Wake up. (process)
3. Want coffee? (decision)
4. If yes: put the kettle on. Wait for it. Pour the water. Drink. If no: skip those steps.
5. Get dressed. (process)
6. End.

A couple of things to notice in this diagram:

• There's exactly one Start and exactly one End. Every path through the diagram begins and ends at the same pair of ovals.
• The decision diamond has two labelled arrows out. "yes" goes to the coffee subroutine; "no" skips it.
• The "no" branch takes a detour around the coffee steps but ends up in the same "Get dressed" box as the "yes" branch. That's the rejoining pattern you'll use constantly.
• The flow reads top-to-bottom. Always. Even when a branch loops sideways, it eventually points downward again.

Your Second Flowchart: A Login Flow (With a Loop)

Real processes often include loops — steps that repeat until some condition is satisfied. A classic example is a login form: if the user enters the wrong password, they're sent back to try again, not kicked out.

Two things are new in this diagram:

• The parallelogram. "Read email & password" is input — data arriving from outside the system (the user typing into a form). Any time data crosses the system's boundary, the parallelogram is the correct shape.
• The loop. The "no" branch doesn't lead to an End. Instead, an arrow curls back up to the input step, letting the user retry. Loops are a flowchart's way of saying "repeat this step until…" — they are how you express things like retries, polling, and "while" loops.

A good loop always has a way out. In this example, the loop ends as soon as the user enters valid credentials. A loop with no way out is an infinite loop — sometimes intentional (a server's main event loop) but usually a bug the diagram helped you notice.

Swimlanes: Who Does What

When a process involves multiple actors — a customer and a cashier, a frontend and a backend, a user and an admin — you can split the flowchart into vertical (or horizontal) swimlanes, one per actor. Each shape sits in the lane of whoever is responsible for that step. Arrows that cross lane boundaries show hand-offs between actors.

Swimlanes are a surprisingly powerful addition to your toolkit. They turn a flat flowchart into a responsibility map: one glance tells you whether a given step is the customer's job or the system's, whether the user is waiting on something, or whether an automated task is blocking a human. If your flowchart has more than one actor, use swimlanes.

Common Beginner Mistakes

Six mistakes account for almost every unreadable flowchart in the world. Watch for them in your own work.

• Unlabelled decision branches. The single most common mistake. Every arrow leaving a diamond needs a label — otherwise the reader has to guess which branch is which, and they will guess wrong about half the time.
• Multiple Starts. A flowchart with two Start ovals confuses every reader immediately. Even if the process can be triggered multiple ways, pick one Start and list the trigger conditions as a note.
• Arrows crossing each other. Crossed arrows are almost always a layout problem. Rearrange the boxes or use connector circles to avoid them — the reader's eye gets lost trying to trace overlapping lines.
• Process boxes that contain multiple actions. "Validate the cart and calculate shipping and charge the card" should be three separate boxes. If any of those three can fail independently, you need to see them separately.
• Forgetting to rejoin branches. After a decision, both branches often continue with the same next step. Draw both arrows into the same box instead of duplicating the subsequent boxes in each branch.
• Too much detail. A flowchart that shows every line of code becomes a wall of boxes and is harder to read than the code itself. Draw the process, not the implementation. If a box says "validate the cart", that's enough — the reader doesn't need to see the twenty individual validation rules.

Where to Go Next

Flowcharts are the entry-level diagram for a reason: once you can draw one cleanly, you can apply the same thinking to half a dozen more specialised diagram types. Three natural next steps:

• Try a data-flow diagram (DFD). A close cousin of the flowchart, focused on where data moves rather than what actions happen. Useful for designing systems that pass records between components.
• Try an activity diagram. UML's version of a flowchart, with a few extra primitives — parallel bars for concurrent work, merge nodes for joining threads. Worth knowing if you work around software architects.
• Turn a real process at your job into a flowchart. The one where everyone keeps asking "wait, what happens if X?" will benefit the most. Half the value is in the drawing; the other half is in the conversations the drawing starts.

A Note on Tools

Every idea in this article is about the notation — the shapes and the rules — not about any particular tool. You can draw a perfectly good flowchart on a whiteboard, on paper, in Figma, Miro, Visio, Google Drawings, or anywhere else you can make a rectangle and a line. If you'd like a tool with all the flowchart shapes already in its sidebar, arrow-snapping that keeps your flow clean, and a Mermaid importer for turning a rough text sketch into a proper diagram, CorriDraw — the tool you're reading this on — is one option. But the ideas transfer. Pick whatever draws cleanly; the notation is the same everywhere.