A flowchart is a process written down so precisely that a stranger could follow it. That standard, not prettiness, is what you're aiming for. Five symbols, short verb-first steps, labeled exits, and a walk-through test get you there.
| Symbol | Shape | Use for |
|---|---|---|
| Terminator | Rounded rectangle | Start and end points |
| Process | Rectangle | Any action step |
| Decision | Diamond | Yes/no questions |
| Input/Output | Parallelogram | Data in or out (forms, emails, files) |
| Arrow | Directed line | What happens next |
Document, database, delay, and connector symbols exist, and some fields swear by them. For business and product processes, restraint wins: readers already know these five, and every extra shape is another thing to look up.
List the process in plain words, one step per line, start to finish, before you touch any shapes. Then mark up your list: which lines are decisions? Which move data in or out? Where does the process end, and does it end differently for different paths? The list is cheap to fix; the drawing is expensive. Most bad flowcharts were drawn before they were written.
Every diamond gets two labeled exits, and both exits go somewhere real. If you're tempted to write a three-way question ("Gold, Silver, or Platimum tier?"), split it into two diamonds in sequence: "Platinum tier?" then "Gold tier?" Binary questions keep the chart readable and force you to discover what you actually mean. Loops are fine, and retry loops are the heart of many processes, but every loop needs an exit; a reader trapped in your chart is a reader who stops reading.
Type your steps with simple prefixes for decisions and branches, and download the finished SVG.
Open the Flowchart Maker →Take three real cases through the finished chart with your finger: the happy path, the rejection path, and one weird edge case (a refund request for an order from a year ago, a candidate who declines). Every case should arrive at an end node without passing through impossible states. This test catches more logic errors than any style guide.
Flowcharts answer "what happens next." If your real question is "when does each thing happen," you want a Gantt chart; if it's "who reports to whom," an org chart; if it's "what are the parts of this idea," a mind map. Pulling the wrong diagram type is the most common planning mistake after skipping the diagram entirely.
Terminator (rounded rectangle) for start and end, process (rectangle) for actions, decision (diamond) for yes/no questions, input/output (parallelogram) for data entering or leaving, and arrows for direction. Those five handle nearly every business or technical process; document and database symbols are for specialized cases.
A diamond asks one question with labeled exits, usually yes and no. Each exit arrow must lead somewhere, and a question with three plausible answers should become two diamonds in a row. The most common flowchart bug is an unlabeled or missing exit; readers literally cannot follow a branch that doesn't say where it goes.
Start with a verb and keep it under about eight words: Verify email address, not The system will proceed to verify the email address entered by the user. If you need a sentence, you're describing three steps; break them up. Short labels also keep boxes the same size, which makes the chart's shape carry the logic.
A flowchart shows the logic of a process; a swimlane diagram shows the same logic plus who does each step, with one lane per person, team, or system. Swimlanes are better when handoffs are the problem; plain flowcharts are better when the branching is the problem. Draw the plain one first, then add lanes only if accountability is unclear.