Simplifying a high-volume policy payment
Role
- Product Designer
Team
- 1 product owner
- 1 designer
- 1 business analyst
Timeline
- Jan 2025 – Mar 2025
Overview
Project context
Policy payment was one of the most frequently used features in Prudential's PRUServices app, allowing policyholders to pay their premiums online. The journey looked simple on the surface: select a policy, choose a payment method, and confirm. But the first step carried complex policy terms, payment rules, eligibility states, and amount-editing behaviour.
Problem
The live flow had already been used by customers, so the redesign could not change behaviour too aggressively. The main issue was clarity: customers had to select a policy while also understanding payment amount, due date, status, auto-deduction information, and editing options.
Business goal
Create a clearer payment baseline for PRUServices without disrupting the live version behaviour customers already knew.
My role
I reviewed the existing Malaysia flow, identified clarity issues in the policy selection step, and redesigned the experience across desktop and mobile. I worked closely with the product owner, BA, and developers to align business rules, interaction behaviour, and implementation details.
Why this matters
Payment was too critical to redesign casually
For many customers, payment was the main reason to use PRUServices. Stakeholders highlighted that policy payment represented around 70% of Malaysia transactions. If the redesign made the journey harder, the risk was not just poor usability, it could mean missed payments, overdue policies, complaints, or more support calls.
So the goal was not to reinvent the flow. It was to improve clarity without disrupting a behaviour customers already knew.
Tradeoff
Explored a cleaner flow, then traded it off for familiarity
I explored separating policy selection from amount editing. The first page would focus only on choosing policies, while the next step would let customers review and edit the payment amount. This reduced cognitive load, but it also changed the live Malaysia flow more than needed.
Since amount editing was a low-usage action, the Malaysia product owners decided the extra step was not worth the rollout risk. So I kept the familiar single-step model and focused on making the existing behaviour clearer.
The final direction was not to add more steps, but to make the existing flow clearer.
- focused flow
- clearer policy card
- lighter amount editing
Focused flow
Made payment feel like a focused task
Previously, payment sat inside the main product page with global navigation still visible.
I moved it into a full-screen dialog pattern, following our design principle for multi-step journeys: keep customers focused, reduce distractions, and lower the chance of accidental context switching.
Clearer policy card
Redesigned the card around hierarchy
- grouping the policy name and policy number
- reducing the top section to key policy details
- moving the payable amount to a more prominent position
- changing the amount breakdown into a vertical invoice-like layout
- adding a clearer select button
The card became easier to scan without removing important payment details.
Lighter amount editing
Made amount editing feel lighter
In v1, editing the payment amount opened a separate page.
For v2, I moved amount editing into a modal. This kept users in context while still supporting customers who needed to adjust the payment amount. It improved a low-usage but complex action without changing the main payment journey.
Responsive design
Final design across desktop and mobile
The payment flow was designed for both desktop and mobile. On mobile, the experience became a focused step-by-step journey, covering policy selection, payment method selection, and confirmation.
Reflection
What I would improve today
Looking back, I would define success signals earlier. Beyond redesigning the flow, I would track practical indicators from real usage: payment completion, modal usage, drop-off by step, error recovery, and support questions related to amount editing.
This project taught me that payment UX is not only about reducing steps. In a live, high-volume journey, the safer improvement is often making existing decisions clearer while protecting behaviours customers already trust.