Describe the process as a list, get a proper flowchart with real symbols
start: / end: terminators · ? Q decision (next line = yes path) · ? Q | Target no branch jumps to Target · .step branch-only (no arrow in from above) · > step input/output · # comment
| Symbol | Shape | Means | Example |
|---|---|---|---|
| Terminator | Rounded rectangle | Start or end of the flow | "Start: order received" |
| Process | Rectangle | An action or step | "Charge the card" |
| Decision | Diamond | A yes/no question | "Card approved?" |
| Input / Output | Parallelogram | Data entering or leaving | "Email receipt sent" |
| Flow arrow | Directed line | Order of steps | Yes/No labeled exits |
| Document | Wavy-bottom rect | A printed or filed doc | "W-4 filed" |
| Connector | Small circle | Jump to another page | "A" on page 2 |
The first five symbols follow the ANSI/ISO conventions drawn in every process diagram since the 1970s. They're what readers expect; the exotic shapes rarely earn their complexity.
The left pane takes a plain-text description of a process; the right renders it with standard symbols. Every line is a step. A leading ? makes it a decision diamond whose yes path continues to the next line, and | Target on that line aims the no branch at a later step by name, which is how loops and rejections are drawn. The result is an SVG you can download and drop into documentation, a wiki page, or a slide.
Write the happy path first, top to bottom, in short verb-first steps. Then go back and add the decisions, asking at each step "what could go differently here?" and marking those with ?. Keep every box under about eight words; if a step needs a paragraph, it's really three steps. End every branch somewhere explicit, even if it's just an end: line with a different label, because open-ended branches are where readers get lost.
The default chart shows a refund flow in five lines: a terminator, a data lookup, one decision with a named no-branch target, an action, and an end. The hiring sample shows a longer pattern, with two decisions in sequence and a rejection path that exits early. Both were written in under a minute, which is the point: the fastest flowchart is the one you can draft while the process is still fresh.
Five cover almost everything: a rounded terminator for start and end, a rectangle for a process or action, a diamond for a decision, a parallelogram for input or output, and an arrow for flow direction. Document, database, and connector symbols exist for specialized diagrams, but mixing in too many shapes is the fastest way to make a chart nobody reads.
One step per line. Plain lines become process rectangles. Start a line with start: or end: for terminators, with ? for a decision diamond (the next line is the yes path), and with > for input or output. Add | Target step after a decision to point the no branch at a later step by name. Lines starting with # are ignored.
One clear start, decisions that always have two labeled exits, verbs in every box, and no more than around 15 steps on one page. If the chart needs a legend longer than the chart, split it into a main flow plus sub-flows. Test it by walking a real example through every branch with your finger.
When the order of operations can change based on conditions. A checklist assumes every step happens every time in sequence; a flowchart earns its keep the moment someone asks "but what if it fails validation?" If your process has no branches, a checklist is honestly the better tool.
Yes, that's what the decision branch is for. A validation step like ? Form valid? | Fix errors sends the no path back to the step named Fix errors, drawing a branch arrow to wherever that step lives in the chart. Loops read naturally once the arrow exists, and every retry loop should have an obvious exit.