Parking fine journey redesign
One user journey across three systems
The online journey for a parking fine, formally a Penalty Charge Notice (PCN), was fragmented across one website and two supplier systems. As the sole Product Designer, I improved the live journey while redesigning and prototyping a consistent end-to-end experience across all three.
Role
Period
Team
Scope
A shared entry point gave users the status, evidence, amount due, deadlines and next actions before asking them to decide what to do.
The situation
Improving individual pages had not fixed the end-to-end journey
The organisation had already improved its public website pages, but some end-to-end journeys still broke apart when users entered supplier systems. Our team was created to tackle those fragmented services, and the PCN journey was one of the priorities.
Mapping the service end to end made the fragmentation visible. Users crossed three different interfaces. The wider evidence also showed inconsistent interaction and accessibility quality, and significant contact-centre demand.
of PCN-related calls in 2024
were enquiries around challenging a fine
We therefore worked at two levels: improve the live journey while testing whether the fragmentation itself had to remain.
Decision 01
A connected journey meant owning the front end
Improving the supplier interfaces could not produce one connected journey. Each system had been procured for its own back-office requirements, so the fragmentation was structural rather than a question of interface quality.
Supplier-side improvements could only ever be temporary. A review can bring an interface closer to current design and accessibility standards, but those standards keep evolving and every change then depends on the supplier.
I proposed owning the user-facing layer instead, connected to the systems underneath. Leadership wanted delivery at pace, so I pursued both: the team kept improving the live service while I designed and prototyped the end-to-end experience the organisation could have if it owned the front end.
Current
Proposed
Two-way data exchange keeps the experience in sync as the case changes.
The proposal moved service stakeholders from early scepticism to supporting further investigation. This prompted a Tech Lead outside the project team to build an API-connected technical proof of concept, followed by a production assessment from the Head of Technology.
Decision 02
Shared context came before choosing an action
A single front end would not fix the journey if it preserved the same action-first logic.
In the existing service, paying was prominent while challenging was buried within tabs, and there was no clear route to review the PCN details before deciding what to do. Users had to click around to understand their case.
I redesigned the information architecture around a shared dashboard, bringing together PCN details, evidence and payment information and surfacing additional information users could not previously see, including meaningful status and the discount deadline.
I confirmed with the service that the underlying system held the data needed to support this. Discovery had also shown users contacting the service for some of this information.
Trade-off
Putting the dashboard before Pay meant one more page before payment for users who already knew they wanted to pay, trading immediate directness for shared context before acting. I compared the complete flows to test whether that made the journey longer overall.
Both proposed journeys were shorter overall.
11–15 pages → 6 for payment
15 pages → 12 for challenging
Decision 03
The recovery model changed, not the decision to build it
Users who had lost their PCN reference had no digital recovery route.
of 2,000 lost PCN calls received in 2024
were recorded as avoidable contact.
My decision was to create a digital recovery pathway rather than treat those calls as inevitable. I proposed a more direct recovery model, which was met with hesitation. I tested whether that constraint was absolute by reviewing comparable services, finding one using the same approach and speaking directly with its team about how they had made it work.
I took that precedent back to Legal but the privacy risk still held, because of the evidence attached to each PCN. I therefore redesigned the route around contextual validation, varying the checks by PCN type, enforcement stage and available information so the right case could be identified without exposing sensitive evidence.
The proposed validation logic changed according to PCN type, enforcement stage and available information, with webchat as a fallback when the case could not be identified confidently.
Outcome
From live service changes to a new front-end direction
01
Reached users
Lost PCN support moved fully to digital. After the lost PCN route with webchat support went live, the dedicated phone path was removed.
The service described the full move to digital self-service as a first for Camden.
Content and information architecture improvements went live. A prioritised usability and accessibility backlog for the replacement supplier platform was accepted for staged implementation, with later releases addressing several of the issues identified.
02
Proved a direction
The API-connected technical proof of concept was followed by a production assessment from the Head of Technology, who recommended progressing the connected model towards an MVP.
03
Changed the conversation
The proposal entered senior-leadership discussions about service architecture and front-end ownership.
The team was subsequently given the larger Permits programme.
What began as an attempt to improve one fragmented journey had opened a broader question about whether the organisation should keep adapting supplier front ends or own the user-facing experience itself.
View next case study