Flowcharts

⏱ 9 min✏️ Quiz at the end

Drawing an Algorithm

A flowchart is a diagram of an algorithm. Instead of a list of steps, you draw symbols connected by arrows β€” and the algorithm's whole logic becomes visible at a glance.

Flowcharts need no programming language. They are how engineers, doctors, and designers all sketch out processes β€” from apps to emergency procedures.

The Symbols

SymbolShapeUsed forExample
TerminatorRounded box (oval)Start and endSTART, END
ProcessRectangleAn action step"Add 1 to score"
DecisionDiamondA yes/no question"Is score > 10?"
Input/OutputParallelogramData in or out"INPUT age", "OUTPUT total"
ArrowLine with arrowheadThe order of flowconnects everything

Three rules keep flowcharts correct:

  1. Exactly one START
  2. Every decision diamond has exactly two exits, labelled YES and NO
  3. Every path eventually reaches an END (unless a loop is meant to continue)

A Complete Example

Deciding whether a number is big or small:

        β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”
        β”‚  START  β”‚
        β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”˜
             β–Ό
      β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
     β•± INPUT number β•±
    β””β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”˜
            β–Ό
      β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
      β”‚ Is number β”‚ NO
      β”‚  > 100?   │─────────┐
      β””β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜         β”‚
            β”‚ YES           β–Ό
            β–Ό        β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β•± OUTPUT      β•±
    β•± OUTPUT     β•±  β”‚  "Small"    β”‚
    β”‚  "Big"     β”‚  β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜
    β””β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜         β”‚
          β–Ό                β–Ό
        β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
        β”‚         END         β”‚
        β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Trace it with input 42: START β†’ input 42 β†’ is 42 > 100? NO β†’ output "Small" β†’ END. Tracing a flowchart with a specific value is the standard way to test it β€” and a favourite exam question.

Decisions and Loops in Flowcharts

The diamond is where selection lives: one question, two exits.

A loop appears when an arrow points back to an earlier symbol:

   β”Œβ”€β”€β”€β”€β–Ίβ”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
   β”‚     β”‚ Ask password β”‚
   β”‚     β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”˜
   β”‚            β–Ό
   β”‚     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
   β”‚  NO β”‚   Correct?   β”‚
   └─────│              β”‚
         β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”˜
                β”‚ YES
                β–Ό
         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
         β”‚ Unlock phone β”‚
         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

"Ask, check, ask again until correct" β€” a condition-controlled loop, visible as a circuit in the diagram.

Why Flowcharts Beat Text

  • Missing cases jump out β€” a diamond with only a YES arrow is an obvious bug
  • Dead ends are visible β€” a path that never reaches END means trouble
  • Anyone can read them β€” teammates, teachers, and non-programmers included

Many programmers sketch a flowchart before writing any code, and debug by tracing their flowchart with the exact input that caused a problem.

Worked Example β€” A Vending Machine

Design a flowchart for a vending machine that checks whether enough money has been inserted before dispensing a snack:

START β†’ INPUT moneyInserted β†’ INPUT itemPrice
  β†’ Is moneyInserted >= itemPrice?
       YES β†’ Dispense item β†’ Calculate change
             β†’ Is change > 0? 
                  YES β†’ Return change β†’ END
                  NO  β†’ END
       NO  β†’ OUTPUT "Insufficient funds" β†’ Return moneyInserted β†’ END

Notice how this flowchart has two decision diamonds, not one β€” a decision inside a branch of another decision. This is nesting, and flowcharts make it easy to see: the "change > 0?" diamond only exists inside the YES branch of the first diamond, because change is meaningless until the item has actually been dispensed. If you tried to write this as a plain numbered list instead, the nested structure would be far easier to lose track of β€” which is exactly why flowcharts are drawn before code, on paper or a whiteboard, while the logic is still being worked out.

From Flowchart to Pseudocode

Flowcharts and pseudocode describe the same logic in two different notations β€” a diagram versus text β€” and translating between them is good practice for reading either one fluently. The vending machine flowchart above becomes:

INPUT moneyInserted
INPUT itemPrice
IF moneyInserted >= itemPrice THEN
    dispense item
    change ← moneyInserted - itemPrice
    IF change > 0 THEN
        return change
    ENDIF
ELSE
    OUTPUT "Insufficient funds"
    return moneyInserted
ENDIF

Every diamond became an IF; every rectangle became a line of pseudocode; the arrows became the order the lines are written in. Once you can translate confidently in both directions, you can choose whichever notation suits the moment β€” a flowchart for planning and communicating with non-programmers, pseudocode for something closer to real code.

Key Words

  • Flowchart β€” a diagram of an algorithm using symbols and arrows
  • Terminator β€” rounded box marking START or END
  • Process β€” rectangle holding an action step
  • Decision β€” diamond holding a yes/no question with two exits
  • Trace β€” following the flow with a specific input to check the logic