Eight hands-on lessons in which ākonga turn precise ideas into working Scratch programs for a real audience.
Unplugged first, then build: lessons 1–2 need no devices at all — ākonga reason about algorithms, decomposition and sequence with paper, movement and argument — and lessons 5, 7 and 8 take those same models into Scratch, so the ideas are owned before anyone types them. Five of the eight lessons run with no devices at all — 1, 2, 3, 4 and 6. Lessons 5, 7 and 8 need Scratch on a device. If your class is ready to build on screen from day one, take the Creative Coding Studio route instead.
Other teaching approach: Creative Coding Studio →How can precise instructions and careful testing turn an idea into a digital outcome that works for someone else?
Ākonga begin as human “computers”, then build the same habits in Scratch: decompose, sequence, loop, choose, test and improve. The unit finishes with a working interactive project, user testing and a public class showcase.
A computer follows what was coded, not what the programmer hoped. Clear algorithms make thinking visible.
Loops handle repetition. Events and conditionals let a program respond to a user.
A bug is useful evidence. Programmers test one thing, explain what happened and improve the next version.
Driver and navigator roles rotate. Explaining code aloud lets knowledge move both ways and makes debugging collaborative.
Following Seymour Papert’s constructionist approach, ākonga learn computational ideas by making a shareable object, not by memorising definitions.
Learners choose an audience they know and test whether the outcome is clear, respectful and useful. Local stories, reo and images are used only with permission.
Write, run and repair instructions for a human robot.
Lesson 2Break a messy problem into parts, then remove details that do not matter.
Lesson 3Sequence a first interaction with a clear start event and ordered steps — on paper, or in Scratch if you have devices.
Lesson 4Replace repeated code with loops and compare which version is easier to change.
Lesson 5Use input and if/then logic to make a program respond to its user.
Lesson 6Diagnose three real Scratch bugs with a repeatable test protocol.
Lesson 7Plan and build an interactive outcome for an authentic audience.
Lesson 8 · SummativeCollect user evidence, revise the code and explain the decisions behind a working project.
Designing and developing an outcome through spatial and product design, materials, foods, biotechnology, systems, or digital tools
The full statement map and teaching evidence are on the curriculum companion. The programming emphasis in this unit is a teacher interpretation of the Phase 3 Digital Technologies focus, not a claimed verbatim quotation.
Teach this tomorrow: Arrange one device per pair, confirm Scratch access, print or share the project brief, and prepare scrap paper or mini-whiteboards. All referenced resources are provided in the linked pages.
Entry: Keep learners unplugged for longer, provide prewritten command cards, and use a starter Scratch file if sign-in or motor demands create barriers.
On-level: Expect sequence, an event, a loop, a conditional, user testing and one evidenced revision.
Extension: Add variables, multiple scenes, cloned sprites or a second user-test cycle, while keeping the original audience need visible.
Use stable pairs and rotate driver/navigator roles. Offer paper pseudocode, verbal explanation or screenshots as alternative response modes. Chunk build tasks into one testable behaviour at a time. Check colour contrast, readable text, keyboard controls and captions or text alternatives where sound is used. Learners without Scratch access can complete every algorithm and test task with command cards and storyboards.
Use learner-created or openly licensed media. Do not copy iwi or hapū stories, names, symbols, reo recordings or community data without permission. Keep accounts anonymous, never publish personal information, and use Scratch educator/classroom settings according to kura policy.
Formative evidence comes from algorithms, code traces, screenshots and debug notes. The summative is the Interactive Outcome Challenge: a working project, user-test evidence, one justified revision and a short explanation of the code.