Sketch and Flowchart

One-sentence summary

Before writing any code or connecting any wires, we put the idea on paper using a rough sketch, a flowchart and a system block diagram.

Why does it matter?

In the previous lesson you chose one idea from several solution alternatives. Now you have a plan: "I will build a night light that turns on by itself when it gets dark." But an idea that stays inside your head is fuzzy. Which part connects where? In what order does the program make its decisions? If you start without writing this down, you often get stuck halfway and have to take everything apart again.

Design means thinking before doing. Engineers draw a plan before building a house, and we draw a sketch before building a robot. Fixing a mistake on paper takes five minutes; fixing the same mistake in a soldered circuit can take an hour.

In this lesson we use three simple tools: a rough sketch, a flowchart that shows the steps, and a system block diagram that shows how the parts connect. Together they answer the questions "how will it look?" and "how will it work?" before you write a single line.

The sketch: making the idea visible

A sketch is a rough drawing that shows how the project will look. It is not artwork; straight lines and labels are enough. The goal is to get the idea out of your head and onto paper.

For our night light, the sketch answers questions like: Where does the light sensor face? Where will the LED be visible? How big is the box? Where does the battery fit?

Example 1: A night-light sketch

You can label a hand-drawn box like this:

        +---------------------------+
        |   [Light sensor]  ○       |  <- faces the top surface
        |                           |
        |     ( LED  ●  ●  )        |  <- faces front, lights the room
        |                           |
        |   [Board]    [Battery box]|  <- inside
        +---------------------------+
             Box: ~10 x 6 x 4 cm

Even this simple drawing raises an important question: if the sensor can see the LED's own light, will it make a wrong decision? That is why we put the sensor on top and the LED at the front. Without the sketch, we might only notice this once the lamp starts flickering on and off.

Example 2: A study-break reminder

The same method works for a completely different project. Imagine a small device that says "take a break" after a set time. The sketch shows where the screen faces and where the button goes:

        +------------------------+
        |   [Screen: 25:00]      |  <- faces the user
        |                        |
        |   ( Start button )     |  <- front, easy to reach
        +------------------------+

In both examples the sketch does the same job: deciding where the parts go before you write any code.

The flowchart: writing the order of decisions

A flowchart uses shapes and arrows to show which steps a program will take and in what order. You saw this earlier in the Flowcharts lesson; here we use it to plan a real project.

As a reminder, the basic symbols are:

• Oval: Start or end.
• Rectangle: An action to perform.
• Diamond: A yes/no decision.
• Arrow: Moving from one step to the next.

The night light's flowchart

The lamp's logic is simple: if it is dark, turn on; if it is bright, turn off; then check again. In text form we can draw it like this:

        [Start]
           |
    [Read light level]
           |
   <Is it dark?>
       /          \
     Yes           No
      |             |
 [Turn LED on]  [Turn LED off]
       \          /
        [Wait briefly]
           |
      (read again)

This diagram answered a question without writing the program: "When does the light turn on?" The answer is clear. But without drawing it, you could easily forget to think about how to set the threshold between "bright" and "dark."

A flowchart becomes even more valuable when conditions pile up. If you add an on/off switch to the lamp, the number of decision boxes grows to two: "Is the switch on?" and "Is it dark?". The chart lets you see both decisions side by side.

The system block diagram: how the parts face each other

A flowchart shows *what will be done*; a system block diagram shows *which part is connected to which part*. Each part is a box, and the arrows between them show the direction that information or power flows.

The night light's block diagram

  [Light sensor] --(reading)--> [Board / Brain] --(command)--> [LED]
                                     ^
                                     |
                                 [Battery / Power]

This diagram makes three things clear:

1. Input: The light sensor measures the room and sends a reading to the board.
2. Process: The board decides based on the reading (the logic from the flowchart).
3. Output: The LED turns on or off according to the board's command.

Almost every electronics project fits this input → process → output pattern. The block diagram shows early whether you forgot a part. If you forget to draw the battery arrow, the question "so where does the board get its power?" jumps out at you right away.

The sketch, the flowchart and the block diagram are three faces of the same project: how it looks, how it decides, and what it connects to.

Mini practice

Complete the three steps below on one page of a notebook. In this round we write no code at all; we only design.

Project idea: a line-following robot (you remember it from earlier modules) that moves while staying on a black line.

1. Draw the sketch. Label the downward-facing sensor, the wheels and the battery on top of a box.
2. Draw the block diagram. Fill in the blanks:

  [Line sensor] --(...)--> [ ......... ] --(...)--> [Motors]
                               ^
                               |
                           [ ......... ]

1. Write the flowchart. Complete this skeleton:

        [Start]
           |
    [Read sensor]
           |
   <Am I on the line?>
       /          \
     Yes           No
      |             |
 [ ......... ]  [ ......... ]
       \          /
        (read again)

When you finish, ask yourself: could a friend look at these three pages and understand what the project does? If they can, your design is ready.

Common mistakes

Jumping straight into code

The most common mistake is sitting down at the computer without drawing any plan. On tiny projects you might get lucky, but as the number of parts grows, a project without a plan falls apart in the middle.

Over-decorating the sketch

A sketch is not a piece of art. Fussing over shading, color and perfect lines is a waste of time. Boxes and labels are enough; what matters is understanding the positions and the connections.

Leaving the "no" path of a decision empty

In a flowchart it is common to draw a decision box and fill in only the "yes" side. If you ask "Is it dark?", you also have to write what happens when it is *not* dark.

Forgetting power and input

In a block diagram, everyone draws the output first, like the LED or the motor. The sensor (input) and the battery (power) are often forgotten. Check the input → process → output pattern every time.

Safety note

This is a paper-planning lesson, so it holds no physical danger. Still, when you turn the design into a real circuit, build the battery, motor and LED connections together with an adult. Do not make any design that runs on mains electricity (a wall socket); keep every project on low-voltage battery or USB power. Adding a "safety" label to your sketch from the start helps you think early about which part might get warm or needs care.

Lesson summary

• Design means thinking before doing; a mistake on paper is cheap, a mistake in a circuit is expensive.
• The sketch shows how the project will look using rough boxes and labels.
• The flowchart shows which decision the program makes and in what order.
• The system block diagram shows which part connects to which part.
• Almost every project fits the input → process → output pattern; the block diagram catches a missing part early.

Review questions

1. What does the sketch answer in a project?
2. What does the diamond shape mean in a flowchart?
3. What is the difference between a system block diagram and a flowchart?
4. In the "input → process → output" pattern, which part does the night light's sensor belong to?
5. Why is fixing a mistake on paper cheaper than fixing it in a soldered circuit?

Answers

1. How the project will look: the positions of the parts, the size of the box, and which surface faces where.
2. It shows a decision with a yes/no answer, from which two different paths branch out.
3. The flowchart shows *what will be done and in what order*; the block diagram shows *which part connects to what*.
4. It belongs to the input part; the sensor measures the room and sends a reading to the board.
5. Because correcting paper with an eraser takes minutes, while removing a part from a soldered circuit, reconnecting it and testing takes much longer.

Source and verification note

For “Sketch and Flowchart”, verification focuses on whether the relationship between The sketch: making the idea visible and Example 2: A study-break reminder remains consistent across examples. A project page should make a result claim only when it is supported by a real prototype, test record or observation. Numbers such as cost, duration and success rate must be labelled clearly when they are estimates.

Next lesson

Bill of Materials and Cost: To turn your design into reality, which parts do you need and how much will they cost?