Pattern Design Thinking

Overview

Today students apply design thinking to micro:bit LED pattern ideas by planning, prototyping, testing, and refining short animations. This builds on prior experience with basic programming blocks or simple LED commands by adding a structured process for turning a goal into working code.

Learning intentions

Students will be able to:

• Plan an LED pattern using clear requirements (goal, length, brightness, sequence).
• Create and iterate a micro:bit LED animation using event-free looping logic.
• Explain how changing inputs/steps changes the output sequence.
• Use debugging strategies to fix patterns that don’t match their design.

Success criteria

• I can describe my animation idea in 3–5 requirements and represent it with a simple storyboard.
• I can write code that produces my storyboard sequence on the micro:bit.
• I can test my animation, identify at least one issue, and update my program to improve it.
• I can explain (in words) the connection between my steps in the code and what appears on the LEDs.

Curriculum links

• Number System — multiplication/division and quotients of fractions (use to interpret timing/step “fractions” when pacing frames and comparing durations conceptually).
• Number System — absolute value as distance from 0 (use during animation “distance” checks like frame index from a target frame).
• The Number System — signs in ordered pairs and reflections (use coordinate thinking for LED positions: swapping signs reflects across axes).
• The Number System — interpret inequalities on a number line (use to justify frame order rules like “frame 2 must be greater than frame 1” for correct sequencing).

Lesson structure (45 minutes)

1. 0–5 min · Hook (Show + Ask). Teacher displays two quick micro:bit LED animations (one smooth loop, one “messy” jumpy sequence) and asks, “What makes the good one feel intentional?” Students quick-write 1 reason each, then share with a partner.

2. 5–12 min · Mini direct teach: Design thinking for LEDs. Teacher introduces a simple loop: Define → Design → Prototype → Test → Improve, then models filling a “requirements” box (theme, number of frames, what repeats, speed). Students help complete an example requirement storyboard: 3–4 frames with “what I see” captions.

3. 12–18 min · Bridge to programming logic. Teacher explains that an animation is a sequence of states: each frame is one LED screen, and code moves through frames in order (often with an array/list or repeated “show then pause” structure). Students identify the “states” in the teacher’s example and label them Frame 1, 2, 3.

4. 18–28 min · Guided planning: Storyboard + frame math (micro-timing). Teacher gives a template: choose 4 frames, pick a speed rule using fractions of a second (e.g., “pause 1/4 second per frame” to make a total duration). Students complete the template including:

• Number of frames (4)
• Pause time per frame (a fraction)
• Total animation time (multiply/relate quantities conceptually, e.g., “4 frames × 1/4 second”)
• A quick “frame order” inequality statement (e.g., frame 2 happens after frame 1)

5. 28–38 min · Prototype sprint (build on micro:bit). Teacher circulates to support block/code setup and debugging, reminding students: one frame at a time, then add the next. Students implement their storyboard on the micro:bit and run it; they must reach “it works once” before polishing.

6. 38–43 min · Test and debug check. Teacher uses a fast checklist: “Does it match Frame 1? Frame 2? Does it loop correctly?” and demonstrates one fix (wrong order, wrong pause, missing show). Students trade devices with a partner for a 2-minute test, then record one specific change they will make.

7. 43–45 min · Exit ticket (quick evidence). Students answer: “What code change improved your animation today, and which frame/behavior did it fix?” Teacher collects for next-step grouping.

Resources

• micro:bit kits (one per student or per pair)
• computers with micro:bit programming environment (blocks-based or text-based, teacher choice)
• LED storyboard template (4-frame planning sheet)
• “requirements” card (goal, frames, loop rule, speed)
• simple fraction/timing reference card (e.g., 1/2, 1/4, 1/8 sec)
• debugging checklist for frame order and looping
• teacher demo animations (pre-made code and recordings)
• projector or board for modeling steps

Assessment

• Formative checks during planning: teacher reviews storyboards for clarity of requirements and correct frame order language.
• During building: teacher uses a “frame test” question (“What do you expect to see right after the first pause?”).
• Exit ticket: evaluates whether students can connect a code change to a specific visual outcome (debugging reasoning).

Differentiation

• Support:
• Provide sentence starters: “In Frame 2, I want…”, “To fix it, I changed…”
• Offer a partial code skeleton that cycles through 4 frames, with placeholders for each frame’s LED pattern.
• Use a visual timing strip showing fractions of a second to reduce math load while still using the idea of fractions.
• Extension:
• Students add a 5th frame or adjust speed using a different fractional pause while keeping the loop length consistent.
• Students justify their inequality rule for frame order in words (“Frame 3 must be after Frame 2 so the animation reads…”).
• EAL/SEN:
• Reduce language demand by allowing students to label frames with icons (smiley, arrow, dot cluster) plus 1 short sentence.
• Offer a “choose from” list of common improvements: swap order, change pause, add missing frame, mirror across axis (if using coordinate-like LED placement).