These are fictional web-application problem prompts. They keep the day's analysis target but change the life domain. Pick one if useful; no account or real personal information is needed. Ask learners to cite one given fact and state one unknown. Staff cue answers are separate and public.
Day 1 · Need before feature
- Community chess club: A paper pairing schedule is posted only inside the hall; a member asks for a “live dashboard”. State the pre-travel need and the unverified data-update assumption.
- Ceramics studio: Firing dates are pinned to a noticeboard; someone requests push alerts. State the need without naming a notification feature and name one missing fact.
Day 2 · User perspective
- Local history exhibit: A page says “use the main entrance”; a temporary side entrance is confirmed. Write a first-time visitor question and one user test needed before claiming the page is easy to use.
- Community film night: A page says “collect tickets where you usually do”; the desk has moved to the foyer. Write a need statement for a new visitor without assuming everyone has a phone.
Day 3 · Decomposition
- Shared music stands: Volunteers mark item codes
S-01andS-02on paper when stands return. Draw input → update → web display → human check; name a stale-status risk. - Exhibition labels: Curators approve a new label on paper before a site editor publishes it. Break the flow into four stages and identify the approval gate.
Day 4 · Scope
- Youth art showcase: A team can update opening hours weekly; proposals include current hours, live crowd size, artist biographies and unreviewed translations. Choose a defensible first page and two deferred features.
- Neighbourhood tool fair: A static map is ready; someone proposes attendee tracking and personalised routes without a reason or consent plan. State a scope limit and one question that might justify an additional feature later.
Day 5 · Criteria
- Choir directory: Visitors need to find the rehearsal room in a five-entry list. Replace “simple search” with a paper-trial criterion that names the reader, task and target time.
- Workshop timetable: Volunteers need to spot the current session on a six-row page. Replace “clear layout” with one observable task and condition.
Day 6 · Existing options
- Community mural tour: A printed route card works on site; a static page would help before travel but could be unavailable with poor coverage. Compare both without claiming measured success.
- Book repair day: A web form asks for name and phone; a paper sign gives only hours and place. Identify what information the visitor needs before choosing a form.
Day 7 · Impacts
- Gardening club schedule: A web-only page might reduce paper use but exclude members who rely on the gate notice. Name one affected group and an observation needed before replacing print.
- Small theatre roster: A web page might save coordinator copying time but require weekly maintenance. Describe a possible economic impact without inventing costs.
Day 8 · Emerging technology
- Zine archive: Sixty approved titles already have genre tags. Compare a tag filter with an untested recommendation tool and name an accuracy question.
- Repair-video index: Twenty tutorial clips have human-written category labels. Explain what extra evidence a speech-recognition search would need before deployment.
Day 9 · Test plan
- Paper-lantern exhibition: Visitors need to find Room B on a static page; connectivity is uncertain. Write a reader/task/threshold trial and one offline fallback.
- Fictional climbing club: Members need to find a session time on a static page; updates happen monthly. Specify one criterion and the update-process question.
Day 10 · Recommendation
- Community seed library: A static list is updated every Monday; do not promise live stock. Recommend a first web page, a criterion and an impact to watch.
- Neighbourhood sound walk: A paper route works offline; a static page helps planning, but no live location is needed. Recommend a scope boundary and a missing fact to test.