A walkthrough method for government digital services

Whether a government digital service works is judged by whether a citizen can get the thing done, not by whether a website is online. A walkthrough is a relatively low-cost check that can be done early: a trained reviewer takes the citizen's position, follows a task script through the service from start to finish, and notes where they get stuck, hesitate or are likely to make mistakes. This article describes the method we have designed. It is a method note, not a walkthrough report. There are no actual walkthrough results to publish at the moment; they will be released separately once real walkthroughs are finished and the facts have been checked with the relevant agencies.

Starting from real citizen tasks

The unit of a walkthrough is the task, not the page. When choosing tasks, we look at three things: how many people use the service, how much it affects daily life, and whether people are known to phone in or return to the counter to supplement documents. Sources can be the agency's published statistics, common support questions, categories from public inquiry channels, and the experience of front-line staff. We ask staff where citizens most often get stuck, because they see the real cost outside the service.

Tasks are described in citizens' words, such as checking one's own payment record, booking on behalf of a family member, or requesting a replacement certificate, not in internal department names. The same task is also considered for different people: first-time users, people acting for someone else, older adults, people with limited mobility, and people less familiar with the language.

Writing the task script

Each task becomes a script, so results from different reviewers can be compared. A script contains the scenario (who the citizen is, what information they hold, which device), a starting point (a search engine or the agency's portal, never a direct link), the goal (what is to be completed), and the success criterion (what screen or receipt shows it is done).

• Always start the way citizens really would, for example by searching keywords, and not by handing over a URL.
• Scripts state goals, not interface steps, so reviewers find their own route and we can see whether the service is findable.
• Data used is synthetic test data; no real personal information is used.
• Each task is walked at least once on desktop and once on a phone.

What gets checked

During the walkthrough, observations are organised under fixed headings, to avoid relying on impressions. Each heading has observation questions, and reviewers answer yes, partly, no or not applicable, with evidence.

• Findability: whether the right service can be found in a reasonable number of steps from search or the portal, whether its name matches how citizens speak, and whether similar services cause confusion.
• Plain language: whether explanations use words citizens understand, whether legal and administrative terms are explained simply, and whether too much is shown at once.
• Form burden: whether every field is truly needed, whether known data can be prefilled, whether the same proof is requested twice, and whether progress can be saved.
• Accessibility: checks guided by key WCAG items, such as keyboard operation, contrast, text alternatives, form labels, and error messages readable by assistive technology. This is a preliminary check and does not claim conformance or certification.
• Mobile: whether the layout works, buttons are large enough, inputs bring up suitable keyboards, and file upload is feasible.
• Error recovery: whether messages explain the cause and next step, whether entered content is kept, and whether people can go back.
• Identity and verification: whether the method is clear, what the alternatives are when it fails, whether a timeout wipes all data, and whether acting for another person is explained.
• Offline alternatives: whether people who cannot or prefer not to use the online service can clearly find a phone line, counter or other route, and whether that information is correct.

Severity rating

Every finding is graded so that an agency knows what to handle first. Grading follows the effect on a citizen completing the task, not how hard the fix is technically. We use four levels: blocker (the task cannot be completed), serious (it can be completed only with outside help or very high effort), moderate (causes confusion or extra steps that most people can overcome), and minor (small issues of appearance or wording).

Two reviewers rate independently; where they differ, they discuss and record the reason. If a finding affects many people (such as the main entry page) or affects vulnerable users more, this is noted in the rating remarks, but severity is not inflated for that reason.

Evidence and privacy redaction

Every finding carries evidence: a screenshot, the step number, the device and browser, and the date and time of checking. A screenshot should explain the problem on its own; annotation boxes may be added but must not hide the problem itself.

On privacy, the walkthrough uses synthetic data and collects no real citizen data. If personal or internal agency information must appear in a screenshot, it is redacted before saving, in a way that cannot be reversed, not merely blurred, and file names and metadata are cleaned as well. Evidence is stored only in the agreed location, for the agreed period, and handled as agreed at closure.

Reporting to agencies constructively

The purpose of the report is to help improve, not to find fault. It begins with the method and scope, then lists what works well, since agencies need to know which designs to keep. Each problem is described as what the citizen met at which step, with evidence, severity and a possible direction for improvement, separating facts (reproducible observations) from suggestions (our opinion).

• Each finding uses the same fields: id, task, step, observation, evidence, severity, who is affected, suggested direction, agency response.
• Before publication the agency checks the facts; incorrect descriptions are corrected and the agency may add context and constraints.
• No individual staff member is named or judged; only processes and interfaces are discussed.
• The agency decides priorities; we provide a suggested order and a re-test plan.

Limits: a walkthrough is not user testing

A walkthrough is an expert-style review. However careful the reviewer, it is not the same as the experience of real citizens. It may miss real barriers, and may mistake a reviewer's own habits for problems. It cannot say what share of people will fail, and cannot replace user testing with real citizens. On accessibility, a light check cannot replace a full assessment and certainly cannot prove that a service meets any standard.

We therefore treat the walkthrough as early screening and a prompt: it finds places worth looking at more deeply, after which the agency decides whether to run user testing or a formal accessibility assessment. Every report states its scope, the situations it did not cover and the likely biases. Aggregated findings will be published only after real walkthroughs are completed and checked with agencies; until then, no number or conclusion on this page should be read as a finding.

A good walkthrough does not hunt for faults. It walks the road on the citizen's behalf, and honestly reports what it saw to the people who maintain it.