User problem identification
User problem identification starts with observation and interviews, not with an idea you already like.
Find someone with a real problem. Build something they would actually use.
A design-led challenge: identify a user, prototype quickly, test with that user, and iterate based on what they do rather than what they politely say.
Building for someone other than yourself is the step that turns a school exercise into genuine design work.
Three core ideas, each taught with worked examples and then practised until it feels obvious.
User problem identification starts with observation and interviews, not with an idea you already like.
Prototyping means building the roughest version that can be tested. Polish comes only after the idea survives.
Testing and pitching means watching real use, then presenting what you learned alongside what you built.
Designers often build deliberately rough prototypes, because polished ones make testers reluctant to criticise them honestly.
“Users will tell you what they want.” They will describe what they think they want. What they do while testing is the real data.
Sessions 65–72 of the 72-session year, at two one-hour sessions per week.
Where this module fits, what you will build, and a hands-on starter that gets everyone curious about user problem identification.
Guided teaching on user problem identification, worked through together with the teacher.
Independent practice, small challenges and one deliberate mistake to diagnose.
Guided teaching on prototyping, building directly on the previous two sessions.
Applied tasks that combine user problem identification and prototyping in one piece of work.
Testing and pitching introduced and practised, completing the toolkit needed for the project.
Guided build session for the module project: AI-for-good solution showcase.
Finish, test against the checklist, present the work and explain the decisions behind it.
Every module ends with something the student built themselves and can demonstrate. This is the piece that goes into their portfolio and gets explained out loud at the end of session 72.
Test your prototype with one real user and say nothing while they use it. The silence is uncomfortable and enormously informative.
Students finishing Module 9 can:
The vocabulary introduced here, in plain language:
6 quick questions drawn from this module — vocabulary, the project you build, and a myth-or-fact round. Every wrong answer explains itself, so a mistake still teaches you something.
Tell us your child’s class and what they enjoy. We will suggest the closest program fit—no pressure and no upfront payment.