Teaching "Design Thinking for AI" to Hacker mode (ages 11–14)

Hook & Warm-Up

Open with the framing line rather than a soft warm-up — this age group responds better to being treated as capable of real thinking from the first sentence:

"Good AI starts with good design. What problem are you solving? Who are you helping? Let's learn the design thinking framework applied to AI products."

Ask directly: "Name an AI feature you actually use — recommendations on YouTube or Spotify, a photo filter, autocomplete, whatever. Now: who do you think that feature was originally built FOR, and what problem were they trying to solve?" Take 2-3 answers and push back gently if an answer is vague ("to make the app better" isn't a problem — ask "better at what, for whom, specifically?").

Bridge to the lesson: "Every one of those features started with a team asking exactly that question, using a process called design thinking. It's not just a nice idea — teams that skip this step build things nobody wanted, and that happens constantly in the tech industry. Today we're learning the actual framework."

Optionally, mention one well-documented pattern without overclaiming specifics: tech companies regularly ship features or products that get pulled back or reworked after public criticism — sometimes for privacy concerns, sometimes because the feature simply didn't solve a real problem well. You don't need to name a specific incident if you're not certain of the details; the general pattern ("shipped fast, criticized publicly, reworked or pulled") is well-established enough to make the point on its own, and it sets up today's framework as a way to catch these problems before launch instead of after.

Main Activity

This age band can handle the full five-step framework by name, plus the reasoning behind each step, not just the step itself. Walk through the lesson's three scenes with more emphasis on the "why" and on realistic constraints.

Scene 1 — Find a Problem. Introduce the five-step framework explicitly: Empathize → Define → Ideate → Prototype → Test. Cover:

• Empathize: Push past "talk to people" toward method: "Real teams interview users, watch them use existing tools, and look for what frustrates them — not what users say they want in the abstract, but what actually goes wrong for them day to day."
• Research: Frame this as due diligence: "If a solution already exists and works, building AI is often wasted effort — or worse, it can make things less predictable than the tool it replaces."
• Problem Statement: Have students critique the example statement together: "Farmers waste 30% of water because they can't tell which crops need it." Ask: "What's specific about this? What's still missing — how would you find out if 30% is even accurate?"
• Not Everything Needs AI: This is a good moment to introduce cost/benefit thinking: AI systems can be unpredictable, need ongoing maintenance, and can encode bias — a simpler rule-based tool avoids all three risks when it's good enough for the job.

Give this age group a slightly harder discrimination task: present two mini-scenarios and ask which one actually needs AI. Scenario A: "A school wants to sort returned library books back onto the correct shelf by call number." Scenario B: "A school wants to flag which students' written essays might have been written with unusual outside help, based on writing-style patterns." Guide the class to see that A is a sorting/lookup task a simple rule-based system (or honestly, just a person) handles fine, while B is the kind of pattern-matching problem where an AI approach might genuinely help — though even there, push further: "And even for B, would you trust a flag from an AI system as proof, or as one signal a human still has to check?" (The honest answer is the latter — this is a good moment to note that AI pattern-matching for something like writing style is unreliable enough that it should never be the sole basis for a decision about a student.)

Scene 2 — Plan the Solution. Spend real time on Data Check and Ethics Check, since this is where the age band's added maturity matters most: "No data means no AI — full stop. And even when data exists, ask: was it collected fairly? Does it represent everyone the AI will affect, or mostly one group?" Connect Ethics Check directly to the framing that ethics review belongs early: "The two questions — 'could this harm anyone?' and 'is the data fair?' — need to be asked while you're still deciding what to build, not as a final check before launch."

A useful concrete illustration for "does the data represent everyone": ask, "if an AI system for recognizing faces was trained mostly on photos of one skin tone, what would you expect to happen when it's used on people with different skin tones?" Most students will correctly guess it would perform worse on the underrepresented group — this is a well-documented, real pattern in facial recognition research, and it's a clean, concrete way to make "fair data" mean something specific rather than staying an abstract virtue.

Cover Prototype and Success Metrics more briskly, but don't skip Success Metrics: "How do you know your AI 'works'? Just being right most of the time isn't enough on its own — right for WHOM, and what happens on the times it's wrong? A medical symptom-checker that's 95% accurate still gets 1 in 20 people a wrong answer — is that acceptable, and does it depend on how serious the missed cases are?"

Scene 3 — Build & Test. Define MVP with a real-world example students may recognize (e.g., early versions of well-known apps launching with far fewer features than today). Walk through the build → test → learn → improve → repeat loop and stress that user testing surfaces problems the original team could never have predicted on their own, because they aren't the user. Make the point explicit: "A team that builds only for people like themselves will miss problems that show up for everyone else — different ages, different devices, different levels of experience, different assumptions. That's one concrete reason 'talk to real people, not just your team' matters, beyond just being a nice sentiment."

Close this scene by connecting back to AIQ itself as a live example students can relate to: AIQ was built for Filipino students across four very different age groups, from five-year-olds to eighteen-year-olds, which is why the whole app changes its interface, vocabulary, and even mascot depending on who's using it — that's the Empathize and Define steps applied at the scale of an entire product, not just one feature.

Discussion

• "Can you think of an AI product or feature that seems like it skipped the 'empathize' step? What went wrong?"
• "Why might a team be tempted to skip the ethics check early on, even when they know they should do it? What pressures cause that?"
• "If you were building an AI tool for your own school, whose problem would you be solving, and how would you find out if it's a real problem or just an assumption?"
• "Is there a downside to testing with real users too early, before the idea is polished? What's the tradeoff?"
• "What data would an AI tool need to solve a problem you care about — and could you actually collect it fairly?"

These discussion questions work well as a think-pair-share (1 minute silent thinking, 2 minutes with a partner, then a few pairs share with the whole class) rather than cold open discussion — at this age, students often have sharper answers than they're willing to volunteer immediately, and the pair step surfaces more voices. If your class enjoys debate, question two (technical bug vs. process gap) is strong enough to run as a short structured argument with two sides defending each position.

Quiz Walkthrough

Hacker mode's quiz counts toward XP and league standing, so students at this age tend to take it seriously — use that motivation, but keep the post-quiz discussion focused on reasoning ("why is that the best answer?") rather than just confirming which option was correct, since the reasoning is what actually transfers to a real project later.

Wrap-Up & Extension

Close with: "The teams that build genuinely useful AI aren't necessarily the ones with the fanciest technology — they're the ones who did the unglamorous work of understanding a real problem first. That skill transfers to any project, not just AI."

This lesson sets up 6.1.2, "Train Your Own Model," where students actually collect data and train something in the app — so it's worth explicitly telling the class: "Everything we talked about today — empathize, define, check your data, check your ethics — you're about to actually do, not just discuss, in the next lesson. Keep today's framework in mind when you get there."

Extension activity (to fill a full class period): Break into small groups of 3-4. Each group picks a real problem at their school (not hypothetical — something they've actually noticed) and works through all five steps on paper in 15-20 minutes: a one-sentence problem statement, two brainstormed solution ideas (at least one non-AI), a rough prototype sketch, one ethics question they'd need to answer before building it, and one way they'd test it with real students. Groups present their problem statement and prototype sketch to the class (2 minutes each), and classmates ask one clarifying question per group — modeling the "test with real people" step on the framework itself.

If a group gets stuck picking a problem, suggest looking at their own school day for friction points: canteen lines, classroom scheduling conflicts, lost-and-found items, or group project coordination are all reliably rich sources of real (if modest) problems that this age group can reason about concretely, without needing to invent something abstract or overly ambitious to sound impressive.