NaPTAN, Department for Transport

Every bus stop, rail platform and ferry terminal in England, Scotland and Wales sits in NaPTAN. When a stop moves, closes or is added, the local authority has to tell DfT. Before this work, that meant emailing an XML file, waiting for someone in the DfT team to validate it by hand, and hoping nothing bounced back.

DfT wanted a service that local authority data managers could use without training, without phone support, and without breaking the live journey planners that depend on the data downstream.

I worked with the product manager and the DfT service owner to frame the outcomes the service had to land. Every design decision had to map back to one of these.

NaPTAN feeds every journey planner, bus app and mapping service used by millions of people across Great Britain. When a stop closes, moves or gains step-free access and the data lags, real passengers feel it. They wait at a stop that no longer exists, plan a connection around a platform that changed, or arrive expecting wheelchair access that is not there.

By giving councils a fast, self-serve way to publish and maintain their stops, the service makes the open data that powers Google Maps, Citymapper and every local bus app more accurate and more current. That means fewer stranded passengers, better accessibility information, and more reliable real-time data for everyone who depends on public transport.

Designing inside government means designing with the people who own the policy, the data and the support load, not just the end user. I ran a stakeholder map early so we knew where decisions actually lived.

I led discovery across 14 local authorities, from large metropolitan councils to small rural ones, plus the DfT team itself. I ran semi-structured interviews, observed real publishing workflows, and analysed every support email from the previous six months to see where people actually got stuck.

Two patterns stood out. First, most data managers were not technical, but the language in the existing process assumed they were. Second, the moment of highest anxiety was not uploading the file, it was the silence afterwards: people did not know whether their data had landed, been rejected, or was sitting in a queue.

Local authorities thought in tasks: download my data, publish a file, remove a stop. The old service spoke in systems. I restructured the homepage around the four tasks people actually came to do, grouped by dataset, so the IA matched the mental model rather than the org chart.

Proximity and common region did the heavy lifting: each dataset became one block, with its task list inside it. Nothing decorative, no orphan links.

I designed end-to-end flows in the GOV.UK Design System, prototyped them, and tested each one with real local authority users. Three flows mattered most: signing in with the right permissions, removing a single stop with safety checks, and publishing a batch of files with clear per-file feedback.

The remove-a-stop flow added three automated checks the old email process never did: is the stop actually in NaPTAN, has it already been removed, and is it still used in any live journey. People could see exactly which check had failed and why, instead of getting a generic rejection days later.

The file report screen was the single highest-stakes page in the service. People wait for it, and they need to know in seconds whether they can move on or whether they have to fix something. I designed two clear states and tested both.

On success, a single green confirmation, the checks that ran, and what happens next. On failure, an error summary at the top using the GOV.UK pattern, the failed check called out in red, the successful checks kept visible so people did not feel they had wasted the upload, and a plain-English explanation of what to do.

Most services have one error page. This one had to handle three very different situations: a network drop, a server problem, and a 20-minute session timeout that deletes the user's answers for security. Each one needed a different message, a different recovery action, and a different tone.

I prototyped all three and tested the wording with users. The session timeout in particular needed to explain why we deleted their data, not just that we had, otherwise people felt punished rather than protected.

In task three of round two testing, I asked five local authority users to upload eleven files using the existing pattern. Every single one tried to drag the whole batch at once, hit the three-file limit silently, and only noticed something was wrong when their data did not appear.

I rewrote the upload page so the limit was stated before the file picker opened, surfaced as an error summary if exceeded, and reinforced in the submit button copy. Round three retested the same task and all five participants completed it without help.

Partway through beta, I picked up a spike to review the accessibility statement page. It admitted the ATCO search component was not keyboard accessible, blamed it on a third-party dependency, and promised a fix that had quietly slipped twice.

Rather than rewrite the statement to sound better, I pushed back. I worked with engineering to actually fix the ATCO search, then rewrote the page to match the GOV.UK accessibility statement pattern: in-scope content, known issues with target dates, and links opening in a new tab signposted in the link text rather than hidden in a tooltip.

It was a small piece of work but it mattered. A government accessibility statement that lies is worse than one that admits gaps honestly, and the GDS assessors notice.

The service moved from alpha into private beta with the pilot authorities. The headline number that DfT cared about was engagement with the publishing tool, because adoption was the gate to wider rollout.

Most of the wins on this project were not visual. They were about the right words at the right moment: the name of a check, the wording of an error, the order of the tasks on the homepage. Gestalt principles helped me group things sensibly, but plain English carried the service.

The other thing this project taught me was that leadership inside a delivery team often looks like a quiet decision to do the harder thing. Fixing the ATCO search instead of softening the statement, retesting the upload flow instead of shipping the first fix, going back to the user when stakeholders disagreed. Small calls, but they compound.