Design Thinking for AI

Learning Objectives

This lesson is AIQ's first in World 6, and it deliberately comes before any hands-on model-building (that starts in the next lesson, 6.1.2, "Train Your Own Model"). Its job is to plant a habit of mind: AI is a tool you pick up after you understand a problem, not a starting point you go looking for a use for. Across the four age bands, by the end of the lesson a student should be able to:

• State that finding a real problem comes before building anything. Every age band opens with this, phrased at their level — from "what would YOU want to fix?" for a five-year-old to "human-centered design starts with empathetic research" for a senior.
• Explain that AI is not always the right tool. Older students should be able to give a concrete reason (cost, risk, a simpler tool already solving it fairly); younger students should just be able to say "sometimes simpler is better."
• Describe the build-test-improve loop — that nobody gets an AI system right on the first try, and that testing with real users is how you find out what's wrong.
• (Ages 8+) Define an MVP — the simplest version of an idea that can be built and tested, rather than trying to build the "finished" thing first.
• (Ages 11+) Recognize that ethics and fairness checks belong early in the process — not as a final review step after something is already built, but as a question asked while still deciding what to build.

Teacher Background

You do not need a technical background to teach this lesson well — it is not about how AI works internally (that comes in other World 6 lessons), it is about how AI products get made, and that process is closer to what you already know from any good project-based learning unit than it is to programming.

The lesson borrows from "design thinking," a process product teams (AI or otherwise) use to avoid building something nobody needed. In the app it's taught as three scenes, each covering four concrete ideas. Find a Problem covers Empathize (talk to the people who have the problem, don't assume you already know it), Research (check whether the problem already has a solution, and whether AI is even the right tool), Problem Statement (write the problem down in one clear sentence — who is affected, what's wrong, why it matters), and Not Everything Needs AI (a spreadsheet, a conversation, or a simple app sometimes solves it better than AI would). Plan the Solution covers Data Check (what data exists, can it be collected ethically, is there enough of it), Prototype (sketch the idea on paper before writing any code), Ethics Check (could this harm anyone, is the data fair, what happens when it's wrong), and Success Metrics (decide up front how you'll know it worked — accuracy, speed, fairness). Build & Test covers MVP First (build the simplest working version, not the finished product), User Testing (watch real people use it — they'll find problems you never imagined), Iterate (build → test → learn → improve → repeat), and Get Feedback (feedback from a range of users catches blind spots).

Worth making concrete for your class: the app's worked Problem Statement example — "farmers waste 30% of water because they can't tell which crops need it" — isn't a made-up scenario to most Filipino students. Rice is the country's staple crop, grown by hundreds of thousands of smallholder families in provinces like Nueva Ecija, Iloilo, and Isabela, and matching irrigation to what a crop actually needs, rather than to a fixed schedule, is a real and unresolved efficiency problem in Philippine irrigation systems, not a hypothetical invented for the lesson. If any students have family who farm, or come from a rice-growing province, invite them to describe how irrigation timing is actually decided on that land today — usually by experience and a fixed rotation, not by measurement. That turns the example from a story about "farmers" in the abstract into a live, local problem an AI tool could plausibly help with.

The lesson also introduces the idea that AI is not always the answer, even when it's the exciting or trendy option. A spreadsheet, a printed sign-up sheet, or a five-minute conversation sometimes solves a problem faster, cheaper, and more reliably than an AI system would — and building AI anyway wastes time and can introduce new problems (bias, unpredictability, cost) that the simpler tool never had. Teaching students to ask "does this even need AI?" is as important as teaching them how to build one.

Two more terms come up, mainly for the older age bands. An MVP (Minimum Viable Product) is the smallest, simplest version of an idea that is complete enough to actually test with real users — the point is to learn quickly and cheaply before investing in a polished version. And the lesson frames the whole process as a loop, not a straight line: build something small, test it, learn from what went wrong, improve it, and repeat. Nothing works perfectly the first time, and that's expected, not a failure.

You will not need to write, run, or debug any code to teach this lesson — it's entirely conceptual and discussion-based. The next lesson in the sequence (6.1.2, "Train Your Own Model") is where students actually build something in the app.

It's worth understanding why AIQ places this lesson first in World 6, ahead of any hands-on building. Curricula that teach AI skills often start with the exciting, tangible part — "here's how to train a model" — and treat the thinking-about-problems part as an afterthought, if it appears at all. AIQ deliberately inverts that order here: before a student trains a single model in the next lesson, they spend one lesson learning that the training itself is the easy, mechanical part, and that deciding what's worth training a model to do is the part that actually requires judgment. This ordering also gives you, as the teacher, a lesson that needs almost no technical setup on your end — which makes it a low-effort, high-value one to deliver well, since the return on a good discussion here carries into every AI lesson that follows it.

One more thing worth knowing before you teach it: this lesson uses the same three-scene structure as the technical AI lessons elsewhere in AIQ (a "Find a Problem" scene, a "Plan the Solution" scene, and a "Build & Test" scene), but none of the scene content in this particular lesson is really AI-specific — every one of these ideas (talk to real users, don't over-build, test early, expect to iterate) applies to building anything, software or otherwise. That's intentional, not an oversight: the lesson is teaching a general design habit and simply anchoring it to AI because that's the context World 6 is building toward.

Materials & Prep

A device with a browser (phone, tablet, Chromebook, or computer) and access to aiq.ph — that's the only strict requirement, since the lesson lives entirely inside the app's guided scenes and quiz.

• Optional but recommended for every age band: paper and pencil (or a shared whiteboard) for the "problem statement" or brainstorming activity described below — writing a problem down by hand tends to make it more concrete than typing it.
• For Explorer and Builder classes: nothing beyond the above. The activity works fine as a whole-class discussion with no extra supplies.
• For Hacker and Architect classes doing the extension activity: sticky notes or index cards make the group brainstorming step faster, though a shared document works too if the class is remote or 1:1 device.
• No printing, no accounts, and no data collection from students are needed to deliver this lesson.
• Because everything here is discussion-based, this lesson also works fine on a single shared classroom device if 1:1 devices aren't available — you can narrate the app's scenes to the whole class from one screen and run the quiz as a group activity, as described in each age-band script's Quiz Walkthrough section.

Common Misconceptions

Pick your grade's script