Lego Logic Studio

Overview

Today students learn to implement simple algorithms as visual programs using input, sequencing, branching (if/then), and fixed iteration, through a Lego STEM Prime build. They also use the design thinking process to define a simple problem and create/test a programmed solution.

Learning intentions

Students will:

• implement a simple algorithm in a visual programming environment using input, sequencing, branching, and fixed repetition
• describe and debug their program steps using clear language (what happens first, next, and in each decision)
• apply design thinking to solve a defined user problem by planning, building, programming, testing, and improving

Success criteria

Students can:

• create a program that uses an input to make a decision (if/then) and repeats a set of actions a fixed number of times
• explain their algorithm in order using correct terms (input, step sequence, decision, repeat)
• test their program against the design criteria and improve one part when it doesn’t work

Curriculum links

• Digital Technologies: implement simple algorithms as visual programs involving control structures and input - Digital Technologies: follow and describe algorithms involving sequencing, comparison operators (branching) and iteration - Digital Technologies: define problems with given design criteria and by co-creating user stories ## Lesson structure (60 minutes)

1. 0–5 min · Hook (Show & predict). Teacher demonstrates a short STEM Prime behaviour (e.g., “If sensor detects something, then move; otherwise turn”). Students predict what will happen using “If…, then…” sentences.

2. 5–15 min · Direct teach (Algorithms with input). Teacher models a simple flow: Input (sensor) → decision (if/then) → repeated action (fixed loop) → end state. Students complete a teacher-provided “algorithm strip” (6–8 cards) in pairs, arranging steps in the correct order.

3. 15–25 min · Design thinking: Define (Problem & user story). Teacher introduces a kit-based challenge: “Build and program a robot helper that performs a task based on a sensor reading.” Provide constraints: must use at least one decision and one fixed repetition; must be safe and shareable within the class. Students co-create a user story using a template: “A user wants __ so that __.” Then they select two design criteria as a class (e.g., “When input is ‘on’, do action A; when ‘off’, do action B.”).

4. 25–45 min · Build & program (Create). Teacher releases students to build a simple mechanism that supports the required actions (for example: move/turn in response to sensor input; trigger a repeating sequence to “patrol” or “collect” actions). Students program using the visual interface, including:

• input: a sensor event (e.g., touch/colour/ultrasonic depending on kit options)
• branching: at least one if/then decision
• fixed iteration: a repeated sequence for a set number of times (e.g., repeat 3 moves) Teacher circulates with prompts: “Where is your input used?” “What is your if condition?” “What step is repeated, and how many times?”

5. 45–55 min · Test & debug (Improve). Teacher runs a “2-minute test rhythm”: test once, note outcome, identify one change, re-test. Students run their program at least twice, recording: what they expected vs what happened, and one improvement they made (or one they plan to make next time).

6. 55–60 min · Share & exit check. Teacher asks two quick demo questions to volunteers: “What is your input?” and “What repeats, and how many times?” Students complete a brief exit ticket on paper: draw or list their algorithm steps (5 lines max) including one if/then and one repeat.

Resources

• Lego STEM Prime kits (one per student pair)
• iPads/tablets or computers with the kit’s visual programming environment
• Algorithm strip cards (sequencing, decision, repeat cards)
• User story template and design criteria checklist
• Program recording sheet (Expected/Actual + One Improvement)
• Exit ticket slips and pencils
• Teacher demo model and power/safety checklist for kit use

Assessment

• Observation checklist during Build & program: identifies input use, branching, and fixed iteration
• Quality of algorithm description during Test & debug: does the student correctly explain order, decision, and repeat?
• Exit ticket (summative for today): includes at least one if/then and one fixed repeat with a correct “how many times” statement

Differentiation

• Support:
• Provide sentence starters: “If sensor __, then I will __.” and “I repeat __ step __ times.”
• Offer a partially completed algorithm strip for students who need more structure.
• Teacher group check-ins at 12 minutes (algorithm readiness) and 35 minutes (program requirements).
• Extension for gifted learners:
• Challenge to add a second decision (two-step branching) and still keep the program simple and testable.
• Require an optimisation goal: reduce the number of blocks by using cleaner repeat structure.
• Ask for a “robustness test”: predict and test what happens if the input changes unexpectedly (e.g., boundary condition).
• EAL/SEN:
• Use visual icons for input/decision/repeat on recording sheets.
• Allow verbal explanations recorded by teacher or peer scribe if needed.

Extension (optional)

• Students create a “mission card” for another pair using their own program rules: include the user story, exact input trigger, and required repeat count. They swap missions and test for correctness.