New parking flow
Background
RingGo partnered with WPS Parking Solutions to add a large number of new parking locations that customers to park at and pay through RingGo app. The problem was that most existing locations required opening the app and paying once parked but these locations required paying when ready to leave.
Outcomes
My design ensured users clearly understood when to pay, allowing for a smooth launch that kept the contact ratio low.
Role and collaborators
Sole product designer on the project, working closely with engineers and product managers. Also collaborated with client success managers during discovery and ideation.
Audience
B2C parkers in the UK
Jump to
Problem
A new and unfamiliar flow
RingGo users generally expected to prepay for parking, but new WPS locations would use an unfamiliar pay-on-exit model. This was a problem because users could get confused parking at these new locations, increasing the likelihood of errors and risking negative user experiences. This could impact adoption of the feature and increase customer support contacts.
How most RingGo locations work
In the vast majority of locations, users followed the same flow: selecting a location, choosing a duration, and paying upfront before going about their day.
How WPS locations differ
ANPR (Automatic Number Plate Recognition) captured vehicle details at entry (sometimes receiving a ticket), user went about their day, and payment happened once they returned to their vehicle before exiting the car park.
Discovery
Understanding location variations
I worked with product and engineering to understand the WPS flow and technical constraints. ANPR and ticketed locations introduced new steps that deviated from the usual RingGo process.
We kicked off with a deep dive into WPS parking mechanics and technical requirements. I worked closely with product and engineering to map out the variations:
ANPR with a barrier – Users’ plates were scanned at entry and exit, and payment was required before departure.
ANPR without a barrier – The system still tracked parking duration, but no barrier controlled exit.
Ticketed locations – Users might need to scan a ticket if ANPR failed.
Unlike the typical RingGo flow, users would no longer prepay for a set duration but instead pay the exact amount before leaving. Understanding these differences helped shape a design that balanced clarity with familiarity.
Also, ANPR use wasn’t always clearly signposted in real-world scenarios, so we couldn’t rely on physical signage to guide users.
Ideation
Adapting existing flows
I began by mapping out user flows to visualize key differences. This helped identify areas needing extra guidance and allowed early alignment with product and engineering.
Key design considerations included:
Communicating location type – I revisited an old idea of adding labels to location cards and details pages. Users could tap the label for a breakdown of the parking flow.
Simplifying ticket scanning – Since this step was new to RingGo, I used concise, instructive headings with additional details only when needed.
Ensuring users knew when they could leave – A final post-payment message confirmed that users were ready to exit, preventing uncertainty about the next steps.
Creating visuals for alignment
With wireframes in place, I aligned with product and engineering, then engaged stakeholders working directly with WPS. I’ve found that non-product teams respond best when visuals are available, making collaboration smoother.
Testing
Uncovering an important design flaw
With this being a totally new flow and way of paying, it was vital that I tested my designs with users. So I created a prototype and organised a user testing session with five existing RingGo users who park at least once a month.
Testing goals
Assess usability – Could users complete tasks without issues
Understand expectations – If they saw a RingGo sign at a pay-on-exit location, what would they do?
Gauge post-payment clarity – Did they understand what to do after paying?
Findings
Necessary revisions
Simplified location labels – I standardized all variations under a single label: “Pay on Exit” for immediate clarity.
Added a confirmation step – After selecting a location, users were explicitly asked if they were ready to exit or had just parked, preventing accidental premature payments.
Implementation
Optimising for many devices
After making the necessary revisions from testing, I conducted a final review with product, engineering, and key stakeholders. Additional steps included:
Ensuring Android compatibility – RingGo had a native-first approach to app design so I needed to make adjustments to mockups that accounted for Android UI differences and made implementation clearer for developers.
Optimizing for small screens – A small percentage of RingGo users have very small devices (around 320px) so it was important to check my designs at smaller widths to ensure key actions were easily accessible and developers had clear directions if layout changes were required.
Stakeholder approval – I prepared final design exports for WPS stakeholders, ensuring alignment before implementation.
Outcomes
Post-launch impact
The new pay-on-exit flow was well received, and post-launch feedback indicated minimal confusion around the new process:
No negative app store reviews
Low customer support inquiries
