Did you know a flowchart can look tidy and still leave a learner unable to decide what happens next? A diamond containing a question might have two arrows and perfectly drawn boxes, but if neither arrow says “Yes” or “No”, the diagram may be missing an essential part of its meaning.
A decision flowchart represents a procedure that selects a path according to a condition, usually a question with two possible outcomes. Each outgoing branch should identify which result it represents. When Yes and No arrows are missing, do not assume left always means Yes or down always means No; those positions are layout choices, not general rules. Write the condition precisely, label its outcomes, and test the paths using concrete input cases before treating the flowchart as a complete algorithm.
The diagnostic: what can you know from the picture alone?
Draw a diamond that says “Is the library card valid?” and two unlabelled arrows. The left arrow leads to “Ask the librarian for help”; the right leads to “Continue to the borrowing desk”. Ask a student, “Which direction does a valid card take?” Some will guess right because the destination makes sense. Ask what in the drawing proves it. The diagram strongly suggests an intended meaning, but without labels or a written procedure the path condition is not explicit. A reader may infer the author’s intention without being able to verify it.
The repair is small but important. Mark the arrow to “Continue” as Yes and the arrow to “Ask for help” as No, provided those meanings match the intended borrowing rule. Then write a test: if the card is valid, the procedure should continue; if not, it should ask for help. When a chart contains unlabelled arrows, students should identify the missing information rather than invent certainty.
A complete worked example: a fictional school-library routine
Invented teaching scenario: imagine a library lending exercise with exactly two Boolean inputs: card_valid and book_available. Each may be Yes or No. The simplified rules are chosen for learning algorithms; they are not an actual school library policy. If the card is not valid, the system sends the learner to ask for help. If the card is valid and the book is available, the book can be issued. If the card is valid but the book is unavailable, the learner may request a reservation.
Write the intended procedure in plain language first
Start: check whether the card is valid. If No, output “Ask for help” and finish. If Yes, ask whether the book is available. From that second decision, if Yes, output “Issue the book”; if No, output “Offer a reservation”. Each output ends the procedure. This verbal specification gives the missing labels a source of truth. We are not assigning branch meanings based on where the arrows happen to be drawn.
Translate words into a fully labelled diagram
Draw a Start oval, then a decision diamond containing “Card valid?” Give it two outgoing arrows labelled No → Ask for help → End and Yes → Book available?. The second decision has two arrows, Yes → Issue book → End and No → Offer reservation → End. A decision arrow carries the outcome of its own question, not the answer to the nearest previous question.
A common mistake is to label the right-hand arrow Yes in both diamonds because that is where the pupil put the first Yes arrow. There is no requirement for every Yes arrow to point in the same physical direction. One might go down and the other sideways. The decision test belongs on each arrow, not in the drawing’s overall direction.
Trace all four input combinations
- Card invalid, book unavailable: first test is No. The chart outputs “Ask for help” without evaluating whether the book is available.
- Card invalid, book available: first test is still No. The result is again “Ask for help”; book availability does not override an invalid card.
- Card valid, book unavailable: first test is Yes, second is No. The result is “Offer a reservation”.
- Card valid, book available: first test is Yes, second is Yes. The result is “Issue book”.
Four rows are enough to cover the possible combinations of these two Yes/No inputs: 2 × 2 = 4 cases. Yet the second question is actually reached only when card_valid is Yes. For an invalid card, the book_available value does not change the output. This is a deliberate example of path-dependent testing, not evidence that the omitted branch label was harmless.
Check the count without confusing paths and cases
The diagram has three possible final outputs: ask for help, offer reservation, and issue the book. That is different from the four possible input combinations. Two combinations lead to the same output because the first decision ends the procedure for invalid cards. A student who insists there must be four end boxes because there are four input rows is counting inputs instead of outcomes.
Why arrows need meaning, not merely decoration
The diamond asks a question. The arrow says what to do for a particular answer. Without its label, a reader may reach the correct endpoint by guesswork, because a chart happens to be laid out in a familiar way. That is not reliable communication. A strong flowchart should be traceable by someone who did not watch the author draw it.
If an arrow is missing entirely, the procedure may fail for one input. If both arrows are present but unlabelled, the procedure may be under-specified. If both arrows are marked Yes, the two outcomes are not distinguished. If a Yes branch leads to a step that assumes No, the diagram contradicts the intended rule. These are separate defects and require different fixes.
The National Centre for Computing Education’s flowchart and pseudocode course places flowcharts within the broader skills of sequence, selection and iteration. Students should learn how symbols and branching conditions represent decisions, not simply memorise that a diamond looks different from a rectangle.
A diagnostic checklist for a broken decision point
- Question: does the diamond state a condition a learner can actually test? “Is it okay?” may need a clearer rule.
- Outcomes: what answers are allowed — Yes/No, True/False, or something else clearly defined?
- Branches: is there a labelled outgoing path for each possible answer?
- Destination: does each labelled path lead to the action specified by the underlying problem?
- Termination: does every valid input eventually reach an appropriate output or a deliberately documented loop?
- Evidence: have representative cases been traced from Start to a final outcome, without jumping over decisions?
Avoid teaching a blanket rule that a diamond must always have exactly two outcomes. In many beginner exercises, a Yes/No condition has two outcomes; other decision structures can have multiple cases if the notation and specification make them clear. Our library example deliberately uses two outcomes to keep the trace test simple.
Practice that teaches debugging, not memorisation
Guided: one condition, two routes
Draw a diamond “Is the room light on?” with two action boxes: “Switch it off” and “Leave it as it is”. Explain the intended classroom rule as “Switch off a light that is on; otherwise do nothing.” Ask the student to place the Yes and No labels. They should mark Yes → Switch it off and No → Leave it. Then trace a light-on case and a light-off case and say which action each reaches.
Paired: a deliberately misleading chart
Create a fictional quiz flowchart with “Is the answer correct?” and arrows to “Try again” and “Next question”. Leave the labels blank. One partner labels according to the intended quiz rule: Yes → Next question, No → Try again. The other partner deliberately swaps the two labels and tests one correct answer and one incorrect answer. When a correct answer leads to “Try again”, the trace reveals the error. Fix the branch label, not the student’s input.
Independent: design a new two-decision procedure
Ask the learner to make a small flowchart for borrowing a classroom device. The learner must declare the two conditions and the intended actions, label every branch, and write at least four input cases with expected outputs. The partner should be able to run the chart without verbal hints. If it cannot be traced, the diagram is not yet finished, no matter how neat the shapes appear.
Four weeks from diagram reading to transferable debugging
- Week 1 — interpret: distinguish a process step from a decision, and locate the missing labels in simple two-path charts.
- Week 2 — repair: attach outcomes based on a written specification and check two contrasting inputs.
- Week 3 — trace: test two-decision charts systematically, noticing early exits and cases that share one output.
- Week 4 — produce independently: design an unfamiliar chart, exchange it with a partner, record defects and revise without being told which arrow to move.
How a parent or teacher can see real progress
Do not grade only visual presentation. Ask the learner to explain aloud which condition is evaluated at each diamond, why an arrow is Yes rather than No, and what happens for an input they did not use while drawing. Record whether the student can diagnose an error from a failed trace and fix the exact label. A learner who can do this on an unfamiliar chart is demonstrating algorithmic reasoning instead of colour-and-shape recognition.
Parents can use everyday decisions, such as whether an item needs charging before use, to practise tracing without a computer. The aim is not to teach a specific school rule as universal. It is to practise writing a condition precisely enough that another person can follow it. For teachers, a quick exit check can consist of a single unlabelled diamond and two input examples; the pupil must supply justified labels and show the path taken.
What the diagram cannot tell us
A chart does not establish whether its underlying policy is fair, safe or permitted. Our library routine has deliberately simplified outcomes. Real lending procedures can depend on privacy rules, availability, lending limits and human review. The learning objective is how to specify and test an algorithm, not to claim this fictional process should replace a genuine institution’s policy.
A perfectly labelled flowchart can still implement the wrong requirement. That is why the written rule, the chart and the test cases must agree. A missing Yes/No label is often just the visible symptom of a larger question: was the procedure ever defined clearly enough to test?
Questions students usually ask
Can I work out the missing labels from the action boxes?
Often you can form a plausible hypothesis. But the chart is clearer when the arrows actually carry those labels, and an ambiguous or contradictory action box may make the inference unreliable. Check against the original written requirement whenever possible.
Does Yes always come out on the right?
No. Arrow directions are layout conventions and can change. The condition and explicit branch labels determine meaning.
Should every possible combination of inputs get a separate output?
Not necessarily. In the worked example, two invalid-card combinations have the same “Ask for help” result. The important check is that every allowed input follows a well-defined route and reaches the intended outcome.
What if I do not know the intended rule?
Mark the missing information as an unresolved design question. Do not fabricate a school policy to complete the drawing. The most rigorous next step is to request the rule or state alternative possible meanings transparently.
Carry the method into another topic
For a related but different challenge, read how AND and OR conditions change flowchart branching and how to trace a flowchart that loops back. For a current subject pathway, see How G1 Computing Works. The eduKate Education learning hub explains why independent tests matter, and the Clementi mathematics reference demonstrates the same diagnosis-first teaching principle.
A flowchart becomes useful when somebody else can follow it without guessing what the author meant. The small labels Yes and No carry a surprisingly large educational idea: clear thinking must remain clear when it leaves the thinker’s head.