Read Teacher Guide once, then pair each day with the matching clean learner card. The case is fictional; no claim about an actual user's preferences or an existing product has been verified. Invite evidence-based alternatives. Every route below demands the same substantive analysis, even when its presentation changes. Routine day clock: 25 = 2 + 5 + 6 + 7 + 5 minutes. Check days: 25 = 2 + 3 + 12 + 5 + 3 minutes. Extend when needed.
Day 1 · Need before feature
Goal: separate a visitor's need from a proposed “live” feature in Card A. Say: “What is the person trying to do, even if no app exists?”
- 0–2: Show the proposal “live availability”; ask what evidence is missing.
- 2–7: Model a need statement: “A visitor wants to know the published practice times before travelling.” Point to the inside-only timetable as evidence.
- 7–13: Pairs identify a missing update process and draw a minimum static page.
- 13–20: Independent response: need, evidence, missing fact and a conditional first idea.
- 20–25: Collect one assumption that would have to be tested before claiming “live”.
Routes: write a need/evidence/unknown table; give a spoken explanation captured in notes; arrange “person / task / evidence / unknown” strips and dictate the same reasoning. Other domains: Day 1 swaps. Optional/home: invent a feature request for a fictional club and rewrite it as a user need on scrap paper. Move: if learners restate “the need is an app”, ask what the visitor could do with a reliable paper timetable sent in advance.
Day 2 · User perspective without assumption
Goal: analyse reader questions and missing evidence in Card B. Say: “Our design guess is not a user interview.”
- 0–2: Read “usual route”; ask why a newcomer might find it incomplete.
- 2–7: Model two different questions: which door today; where to start once inside.
- 7–13: Learners name the confirmed ground-floor entrance and what is not known about diverse users.
- 13–20: Draft a tentative need statement and a respectful question for future user testing.
- 20–25: Compare two statements for unwarranted “all visitors” claims.
Routes: written question/known/unknown grid; spoken scenario explanation with captured evidence; labelled path sketch with a dictated uncertainty note. Other domains: Day 2 swaps. Optional/home: write an invented page instruction that a first-time reader could use, then note who should review it. Move: if learners assert accessibility has been proved, point to the absence of testing in the card.
Day 3 · Decompose information flow
Goal: break Card C into input, update, display and human check. Say: “A page is only as current as its update process.”
- 0–2: Identify the tool code
T-04, not a visitor name, as the relevant item identifier. - 2–7: Model an arrow from volunteer's sheet update to a possible web display.
- 7–13: Pairs mark the point where “on table” could become stale and ask who would correct it.
- 13–20: Learners draw a four-part flow and justify one needed and one unnecessary data field.
- 20–25: Ask whether the display can claim real-time status; collect the reason.
Routes: write an input/process/output table; explain the flow aloud while a scribe captures the same four parts; place four labelled cards and arrows, then dictate a stale-data warning. Other domains: Day 3 swaps. Optional/home: diagram a fictional lending process using item codes only. Move: if learners jump straight to a database, bring them back to the human updating the source.
Day 4 · Draw the scope boundary
Goal: separate first-version needs from unsupported features in Card D. Say: “An attractive feature is not automatically a requirement.”
- 0–2: State the only confirmed update capacity: workshop times weekly.
- 2–7: Model a first-version schedule page and mark live stock as unsupported.
- 7–13: Pairs sort advice, counts, bookings and translations by evidence and process needed.
- 13–20: Independent scope note: include, defer or exclude each proposal with one reason.
- 20–25: Ask which missing fact would decide whether bookings are needed.
Routes: written three-column scope table; spoken scope decision with captured evidence; movable proposal strips on the scope mat with dictated justifications. Other domains: Day 4 swaps. Optional/home: reduce a fictional feature list to a defensible first version. Move: if someone proposes publishing a translation or count “for now”, ask who will verify accuracy and keep it current.
Day 5 · Criterion and first public check
Goal: identify need, scope and a testable criterion in Card E, then independently apply the same analysis to Check A. Say: “Name what we can observe, not just what we hope.”
- 0–2: Model “find an item code before rehearsal” as the prop-shelf need.
- 2–5: Contrast “easy to use” with a trial in which a crew member finds a code in a set time; do not preview Check A.
- 5–17: Give the fresh check, collect a first response in any route.
- 17–22: Use public key for feedback; invite a revised criterion with condition and measure.
- 22–25: Record a next move: need/evidence, scope, missing fact or criterion.
Routes: written four-part analysis; spoken analysis with a captured trial condition; labelled scope/criterion strips with dictated evidence. Other domains: Day 5 swaps after the check. Optional/home: invent a criterion a person could actually test in a paper trial. Move: if a learner claims “everyone finds it easily”, ask for the stated group, task and threshold. This public check is not secure or formal assessment.
Day 6 · Compare existing approaches
Goal: compare paper, static page and name form in Card F, tied to pre-travel information. Say: “A new form may create a new problem.”
- 0–2: Identify the visitor's question before travelling.
- 2–7: Model paper versus static page for reach before arrival; do not pretend either tracks live availability.
- 7–13: Students find the unexplained collection of names and the missing update process.
- 13–20: Recommend one low-risk first step and a question that could change the decision.
- 20–25: Ask which observation would test whether the chosen approach helped.
Routes: comparison matrix; oral trade-off explanation captured in notes; three labelled approach cards with a dictated recommendation. Other domains: Day 6 swaps. Optional/home: compare a paper notice and static page for an invented event. Move: if learners say “digital is always better”, ask who can see the page before travel and what process keeps it accurate.
Day 7 · Describe possible impacts
Goal: specify a group and mechanism for personal, social and economic impacts in Card G. Say: “A possible benefit is not a measured benefit.”
- 0–2: Show the idea of replacing every poster with one page.
- 2–7: Model one possible social impact: members without reliable mobile data could miss an update.
- 7–13: Pairs consider volunteer time and printing without inventing cost figures.
- 13–20: Learners recommend a communication mix and one observation to collect.
- 20–25: Challenge any “saves money” claim lacking cost data.
Routes: written impact table; spoken mechanism-by-group explanation captured in notes; label three impact cards and connect each to an affected group. Other domains: Day 7 swaps. Optional/home: make a fictional two-option communication plan without assuming everyone's connectivity. Move: if responses list only good or bad labels, ask “Who, how, under what condition?”
Day 8 · Emerging tech with a reason
Goal: weigh simple filtering against an untested suggestion tool in Card H. Say: “More complex technology must earn its place.”
- 0–2: State the actual task: find an approved description by topic.
- 2–7: Model the five-topic filter with the already tagged descriptions; mark its success as still untested.
- 7–13: Learners list evidence a suggestion tool would need: examples, accuracy, maintenance, consent/impact review.
- 13–20: Recommend a first step and justify a test before making benefit claims.
- 20–25: Ask how an incorrect recommendation might affect a visitor or staff workload.
Routes: written comparison; spoken option argument with captured evidence and uncertainty; two labelled option cards connected to need, data and risk strips. Other domains: Day 8 swaps. Optional/home: invent a small search problem and say when a fixed category list may be sufficient. Move: if learners equate “AI” with automatic accuracy, ask which training or evaluation facts the card actually provides.
Day 9 · Build a testable first-version brief
Goal: sort need, constraint, missing information and criterion in Card I. Say: “A criterion tells us what to observe when we trial a design.”
- 0–2: Identify the workshop-tent task.
- 2–7: Model a criterion: in a planned paper trial, a first-time reader points to the workshop tent on the static map in under 20 seconds. This is a target, not a result.
- 7–13: Students sort four statements with offline lab or paper strips; name mobile coverage as unknown.
- 13–20: Draft one first-version brief and explain what must be checked on site.
- 20–25: Compare two possible criteria for observability, not optimism.
Routes: written requirements/criteria table; spoken trial plan with captured reader/task/threshold; labelled four-strip sort and dictated reason using criterion mat. Other domains: Day 9 swaps. Optional/home: create a paper prototype of a fictional static map with a clear destination label. Move: if learners report a made-up trial “result”, change the tense to “we would test”.
Day 10 · Defensible recommendation and second check
Goal: synthesize Card J into a bounded first-version brief, then transfer to new Check B. Say: “A recommendation needs an evidence trail and a limit.”
- 0–2: Model the costume-shelf need and morning update constraint only.
- 2–5: Invite one wording that avoids a live-availability promise; do not preview Check B.
- 5–17: Independent fresh check in any equivalent route; collect first responses.
- 17–22: Discuss public key and revise one assumption or criterion.
- 22–25: Exit: name the next fact a real team would need before implementation.
Routes: write a brief with need, scope, criterion and impact; speak the brief while a scribe records all four elements; arrange a labelled decision diagram and dictate reasons for include/defer. Other domains: Day 10 swaps after the check. Optional/home: write a two-sentence recommendation for a fictional event page with one limit. Move: if learners recommend a tool because it sounds modern, ask what source detail shows it solves the specified problem. This public check is not a secure exam.