Test one parent task before declaring a school website reviewed
Turn a website checklist into an observed task, a concrete problem and an owned action, using a fictional absence-information example.
A website review can end with many ticks and little evidence about whether a family can use the site. “Navigation reviewed” does not explain where someone became stuck, which wording caused confusion or what will change next.
Use the school website checklist alongside one specific task. Its task record is usable on paper or in your own notes. The purpose is to find a concrete improvement, not award the school a compliance certificate or judge the participant’s ability.
Agree the destination before testing the route
Choose a common, bounded question such as “Find how the school asks families to report an absence.” Ask the responsible school team to confirm the current answer first. Otherwise, a confident route to an outdated instruction might be recorded as success.
Name the start page and the point at which the exercise ends. For this task, stop after identifying the appropriate current instruction. Do not submit an absence report, create an account or use real pupil information merely to test a public information journey.
Give a task without giving away the menu
The government’s moderated usability-testing guidance describes observing people attempting specific tasks and using neutral instructions. It is service-design guidance, not a statutory school website standard.
Ask a willing colleague or appropriate participant: “Imagine you need to tell the school that a child will be absent. Find the school’s instructions.” Avoid “Open Parents, then Attendance”, which supplies the route you wanted to investigate.
Explain that you are reviewing the website, not testing the person. Agree what notes you will keep and avoid recording personal information. A small internal rehearsal can expose a particular problem; it does not establish how every family, including people using assistive technology, experiences the site.
Observe before explaining
Record what happens: which label they choose, where they pause, whether a PDF opens and what they think the instruction means. Keep observation separate from interpretation. “Opened three newsletter PDFs before finding the attendance page” is more useful than “did not understand the website”.
If help becomes necessary, note when you supplied it. A completed route after prompting is different evidence from an unassisted route. Ask what the participant expected a label to mean rather than defending the current design.
A fictional result and a proportionate action
In this invented example, the school’s current instruction is on an attendance page. A participant opens a menu labelled “Information”, then an old newsletter, and finds a superseded email address. The observer points out the current page before anything is sent.
The result is not “task passed”. A useful action is to replace the outdated reference, improve the menu label and ask the office to confirm the final wording. The review should name the owner and a recheck date. It should not claim that changing one label has solved every communication problem.
Keep five fields
- Task and setup: start page, device, checking date and stopping point.
- Expected result: the confirmed destination and why it is current.
- Observed route: the pages or labels actually used.
- Problem or assistance: the exact point at which the route became unclear.
- Action and recheck: the change, responsible person and the evidence needed afterwards.
Run the same bounded task after the change. If the route improves, describe that observed result and its limited scope. Continue the wider checklist for content ownership, accessibility, privacy and resilience. A useful review connects an observation to an action; it does not turn a tick count into a promise about the whole website.