Overview
A service that was failing the people who needed it most
Camden's PCN service lets residents and visitors view, pay, or challenge parking fines. For many users, it's a high-stakes interaction. Miss a deadline, misunderstand your options, or fail to complete a challenge and the fine increases.
When I joined the team, the journey was split across three separate third-party platforms, each with its own interface, behaviour, and accessibility failures. Users moved between platforms without context, struggled to complete basic tasks, and had no online route for some of the most common issues they faced.
The result was a service that was frustrating to use, impossible to complete for many, and generating avoidable pressure on an already stretched contact centre.
Problem
Three platforms, no joined-up journey, and a contact centre absorbing the consequences
The scale of the problem was visible in the data from the start. Users couldn't complete basic tasks, staff couldn't help when they called in, and satisfaction across the journey told its own story.
Users were forced to choose between paying or challenging before seeing any details about their fine. Those who had lost their PCN number had no online route at all and were forced to call in. Every platform transition brought a different interface, different behaviour, and a different standard of accessibility. The journey didn't feel like one service. It felt like three unrelated ones.
40%
of PCN-related calls were about challenges
98%
of those calls were avoidable
26%
were users needing help to self-serve
2.4/5
Satisfaction score
my role
Leading design across research, strategy and delivery
I led the design work on this project from discovery through to a fully prototyped solution, as the sole designer on a cross-functional team that included a product manager, a data analyst, and a content designer.
The team was set up specifically to improve end-to-end citizen journeys across Camden's website, with objectives set directly by senior leadership.
My responsibilities included:
Research and strategy
—
Mapping the existing end-to-end service across multiple platforms
—
Conducting accessibility reviews and heuristic evaluation of current journeys
—
Facilitating workshops for synthesis, problem framing, and alignment
—
Defining the design approach and interaction strategy
Design and delivery
—
Designing information architecture and key interaction patterns
—
Creating prototypes to test and communicate proposed solutions
—
Advocating for longer-term strategic change alongside immediate delivery needs
—
Collaborating with the content designer on content and IA decisions
Discovery
Getting under the surface
of a broken service
I started by mapping the existing experience end to end, tracing every possible path a user could take from receiving a PCN through to completing a payment or challenge. This meant accounting for all the platforms the journey touched, every decision point, and every place the experience broke down or handed the user off somewhere unfamiliar.
Alongside that I mapped the underlying service process, covering the policy stages, enforcement rules, branching decision paths, and system dependencies that shaped what users could and couldn't do at each stage.
The operational complexity was significant and largely invisible within the interface itself.
Getting a clear picture required working through the service independently rather than relying on existing documentation.
To understand the user side I listened to call recordings, conducted a heuristic evaluation of the current experience, and gathered feedback directly from users through a survey running on the council's website. I also reviewed the existing platforms for accessibility issues as part of this phase.
By the end of discovery I had a clear, evidence-based picture of where the service was failing, why, and what the consequences were for users. The next step was making sense of it all.
Synthesis
Turning complexity into a clear problem to solve
With a substantial amount of research and evidence gathered, the next step was making sense of it in a way the whole team could work from.
I facilitated a series of workshops to theme the findings, working through user feedback, call data, heuristic findings, and accessibility issues together. From these themes I developed problem statements, how might we questions, and hypotheses that would directly inform the design work ahead.
Now adopted as standard practice across the team.
This approach was well received across the team and wider stakeholders, grounding design decisions in evidence rather than assumption. I also presented the full findings at a quarterly show and tell to a wide audience across the organisation, which helped build broader awareness and buy-in for the direction we were taking.
Because we know users who have lost their PCN number are forced to call in due to a lack of self-serve options, we believe that introducing a digital retrieval process and alternative support channels will enable users to stay online and self-serve independently.
In 2024, 17% of calls (151 hours) regarding a PCN were due to a lost penalty charge number.
Introduced an online, digital retrieval process
Added online chat support as a fallback for users who still needed help, without forcing them to switch channels
Reduced frustration
Less reliance on phone support
Users empowered to self-serve
Design decisions
Five decisions that shaped the redesign
A single dashboard for everything that matters
The existing experience scattered information across multiple tabs with no clear hierarchy. Payment was the dominant action on every page, while challenging was buried as a tab that then led somewhere unexpected. Status updates were limited to a single label that rarely reflected reality.
I designed a single dashboard: PCN details, contravention reason, evidence, current status, amount due, and clear actions for paying or challenging. I introduced status labels that reflected the user's actual situation rather than internal system states. I made the discounted price window prominent, along with a live counter showing exactly how many days remained to pay at the lower rate, which I validated with the developer to confirm it was technically feasible. And I worked with the team to rewrite contravention reasons from enforcement jargon into plain language, so users could actually understand why they had received the fine.
Before: information split across tabs, with unclear status and weak hierarchy.
After: PCN details, evidence, status, payment deadline and actions brought into one place.
Redesigning the information architecture
The original journey split paying and challenging into separate paths from the start, assuming users already knew what they wanted to do before seeing any details about their fine. This left users who wanted to understand their situation first with no clear route forward.
I redesigned the IA around a single entry point that surfaces PCN details before asking users to make any decision. There was a concern this would add steps for users who just wanted to pay, but mapping it out showed the opposite. Because users entered their PCN number upfront, it was already removed as a step later in the payment flow, making the overall journey shorter not longer.
Pay for PCN
11 pages without evidence
15 pages with evidence
6 pages with evidence only
Challenge PCN
15 pages
No guidance
Irrelevant questions
12 pages
Guided flow
Relevant questions only
A shared entry point, removed duplicated steps later in both journeys.
A dynamic challenge form
The original challenge form asked every user the same questions regardless of their circumstances, creating unnecessary steps, irrelevant questions, and confusing journeys.
I worked with the Parking team to understand the service rules behind different challenge scenarios, then redesigned the flow to become context-aware, showing only the questions relevant to each user’s situation.
The form adapted to the user, rather than forcing every user through the same journey.
Creating a digital pathway where none existed
Users who had lost their PCN number had no way to retrieve it online. I researched how other councils approached this, spoke directly with a team that had taken a different route, and brought the most promising approach to our legal team. They confirmed it wasn’t viable due to data protection constraints around the evidence attached to each PCN.
Rather than stopping there, I designed an alternative that used contextual validation logic to return the right information based on information already held by the system, without exposing anything it shouldn’t. It removed a key blocker that had been forcing users to call in and created a self-service route where there had been none before.
Advocating for front-end ownership
Every service at Camden procured its own platform based on back-end requirements, each bringing its own front-end experience that we were expected to use. Changes were slow, expensive, and inconsistent. We were always playing catch-up with systems we didn’t own.
I proposed using this work as a proof of concept for decoupling from these platforms entirely, building our own front-end connected to back-end systems via API. The Tech Lead built a proof of concept confirming it was technically viable. The Head of Technology wrote a formal paper on implementation, and the proposal was discussed at senior leadership level. This remains an ongoing strategic conversation.
Some of the biggest design constraints were not interface issues. They were ownership issues.
solution
One journey, one experience, one place to understand and act
The redesigned service brought paying, challenging, and retrieving a lost PCN into a single, consistent journey. Users entered through one place, saw their details before making any decisions, and had a clear path forward regardless of what they needed to do.
The service finally behaved like one connected experience
The dashboard became the heart of the experience. Users could immediately see their PCN details, the reason for the fine in plain language, their current status, the amount due, and the discounted payment window, alongside clear actions to pay or challenge. Everything relevant to their situation was available in one place, without navigating between platforms or repeating information.
Balance not paid
Challenge submitted
Paid
The dashboard adapted dynamically to reflect the user’s current situation, updating available actions, status messaging, and payment information in real time.
Webchat provided a fallback for those needing support without forcing them to abandon the digital journey entirely.
The work was built using the existing design system, with new components proposed and documented where gaps existed so the solution could contribute back to the wider design language.
trade-offs
Navigating constraints without losing sight of the user
Third-party platform constraints shaped every decision. We couldn't control the underlying systems, which meant some of the most important improvements had to be argued for, evidenced, and negotiated rather than simply designed and built.
The challenge form was the clearest example. Accessibility requirements meant it had to work within existing platform constraints, limiting how much the interaction could be simplified.
The discounted payment window counter required developer validation before it could be confirmed as feasible, while the original lost PCN recovery approach had to be redesigned entirely after being ruled out by legal.
Good design decisions still have to survive organisational reality.
The most significant trade-off was scope. The fully redesigned front-end solution remains unbuilt, while incremental improvements and interim solutions were implemented within the constraints of the existing platforms.
It was not the solution I would have chosen given a blank slate, but it was the right call within the constraints we were working in.
Impact
Design work that drove organisational change
Lost PCN support queries transitioned to digital self-serve
Following the introduction of the interim lost PCN journey, adoption of the digital channel increased enough for the contact centre to transition support queries fully to digital self-service, a first for a Camden service.
[PLACEHOLDER: chatbot usage increased from X to X sessions per month / call volumes dropped by X% within timeframe]
From sceptic to advocate
The Parking service had been sceptical about our involvement at the start of the project. After seeing the prototype presented to a wider audience, the Head of Parking met with us to discuss his reservations. By the end of that conversation he had been won over by the evidence and reasoning behind our decisions.
A new way of working
The synthesis approach introduced on this project has since been adopted as standard practice within the project team. A small team of three, with no dedicated developer, is now trusted to define the scope of its own work based on the evidence it produces.
The strategic conversation
The proof of concept work and the front-end ownership proposal continue to inform strategic discussions around service architecture and platform ownership at senior leadership level.
Reflection
What this project taught me
The most valuable work on this project happened before any screen was designed. Mapping the service end to end, understanding the operational complexity behind the interface, and building a clear evidence base created the foundation for every decision that followed.
This project also shifted how I think about organisational change. Good design is rarely enough on its own. Decisions need to be evidenced, communicated clearly, and defended at the right moments to the right people. The shift from scepticism to advocacy from the Parking service happened because the reasoning behind the work was strong enough to withstand scrutiny.
The front-end ownership proposal remains the part of the project I am most proud of. The proof of concept demonstrated what was possible, but the organisational conditions to fully deliver it were not yet in place. If I approached the project again, I would push earlier for dedicated front-end resource to increase the likelihood of shipping the proposed experience rather than only demonstrating it.