Ask a service team to describe how a citizen completes their service. They will tell you, fluently, in detail. Ask them when they last did it themselves — from a cold start, without insider knowledge, on the live service — and most won’t be able to remember.
This is the gap a Service Walk closes.
A Service Walk is the simplest, cheapest, and most direct research method available to anyone working on a public service. It requires no recruitment, no incentives, no ethics review, no specialist tooling. You can do one this afternoon. And yet most service teams have never done one properly, which is why their internal mental model of the service diverges, sometimes by years, from the experience their citizens actually have.
What it is
A Service Walk is a structured observation of a live service, walked end-to-end by the team that owns it, from the perspective of a citizen attempting the task for the first time.
It is not usability testing. In usability testing, the user is external to the team and the team observes; in a Service Walk, the team is the user. It is not a heuristic review. In a heuristic review, the team evaluates against criteria; in a Service Walk, the team simply records what happens.
The point is not evaluation. The point is to make your own service strange to you. To see it as a citizen would — without the internal knowledge of why each screen is the way it is, what the next page is going to ask, or where the help link actually goes. That defamiliarisation is the entire value of the method, and it is harder to achieve than it sounds.
The non-negotiable: observe, don’t analyse
The discipline of a Service Walk is to record what happens, not to explain why or to propose fixes. This is the hardest part. Teams want, badly, to immediately say “oh, that’s because of the legacy IT” or “we should change that label” or “the policy team made us do that.” Resist. All of it. Every word.
Premature analysis is the most common failure mode of the method, and it ruins the data. Once a team has rationalised a friction point (“oh, that’s because users have to verify identity first”), they stop noticing how much friction it actually creates, because the rationalisation has neutralised it. The whole point is to feel the friction the way a citizen feels it — and a citizen has no rationalisation available.
Analysis comes later. After the walk. With the recording in front of you. Not during.
How to do one
Form a team of three or four. One person plays the citizen. The others observe and record. Mix the team: ideally one researcher, one content designer, one product or service person, and — if you can — one senior decision-maker who needs to see what their service is actually like. Senior participants discover more in ninety minutes of a Service Walk than in any number of dashboards.
Pick a path. Not the simplest one and not the team’s favourite. Pick a real, plausible path that a substantial number of citizens actually take — ideally the most common one, or the one most prone to going wrong. If you have analytics, let them choose for you. If you don’t, pick the path the team is most reluctant to walk. That reluctance is usually a signal.
Walk the service on the live channel. The actual website. The actual app. The actual phone line. Not a staging environment, not a wireframe, not a Figma prototype. The whole exercise depends on the realism of the channel, and a staging environment with placeholder content tells you nothing about what citizens encounter.
The person playing the citizen is forbidden from using any internal knowledge. If they wouldn’t know something as a first-time user, they do not know it now. They cannot use the back-of-house URL. They cannot use the password they happen to remember. They cannot interpret the abbreviation the policy team uses for that benefit. If they need to look something up, they look it up the way a citizen would — by typing it into a search engine.
This rule will feel pedantic for the first five minutes and obvious by the end. Insider knowledge leaks are the second most common failure mode of the method.
What to record at every step
At every screen, page, or interaction, the observers record:
- What did you have to know to get here?
- What did you have to do?
- What were you unsure of?
- Where did you wait, and for how long?
- Where did you feel friction — confusion, re-reading, second-guessing, doubt about whether you’d done it right?
Take screenshots of every step. Number them in sequence. The numbering matters because Service Walk findings are most useful when paired with the exact screenshot they refer to, and unnumbered screenshots become unmanageable within an hour.
The walker narrates. Not loudly, not performatively, but enough that observers can capture the texture of the experience. “I’m reading the eligibility question. I don’t actually know what ‘qualifying income’ means here. I’m guessing it’s my gross. I’m going to say yes.” That kind of running narration is the data.
Resist the urge to clean up the recording as you go. Capture the second-guessing, the misreadings, the small backtracks. They are the friction.
Variants worth knowing
The basic Service Walk has useful variations.
A cold walk is the default: a first-time user attempting the service for the first time. Most teams should start here.
A hostile walk is the same exercise but on a deliberately uncomfortable path. Eligibility failure. Validation error. Time-out. Information you don’t have to hand. Document upload that fails. Most services break far worse on hostile paths than on cold ones, and most teams never look.
An assisted-digital walk has two team members: one playing citizen, one playing helper — a family member, an advocate, library staff, a call-centre agent. Both have to make sense of the screen together. This surfaces an entirely different layer of friction — most government screens are designed for one user, and stop working as soon as a second one is involved.
A mobile-only walk is conducted on a phone with no fallback to desktop. Many services were designed desktop-first, then made responsive, and the gap between the two experiences is enormous and largely invisible from the inside.
A constrained walk introduces a deliberate handicap that mirrors a real user constraint — completing the service on a slow connection, with a screen reader, in a second language, with the screen brightness turned down to simulate vision difficulty. None of these substitute for research with actual citizens who have those constraints, but they raise the team’s awareness of how much the service depends on conditions the team takes for granted.
What tends to go wrong
The insider knowledge leak is the most common problem and the one most worth policing. The walker will, repeatedly, slip into using things they know. Catch it every time. Reset and re-walk if you have to.
Premature analysis is the second. Some teams cannot help themselves. If yours can’t, run the Service Walk as two separate sessions — one to walk, one to analyse, with at least a few hours between them. The gap between sessions gives the recording time to settle and stops the loudest opinion in the room from shaping the data.
Walking the happy path is the third. Teams gravitate to it. Force the choice of path before the walk begins, and don’t let it drift.
Using a developer or admin account is the fourth. Many staff have access to enhanced views — debug menus, internal status overlays, additional metadata — that subtly inform their reading of the screen. Use a clean account, or a fresh device, or both.
Forgetting to record is the fifth. A Service Walk that produces strong opinions but no captured data is a conversation, not a method. Insist on the screenshots and the notes.
What to do with what you found
The Service Walk produces a list of observations. The next step is to code them: each friction point is named with a failure pattern — eligibility cliff, synonym trap, silent wait, hidden mandatory, status black box, shame error, dead end. Naming the patterns turns generic complaints into specific diagnoses, and lets you compare findings across services.
From the coded list, promote the most severe issues into a priority assessment — which ones are worth solving first, given the cost, the reach, and the equity impact of each. Not all friction is equal, and the Service Walk’s value is realised only when its findings are converted into a small number of well-chosen problems to solve.
Crucially, the Service Walk is the input to redesign, not the redesign itself. Resist the urge to leap to solutions during the walk, immediately after the walk, or in the report from the walk. Three different things. Three different sessions.
Make it a habit, not an event
A Service Walk done once is useful. A Service Walk done quarterly, on every live service, becomes the most reliable early-warning system a service team has.
Services drift. Policies change. Suppliers update components. Content gets edited by people who don’t see the whole journey. New regulations get layered on top of old flows. Six months can take a working service and make it subtly broken in ways that no dashboard will surface — but a Service Walk will, immediately.
The Service Walk also has a quiet political use. When stakeholder claims about how the service works don’t match what citizens are saying, a Service Walk reconciles them, fast, with evidence anyone in the room can see. “Here’s the page. Here’s what it asks. Here’s what we didn’t know.” It is much harder to argue with the screenshot than with the user.
The discipline takes about ninety minutes once a quarter, plus an hour to code the findings. Most service teams could do it, and don’t. Be the one that does.