# Teacher guide · problem framing before a feature list

**Use one consistent technology context:** web applications. The ten fictional cases move across music, public exhibitions, repair, gardens, art and community services so learners can transfer the *same* analysis, but the proposed digital context stays web. Schools may select another QCAA-permitted context and adapt the examples; do not claim this starter covers all contexts or programming features.

## Routine for a 25-minute block

Give the two- or three-sentence source on the learner card. Ask: **Who is trying to do what? What blocks them now? What information would we need before building?** Insist on a source detail for each claimed problem. Model a diagram or table, then offer the three routes. Collect one short product: a need statement, decomposition, scope decision or criterion. Ask “How would we know?” to make a criterion observable. Finish by naming one untested assumption.

**Equivalent routes:** a written table, a spoken explanation with exact points captured by a scribe, and a labelled diagram or movable paper strips with a dictated rationale all demonstrate the same target. Let learners switch routes each day. A visual route must retain captions; a spoken route needs recorded reasoning. Do not sort students into fixed learning-style groups. Quiet reading, teacher read-aloud, a screen-reader text copy and extra time are legitimate access adjustments.

## Keep the analysis disciplined

- A feature (“add live stock”) is a proposal, not the user's need (“know whether a copy is at the desk”). Ask whether the required data exists and can be updated.
- A user perspective is a *hypothesis* unless a real user has confirmed it. The fictional cards are design exercises, not research evidence.
- Separate **must work**, **could help**, and **out of scope**. Make trade-offs visible. A small paper-based process may be more appropriate than a web app for some cases.
- A success criterion should specify an observable test and a condition: “In a paper trial, a reader finds the updated room in under 20 seconds using the page” is more testable than “easy to use”. Do not present classroom trial values as real outcomes.
- For impacts, name a mechanism and a group: a web-only page may reduce printing yet exclude visitors without connectivity. Do not declare a net benefit without evidence.
- Emerging technology is not a compulsory solution. Compare a simple labelled filter with a machine-learning suggestion when the data, risk and workload justify discussion. Do not claim a model was trained or accurate.
- Avoid collecting names, contact details, diagnoses, location histories or actual learner information. The offline lab stores nothing and uses only prewritten fictional facts.

## What to prepare

Print [need-map](print/need-map.pdf), [scope-boundary](print/scope-boundary.pdf), [criterion-test](print/criterion-test.pdf), [impact-lens](print/impact-lens.pdf) or [decision-grid](print/decision-grid.pdf) when helpful; each has [full text and tactile build directions](print/TEXT-ALTERNATIVES.md). Put a few scrap-paper strips on each table. The [problem-framing lab](problem-framing-lab.html) is optional on Day 9; its paper route is on the page and in the learner card. No specialist software is required for this starter.

## Check and feedback

The [Day 5 and Day 10 checks](STUDENT-CHECKS.md) use new cases. The [key](teacher/KEY-AND-NEXT.md) is public, so collect first responses before feedback; adapt a case if prior key access matters. Respond to the reason, not just the chosen label. This is informal classroom feedback and is not an A–E or QCAA result.