AIQ
AIQ
Part of the Design Thinking for AI lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 💻 Hacker (11–14) · ⚡ Architect (15–18)
Open with students at their desks or in small groups — no devices out yet. Read the hook with energy:
"Great AI starts with a great PROBLEM to solve. Before building anything, ask: Who has this problem? Why does it matter?"
Ask the class: "Think of someone you know — a parent, a sibling, a classmate — who has an annoying problem they deal with a lot. Not a huge problem, just something that bugs them." Give them 30 seconds of quiet thinking time, then have them turn to a partner and share. Circulate and listen for good examples (e.g., "my mom forgets where she puts her keys," "my little brother can't tell time yet").
Bring the class back together: "Today we're learning how real AI builders — the actual engineers who make apps like the ones on your parents' phones — decide what to build. It's the exact same process you just did: find a person, find their problem, THEN think about solutions."
Write today's four keywords on the board where they'll stay visible for the whole lesson: Ideate, Empathize, Define, Build — the four icons from the app's hook screen. Tell the class: "You don't need to memorize these words today. Just notice them as we go — by the end of the lesson you'll already know what each one means, because we'll have done all four."
Walk the class through the lesson's three scenes as a guided sequence, pausing after each to connect it to the partner-problem they picked in the hook. Budget roughly 4-5 minutes per scene if you're narrating live alongside the app, or let pairs move through the interactive scenes on their own devices while you circulate and drop in the prompts below at each pair's pace — either approach works, and mixed-device classrooms often do better with the second.
Scene 1 — Find a Problem. Introduce each idea and ask students to apply it to their own chosen problem:
Give a concrete classroom-relevant example to anchor all four ideas at once: "Say a teacher wants students to remember their library books. Empathizing means actually asking students why they forget — is it because there's no reminder, or because the return bin is in an inconvenient spot? Researching means checking if the school already has a reminder system that just isn't being used. The problem statement might be: 'Students forget to return library books because there's no reminder close to when it's due.' And Not-Everything-Needs-AI means asking: would a simple sticker calendar or a text reminder from the librarian solve this just as well as building an app?" This example works well because the "simple fix beats AI" answer is genuinely true here, which reinforces the lesson honestly rather than as a scripted moral.
Scene 2 — Plan the Solution. Explain briefly, using the pair's problem as the running example: Data Check ("what information would you need to collect, and can you get it fairly?"), Prototype ("sketch your idea on paper before building anything real"), Ethics Check ("could this idea accidentally hurt or embarrass anyone?"), Success Metrics ("how would you know if your idea actually worked?"). On Data Check specifically, push a little further with this age group: "If you wanted to build something to help students who forget their books, what would you need to know? Maybe: which students forget most often, and why. But be careful — writing down 'which students forget the most' could embarrass those students if it's shared publicly. That's part of the Ethics Check too — even collecting information the right way can go wrong if you're not careful who sees it."
Scene 3 — Build & Test. Introduce MVP directly: "Build the simplest version first — a Minimum Viable Product. Test, learn, improve, repeat!" Use a relatable comparison: "If you wanted to build a lemonade stand, your MVP isn't a fancy cart with a sign and a cash register — it's a table, a pitcher, and cups. You test THAT first." Extend the comparison one step further: "Now imagine your first day, nobody buys lemonade because your sign is too small to read from the street. That's not a disaster — that's exactly what testing is FOR. You learn 'make the sign bigger' and try again the next day. That's the whole loop: build small, test, learn, improve, repeat." Cover User Testing and Iterate by asking: "Why might watching someone actually use your idea teach you something that just imagining it in your head never would?" (Answer to draw out: people surprise you — they use things in ways you didn't expect, or get stuck somewhere you thought was obvious.) Then have pairs open the app to complete the interactive scenes and quiz themselves, now primed with the vocabulary.
These work well as a quick-write (2 minutes, pen to paper) followed by a few volunteers sharing, rather than pure open discussion — 8-10 year-olds often produce more thoughtful answers when they've had a moment to organize a thought in writing first, and it also gives you material to check understanding from students who don't usually raise their hands.
Builder mode scores this quiz and awards XP for it, so treat it as a real check for understanding, not just review — but keep the tone matter-of-fact rather than high-stakes; a missed question triggers Axiom's "let's try again" message rather than any penalty, and students can retry. If you're doing this as a class rather than on individual devices, consider having students commit to an answer (thumbs at chest, reveal on three) before you show the correct one, so guessing off a classmate isn't the default.
Close with: "Every app or AI tool you've ever used started exactly the way you did today — someone found a real problem before they built anything. That's the part most people skip, and it's the part that matters most."
A quick check before moving on: ask two or three students, cold-call or volunteer, to say back in their own words what "MVP" means and why testing early matters. If the answers are vague ("it's the simple one"), that's a sign to revisit the lemonade-stand example rather than move on — this is the vocabulary this age band is expected to carry into 6.1.2, where they build something for real, so it's worth the extra minute to make sure it stuck.
Extension activity (to fill a full class period): Keep students in their pairs from the hook. Give each pair 10 minutes to turn their problem statement into a one-page "pitch": a drawn sketch of their MVP, one sentence on how they'd test it, and one sentence on whether AI is actually needed or a simpler tool would do. Have 2-3 pairs present their pitch to the class in under a minute each, and have the class vote thumbs-up/thumbs-down on whether AI was really the right choice for that idea — this previews the ethics-and-tradeoffs thinking that gets more explicit in older grades.
To stretch this further with a fast group, add a "one-day-later" round: after presenting, give each pair one specific piece of feedback from a classmate (assign this if the room is shy — "Pair 2, ask Pair 1 one question about their sketch") and two minutes to sketch a "version 2" that responds to it. This makes the build-test-improve loop something the class actually experiences in miniature during the period, rather than something they only heard described — pointing out afterward that they just did, in five minutes, a tiny version of exactly what the lesson's "Iterate" step describes.