Flowchart Fundamentals

Flowchart Fundamentals

A flowchart is a visual language for logic. Before a single line of code is written, before a database schema is designed, an analyst can draw a flowchart that makes the logic of a business process or system procedure completely visible to every stakeholder in the room — from the clinic receptionist to the software architect. That shared visibility is the point: it forces ambiguity into the open and collapses hours of verbal debate into minutes of pointing at a diagram.

This lesson covers the five standard flowchart symbols, how to combine them into a working diagram, and how to read and critique a flowchart for correctness. By the end you should be able to draw a clean, properly notated flowchart for any linear or branching business procedure.

The Five Core Symbols

Each symbol has a specific shape and a specific meaning. Using the wrong shape — for example, a rectangle where a diamond belongs — is not merely a cosmetic error; it misleads every reader about whether that step involves a branch in logic. The figure below shows each symbol drawn to standard proportions, its name, and its meaning.

Rules That Make a Flowchart Correct

Drawing the shapes is the easy part. The discipline is in the rules:

• One Start, at least one End: Every flowchart begins with a single Terminator labelled "Start" and finishes at one or more Terminators labelled "End" (or "Stop"). A diagram with no End is logically incomplete — it implies the process never terminates.
• Label every Decision exit: A diamond with an unlabelled exit is meaningless. Use "Yes" / "No" for binary questions, or specific values ("Standard", "Express", "Same-Day") for multi-exit decisions. Readers must know which path to follow for every possible answer.
• Process boxes describe actions, not questions: "Check Stock Level" belongs in a diamond; "Update Stock Record" belongs in a rectangle. If you catch yourself writing a question in a rectangle, you need a diamond instead.
• Flow direction is top-to-bottom, left-to-right: The default reading direction. Backward arrows (loops) are legitimate, but should loop back cleanly — typically to a step before the decision that caused the loop.
• One action per process box: "Validate form AND send email AND update database" crammed into one rectangle hides three discrete steps. Split them. Granularity aids debugging and later database design.

Reading a Flowchart: Clinic Appointment Booking

The diagram below shows the patient appointment-booking process for a small private clinic. Walk through it systematically: identify each symbol, trace the Yes path from the first decision and then the No path, and note where the two paths merge before reaching the End.

Notice what this diagram makes immediately visible: there are two exit paths from this process — one where the patient successfully books and receives a confirmation, and one where no suitable slot exists and the patient is notified. Without the flowchart, a developer might implement only the happy path and miss the second ending entirely.

Using the Connector Symbol

On a small diagram like the clinic example, flow lines can cross the page cleanly. On a complex business process — say, a 30-step order fulfillment procedure — flow lines cross and tangle until the chart becomes unreadable. The connector symbol (a small circle with a letter) solves this. Instead of drawing a long crossing arrow, you place a connector circle at the point where the flow leaves, label it "A", then place a matching "A" circle where the flow should resume. The reader follows the letter, not the line.

Practical Drawing Tips

1. Write the narrative first: Before opening a drawing tool, list the steps of the process in plain English. Then identify which steps are actions (rectangles), which involve data entry or output (parallelograms), and which involve a yes/no choice (diamonds). This pre-analysis prevents the most common error — drawing shapes before the logic is clear.
2. One verb per process box: "Validate", "Calculate", "Send", "Update". If you find yourself writing "and" inside a rectangle, split it into two boxes.
3. Walk a trace path: Once drawn, trace the flow from Start to each possible End, following every branch. Read each step aloud: "If the slot is available, I go right to Book Slot; then I send a confirmation; then I reach End. If the slot is not available, I go down to Show Alternatives…" This verbal trace is the fastest bug-finder for a flowchart.
4. Validate with stakeholders: Show the flowchart to the people who actually perform the process. They will immediately spot missing branches ("What about when the patient wants a specific doctor, not just any doctor?") and incorrect flow.

With these five symbols and their rules internalised, you are equipped to model any discrete business procedure as a flowchart that any stakeholder can read, critique, and approve. In the next lesson, we extend this into drawing effective flowcharts for real, multi-path business scenarios — including how to handle loops, exception paths, and swimlane separation of responsibilities.