# Ten 25-minute teacher scripts · Unit 1 Topic 1 starter Read [Teacher Guide](TEACHER-GUIDE.md) once, then pair each day with the matching [clean learner card](LEARNER-CARDS.md). 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](LEARNER-CARDS.md#card-a--rehearsal-room-information-day-1). **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](PRACTICE-SWAPS.md#day-1--need-before-feature). **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](LEARNER-CARDS.md#card-b--a-route-through-an-exhibition-day-2). **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](PRACTICE-SWAPS.md#day-2--user-perspective). **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](LEARNER-CARDS.md#card-c--returns-at-a-repair-bench-day-3) 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](PRACTICE-SWAPS.md#day-3--decomposition). **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](LEARNER-CARDS.md#card-d--a-seed-share-schedule-day-4). **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](print/scope-boundary.pdf) with dictated justifications. **Other domains:** [Day 4 swaps](PRACTICE-SWAPS.md#day-4--scope). **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](LEARNER-CARDS.md#card-e--a-prop-collection-list-day-5-practice), then independently apply the same analysis to [Check A](STUDENT-CHECKS.md#check-a--day-5-fresh-transfer). **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](teacher/KEY-AND-NEXT.md#check-a--day-5) 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](PRACTICE-SWAPS.md#day-5--criteria) 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](LEARNER-CARDS.md#card-f--compare-existing-approaches-day-6), 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](PRACTICE-SWAPS.md#day-6--existing-options). **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](LEARNER-CARDS.md#card-g--who-carries-the-impact-day-7). **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](PRACTICE-SWAPS.md#day-7--impacts). **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](LEARNER-CARDS.md#card-h--new-technology-or-simple-filter-day-8). **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](PRACTICE-SWAPS.md#day-8--emerging-technology). **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](LEARNER-CARDS.md#card-i--criteria-for-an-art-fair-map-day-9). **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](problem-framing-lab.html) 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](print/criterion-test.pdf). **Other domains:** [Day 9 swaps](PRACTICE-SWAPS.md#day-9--test-plan). **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](LEARNER-CARDS.md#card-j--make-a-narrow-recommendation-day-10-practice) into a bounded first-version brief, then transfer to new [Check B](STUDENT-CHECKS.md#check-b--day-10-fresh-transfer). **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](teacher/KEY-AND-NEXT.md#check-b--day-10) 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](PRACTICE-SWAPS.md#day-10--recommendation) 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.