Guest Payment
My Role
Senior Product Designer
Team
1 Product Owner, 1 Business Analyst, 1 Tech Lead, 1 UX Researcher, 2 Operation Managers, 1 Compliance Manager, and 6 Developers
Timeline
3 months, kickoff to launch
Impact
Estimated $400K+ saved a year · 86% Ease-of-Doing-Business score
The Problem
Customers without an online account, or who couldn't remember their login, had two ways to pay a life insurance premium: a complex phone system or a check in the mail. Payments got lost, due dates were missed, and some policies lapsed.
"You guys are still doing business like it's the 90s."
— Customer, research interview
It was expensive, too. Phone payments were only 0.6% of payment volume, but each one cost $6.69 — 11 times the $0.60 cost of paying online. About 220,000 phone payments a year added up to roughly $1.47 million.
Before the project started, we set a target: at least $400,000 a year in savings.
Research → Direction
I partnered with a UX researcher to interview 10 customers. Four findings shaped the design:
All 10 had forgotten their Prudential login
All 10 preferred paying online over calling or mailing a check
8 of 10 had a partner or adult child pay for them at some point — matching our data, where 27% of payments came from someone other than the policyholder
When a bill arrived, they went to a bookmark or searched Google for "Prudential payments," then checked they were on the real Prudential site before entering anything
Analytics backed up that last finding: about 60% of visitors arrived from a Google search. Competitors also already let customers pay with basic policy details and no login. So the front door mattered as much as the flow: people needed to find the real payment page through search and pay without logging in.
Designing the Experience
Let guests in on their own terms, without hiding the login. Every customer we interviewed had forgotten their login, so paying had to work without one. But the business still wanted account holders to log in, because it's more secure and keeps them engaged. We weighed a separate guest flow against a single page with both paths and chose the single page because it serves both goals. Both paths get equal visual weight, and the login side lists the benefits of an account. Since most visitors came from Google, we also optimized the page for search with the Pru.com team.
Verify against what's already on the bill. People start with the bill, and many payers aren't the policyholder. After reviewing three options with stakeholders and Compliance, we chose two fields printed on the monthly bill: the policy number and the insured's last name. A family member paying for a parent can usually remember the last name because they share it. After launch, 97% of people who reached this step completed it.
Show just enough to pay. With the bill in hand, getting to this page is easy. So for security, it shows only what's needed to pay — the amount, the due date, and the default payment frequency — and no sensitive customer or policy details.
Validating with Users
Before launch, we ran an unmoderated click test with 50 participants:
90% understood there were two ways to pay — the core risk of the landing page
Every participant said the information shown was enough to pay with confidence, even with so little on the page
Results
An estimated $400,000+ saved per year as of March 2026, above the target — based on guest payment traffic, at $6.09 saved for each payment moved from phone to online
86% Ease-of-Doing-Business score, against a team benchmark of 80%; the score reflects a top-tier experience at Prudential.
What I'd Do Differently
Bring Compliance in earlier. We brought them in once the design was ready, then spent real time getting them up to speed. Involving them during exploration would have built buy-in faster and saved a lot of back-and-forth.
Plan the measurement with the target. We set a savings target, but not how we'd track it, so after launch I worked with the Product Owner to define the measures and gather the data. Next time, I'd also track logins from day one to see whether the guest path pulled account holders away from logging in — the risk the landing page was designed around.
