Why it matters

A flowchart is the most universally recognized of all process diagrams: a sequence of shaped boxes connected by arrows that traces the flow of work through a procedure from start to finish. Its whole job is to take a process that lives in someone’s head — or buried in a paragraph of prose — and lay every step, every branch, and every loop out on the page, so the logic can be walked, audited, and argued with rather than assumed.

For example: a team writes up its deployment process as a paragraph — “merge the branch, run the tests, deploy to staging, get approval, ship.” Read aloud it sounds complete. Drawn as a flowchart, the decision diamond after “run the tests” has only one arrow coming out of it — the yes branch. Nobody had ever specified what happens when the tests fail, so in practice each engineer improvised. The prose hid the gap behind the happy path; the diamond with a missing arrow made the unhandled case impossible to overlook.

  • What it shows. The full sequence of a process — its steps, the decision points where it branches, and every alternative path through it — drawn in a small standardized vocabulary of shapes so the logic is explicit.
  • When to reach for it. A process that exists or is being designed, has more than a handful of steps and at least one branch, and needs to be communicated to people who will execute, audit, or improve it.
  • How to read it. Start at the rounded terminator, follow the arrows step by step, and at each diamond take the branch its condition dictates — tracing the happy path first, then each alternative, to the end.
  • What you’d miss without it. The branches prose glosses over — the unhandled cases, the dead-ends that never reach an endpoint, and the loops — which a flowchart’s decision diamonds force you to draw and label explicitly.
  • Where it misleads. A linear, obvious process gets no clarity from being flowcharted (a list would do); and a tidy chart can imply a process is well-understood when the real divergence is between the chart and what people actually do.

How to read it

A flowchart traces a process step by step in a small standardized vocabulary of shapes, and once you know the shapes you can read any chart in the world. A rounded rectangle (or oval) is a terminator — the start or the end. A plain rectangle is a step: a single action the process takes. A diamond is a decision — a yes/no question — and crucially it has more than one arrow leaving it, one per answer, each labeled with the condition. A parallelogram is an input or output — data going in or a result coming out. And arrows carry the one thing the static shapes cannot: the direction of flow, the order in which it all happens.

So you read it by walking it. Begin at the start terminator and follow the arrow to the first step. Do what the rectangle says, follow its arrow, and keep going until you hit a diamond. There you answer its question and take the branch it dictates — yes down one arrow, no down the other — and carry on. Sometimes an arrow leads backward, to a step you’ve already passed: that’s a loop, a part of the process that repeats until some condition lets you out. You’re done when an arrow delivers you to an end terminator.

What this makes visible is the actual logic and sequence of the process — including every branch and loop — laid out so it can be walked rather than assumed. Prose describes the happy path and quietly drops the rest; a flowchart cannot, because a decision diamond with only one arrow coming out of it is a visible hole, a dead-end path that never reaches a terminator is a visible bug, and the number of distinct routes from start to end is right there to be counted. Reading a flowchart back is the test: trace the main path first, then each alternative, and any branch you can’t finish tracing is work the process hasn’t specified yet.

When to use it

The flowchart belongs to the PROCESS family of diagrams — the artifacts that structure procedural sequences and workflows — and within that family it is the foundational sequential-process tool: the one you reach for to specify or communicate a procedure or algorithm with branches. That places it next to several relatives, and knowing the boundaries is how you pick the right one:

  • The Process Mapping mode draws the value-stream view of a process rather than its control logic — it makes handoffs between people, the queues that pile up between steps, and the waste and delay visible, asking not “what is the branching logic” but “where does this process leak time and effort.” Reach for it to improve a flow; reach for a flowchart to specify one.
  • A Sequence Diagram is the right tool when the process is a conversation between multiple actors and the question is who sends what message to whom over time — it puts the actors across the top and time down the page, where a flowchart puts the logic.
  • A State Diagram is for when the subject isn’t a procedure but a thing that moves through a lifecycle — its concern is the states something can be in and the transitions between them, not the sequence of actions a worker performs.

Reach for a flowchart when a process has sequential steps and at least one decision branch and needs to be made explicit for the people who run, audit, or improve it. Skip it when the process is purely linear and obvious (a simple list suffices), when the central question is the handoffs and bottlenecks between actors (use the Process Mapping mode’s value-stream view), when multiple actors exchange messages over time (a sequence diagram), or when the subject is a lifecycle of states rather than a sequence of actions (a state diagram).

How Ora builds it

Ora produces a flowchart from a semantic spec — a structured description in which each node is typed by its role (terminator, process, decision, or input/output) and the edges between them are directed and, where they leave a decision, carry a branch label (the yes/no condition that selects them). Loops are simply edges that point back to an earlier node, and a large process can name a sub-process node that expands into its own chart. That spec is then rendered to a diagram — Graphviz arranges and draws the typed shapes and directed arrows, with Mermaid’s clean flowchart syntax as the alternative for environments that render Markdown directly — together with an outline view and alt-text describing the start point, each decision diamond with its condition and branches, the endpoints, and the count of distinct paths through the chart, since the shapes alone are not accessible to a screen reader.

The diagram is the visual face of Ora’s process-specification work: when you describe a procedure and ask for it to be drawn, Ora identifies the start, the ordered steps, the decision points and their conditions, and the end points — and ensures both branches of every decision are traced to a conclusion rather than left hanging. Reading the result back, tracing the happy path and then each alternative, is how it shows its work and surfaces the unhandled cases.

The technique is the work of Frank and Lillian Gilbreth, the industrial-engineering pioneers who introduced the “process chart” in their 1921 paper Process Charts, presented to the American Society of Mechanical Engineers — the first systematic notation for charting work as a connected sequence of steps. The conventional shapes were later carried into computer-program design and then standardized: ANSI fixed the symbol vocabulary in the 1960s, and ISO 5807 (1985) is the international standard for flowchart symbols. The practice is documented for a modern audience in Robert Damelio’s The Basics of Process Mapping, which treats the flowchart as one of three complementary views of work alongside relationship maps and cross-functional (swimlane) maps.

  • Sequence Diagram — the PROCESS-family member for interactions: actors across the top and time down the page, showing who sends which message to whom, where a flowchart shows branching logic.
  • State Diagram — the lifecycle view: the states a thing can occupy and the transitions between them, rather than the ordered actions of a procedure.
  • C4 Architecture Diagram — the structural skeleton a process flows through; pair the two when a procedure traverses multiple software components (C4 shows the parts, the flowchart shows the flow).
  • Process Mapping (mode) — the value-stream complement: handoffs, queues, and waste for improving a flow, where the flowchart specifies its control logic.