Overview
A new platform, procured before design was involved
Camden Council introduced a third-party payment platform to consolidate online payments across every council service, covering over 100 distinct journeys from Council Tax to parking charges to housing rent.
The platform had been procured before design was involved. The supplier presented it as accessible and ready for use. There was no audit, no evidence, and no user testing to support that claim.
Given the fixed timeline and limited room for structural redesign, I led an accessibility and usability evaluation to establish whether users could complete payments independently, and to identify the risks Camden would be accepting before go-live.
challenge
A constrained brief, with real consequences
Several conditions made this more complex than a standard evaluation.
Third party platform
Limited control over core interactions, underlying components, and embedded Stripe elements.
100+ payment journeys
High risk of inconsistent behaviour, edge cases, and fragmented experiences across services.
Fixed go-live deadline
Evaluation had to be structured, prioritised, and actionable from day one.
Public service consequences
Failed payments meant lost revenue, exclusion from essential services, and greater pressure on phone and in-person support.
The supplier remained confident the system was ready. The evaluation needed to replace that assurance with evidence, and make the real level of go-live risk clear.
my role
Sole designer, leading the evaluation end to end
I was the only designer on this work, leading the evaluation from planning through to sign-off while also carrying my core project responsibilities.
The work began before the evaluation itself. The original intention was to redesign the payment journeys, so I started by mapping over 100 journeys to understand the landscape. When timelines made a redesign unfeasible, that mapping still shaped how I structured the review.
Shaping the scope
—
Mapped over 100 payment journeys
—
Identified journey types, entry points, amount behaviours, and payment patterns
—
Used the mapping to shape representative test coverage
Leading the evaluation
—
Defined evaluation criteria and test scenarios
—
Tested accessibility and usability across devices and edge cases
—
Logged, prioritised, and escalated findings
—
Managed supplier review conversations
—
Retested fixes and supported go-live decisions
Approach
Building a framework before testing a single journey
Framing evaluation around user needs
Instead of assessing the platform only against a standard compliance list, I defined a set of user needs specific to payment journeys, drawn from existing user feedback, observed behaviour in related council services, and established expectations for completing online payments.
A flat list of issues can be debated, deprioritised, or reframed as technical fixes. Mapping findings to user needs made the risk clearer: if a need was unmet, the question became what users could no longer do, and what the organisation was accepting by going live.
Mapping the testing landscape
To get representative coverage across 100+ journeys without testing each one individually, I identified the key variables that changed how users experienced a payment, then structured testing around those variables.
Amount type
Different amounts triggered different validation, fees and edge cases.
Examples:
—
Fixed amount
—
Variable amount
—
£0.00
—
High value
Entry point
Where a journey started changed the context and data passed through.
Examples:
—
Service page
—
Direct link
—
Account area
—
Email link
Payment method
Each payment method introduced different fields and validation points.
Examples:
—
Card
—
Apple Pay
—
Saved card
—
Stripe element
Device
Layout, interaction and accessibility behaviour changed by device and browser.
Examples:
—
Desktop
—
Mobile
—
Keyboard
—
Screen reader
Outcome
Testing had to cover success, failure and recovery states.
Examples:
—
Success
—
Validation error
—
Declined payment
—
Session timeout
Defining what to test and how
Before testing began, I documented the scenarios to cover, the methods for each, and what I would be looking for as evidence.
Building the issue log and severity model
I designed the issue log from scratch so every finding could be filtered, prioritised, and traced. Each issue was mapped to the journey, device, issue type, relevant WCAG criterion, screenshot evidence, severity, status, and the user need affected.
Expert review
Task walkthroughs
WCAG 2.2 AA
Keyboard
Screen reader
Mobile
Error and edge cases
Prioritising by user impact
To turn findings into launch decisions, I introduced a severity model defined by consequence to the user rather than technical severity alone.
Go live blocker
Prevents task completion or creates legal, regulatory, or financial risk.
Users cannot complete payment
No confirmation or receipt
Legal / compliance exposure
High
Major usability or accessibility barrier that affects user success or confidence.
Critical content not accessible
Confusing or misleading error
Loss of user input
Medium
Causes confusion or friction that could lead to errors or abandonment.
Unclear instructions
Inconsistent behaviour
Extra steps / unnecessary frictions
Low
Minor usability issue with limited impact on task completion.
Cosmetic or content issue
Low clarity text
"Nice to have" improvement
key findings
Where the experience broke down
Testing identified four recurring patterns of failure across the payment journeys. These were not isolated incidents. They appeared consistently across different journeys, devices, and user scenarios.
Task completion failures
Some payment flows entered states that prevented users from completing transactions entirely.
In one preselected amount flow, the system displayed a total of £0.00 despite a valid quantity being entered. Attempting to correct it produced an incorrect total rather than replacing the value, and once edited, the primary action button disabled itself with no explanation. The only way out was to abandon the session and start again.
This combined task completion failure with financial risk. A user who did not notice the incorrect total could have paid significantly more than intended.
The interaction combined task failure with financial risk. A user could be blocked from paying, or pay significantly more than intended.
Short clip showing how the amount field entered an unrecoverable state during testing.
Accessibility gaps at critical moments
Several issues blocked users relying on assistive technology at the moments that mattered most:
—
Payment confirmation not announced to screen readers
—
No reference number presented after a successful payment
—
Focus moved directly to an unrelated action
—
Saved cards could not be selected by screen reader users
For someone who could not see the screen, this meant there was often no reliable way to know whether a payment had succeeded, or to complete the payment independently.
Poor error handling and recovery
When things went wrong, the system frequently failed to explain what had happened or how to recover.
When a session expired, the timer continued to show time remaining while submission returned a generic internal server error, with no explanation that the session had ended and no clear way forward.
Confusing interaction patterns
To submit a payment, users first had to complete an intermediate step that sits mid-page and is typically associated with adding multiple items to a basket, not completing a single payment. Users who had entered all their details correctly found the primary action unresponsive, with no explanation why.
This was flagged during the review as a usability risk. It was not addressed before launch, on the basis that it fell outside the agreed accessibility scope.
Users could complete the visible payment form, but the primary action remained unavailable because an unclear intermediate "Add line" step had to be completed.
trade-offs
Working within constraints that could not be designed away
Evaluation, not redesign
The original ambition was to redesign the payment journeys from the ground up. Procurement timelines made that impossible before design was even involved. The evaluation was the scope that was achievable, not the scope that was ideal. An evaluation can identify what is wrong. It cannot always change what gets shipped.
Accessibility scope versus usability risk
The agreed scope was accessibility. That gave the work legal weight and a clear basis for escalation, but it also gave the supplier a boundary to deprioritise usability issues that carried no equivalent obligation.
A payment journey can be technically accessible and still fail users.
The post-launch complaints proved the point. The issues that went live unresolved were the ones that fell on the usability side of a line that exists for legal reasons, not human ones.
Platform and supplier limits
Throughout the review, the supplier continued making configuration changes to the test environment, altering interaction patterns and requiring affected scenarios to be retested. I escalated this formally and requested a stable environment for the remainder of the review. The instability added pressure to an already tight timeline.
Two go-live blockers remained unresolved because they sat within Stripe infrastructure rather than the supplier’s own code. The decision was made to document them in the accessibility statement rather than delay launch, and those issues remained open.
Impact
Evidence that changed decisions, before and after launch
102
100%
What resolving the critical issues meant
For council services, inaccessible payment journeys do more than create frustration. Residents cannot choose another provider for Council Tax, rent, or parking charges. If they cannot complete a payment online, the consequences can include debt recovery, penalty charges, enforcement, or reliance on assisted digital support.
Resolving the critical issues before launch reduced the risk of excluding users from services they had a legal right to access.
What the evaluation couldn't fix
The usability issues deprioritised as outside the accessibility scope went live unresolved. Their impact was not theoretical.
These were exactly the scenarios flagged during the evaluation, documented, escalated, and set aside. Post-launch, the same issue came back to the team for resolution.
Recognition
"This is such a great example of how we should be working. It's fantastic to see the thought and care that has gone into putting the user first."
-User Experience Lead
-Lead UX Designer
The approach was recommended for wider internal sharing as an example of how supplier-led platforms should be evaluated before launch.
Reflection
What this project confirmed
This was the second time in a short period that a platform had been procured and gone live without meaningful design involvement at the point of selection. The PCN project had already made the case for owning our front end. This project showed what happens when that argument has not yet been won. Until it is, design involvement at the point of procurement, before platforms are chosen and deadlines are set, is the next best safeguard.
It also confirmed how I work under pressure. The timeline was tight, the supplier relationship was difficult, and the finish line was clear. It would have been easy to quietly reduce the scope without anyone seeing the full extent of what had been left untested. But the point of the work was to understand the real risk to users, not to get through the review. So I didn't cut it short.
The usability issues that went live unresolved were the clearest lesson. They were documented, escalated, and set aside because they fell on the wrong side of a boundary.
The line between accessibility and usability is a legal distinction, not a human one.
If I could do one thing differently, I would have completed the synthesis. A numbered list of issues showed what was fixed. Mapping findings back to user needs would have shown something more important. Not what was fixed, but what was accepted.