From a shared Zelle page to its own product

A landing page that technically worked, and a churn problem nobody owned.

Bill Pay shared a landing page with Zelle, so new customers couldn't tell the two products apart. They couldn't find Bill Pay's features, and these new users had the lowest payment submission rate of any Bill Pay user.

40%

Payment submission rate

Lowest of any Bill Pay segment. New users dropped off before completing a single payment.

5×

More likely to complain

Higher call-center rates within 4 hours of initiating a payment, vs. frequent users.

Annual churn

Across frequent and infrequent Bill Pay users. Enterprise monthly report baseline.

These numbers made Bill Pay's new user experience the highest priority surface in Banking Payments. I led the redesign, starting with the landing page architecture, then expanding into onboarding as a parallel workstream.

I owned

Redesigned the IA, landing page, and onboarding flow
The decision to scope the Concept Design out of MVP
Cross-product alignment meetings with Zelle and Transfer leads
Design QA through build with engineering

I partnered on

Research plan and synthesis (with the team's research lead)
Component feasibility scoping (with design system engineers)
PRD revisions (with the Bill Pay PM)
Accessibility review (with the ADA advisor)

We tested twice. Both rounds pointed to the same thing: the shared architecture.

I defined the insight areas, built prototypes for both rounds, and contributed to synthesis. Round 1 was a generative concept study with first-time users. Round 2 was a usability test with 12 participants across new, infrequent, and frequent segments, covering completing a payment, adding a payee, and finding a past transaction. That round hit a 92% task completion rate.

The sharpest finding came from Round 1: every new user described Bill Pay using language borrowed from another product. They weren't failing to use the page. They couldn't identify which part of it was Bill Pay at all. The shared surface made the products look like features of one another.

Concept testing: the shared surface confused first-time users

"This is a lot to process. There's the Zelle stuff, but then there's Bill Pay recipients at the top, at the bottom. It just feels like there's a lot on the screen."

First-time customer, Concept testing, Round 1

Research pointed to two problems: users landed on the page without knowing what Bill Pay was, and the page tried to do too much. The first was why onboarding became its own project alongside the redesign. The landing page alone couldn't fix confusion that started before users ever reached it. The second was about narrowing what the landing page itself should do.

Three functionality focus points for the redesigned landing page

Assist

Help users do the things they do frequently. Surface common actions; hide nothing behind extra taps.

Access

Provide every option, but don't make users hunt for it. Progressive, not buried.

Inform

Ground users in what has happened, what is happening, and what will happen next.

The key design decisions.

01Ran a feasibility check with engineering before the scope became a fight.

The Concept version borrowed patterns from the Direct Deposit Account and Plan & Track teams. It tested better and looked better. Before the formal feasibility review, I pulled in the engineering lead for a quick check on custom-code surface area and API dependencies. It confirmed what the designs were already hinting at: too much custom build-out, unresolved dependencies, and no clear path inside our timeline.

We made the call together to descope it, saving weeks of back-and-forth in sprint planning and giving the team runway to land the MVP cleanly.

Considered vs. shipped Bill Pay landing page

02Replace a single generic pitch with three value props users can hold onto.

The existing onboarding opened with one header and one sentence covering all of Bill Pay's value, broad enough to mean nothing to a first-time user. We explored a full walkthrough: three separate screens, one value prop each. It would have given each message room to land, but every additional screen was another exit point for the segment with the lowest submission rate.

I pushed to keep it on one screen but structure the content as three distinct value props. It gave users specificity without the friction cost: memorable enough to form a mental model, compressed enough to not lose them.

03Move the Payments Due explainer in, not out.

Round 2 surfaced a confusion: every participant misunderstood how Payments Due populated. They assumed it showed every bill they owed, when it only listed payees they'd already added. The risk was real: a user could trust an incomplete list, assume nothing was due, and miss a bill that never appeared there. The default fix would have been a help article. I argued for an inline info icon that explained what the list did and didn't include. It was slight engineering work added to MVP scope, but it closed the gap that would have driven missed-payment complaints. The PM agreed quickly. It's the smallest thing that shipped, and probably the highest-leverage.

Three versions, each narrowing toward what engineering could actually build.

Each version narrowed the design toward what was feasible inside a component system, trading ambition for what could realistically ship.

InitialDense by default

The three principles were applied, but in a barebones way. Every feature was visible, product surfaces visually merged, and horizontal scrolling of payees and activity filters surfaced ADA compliance issues.

ConceptCustom-coded ambition

Borrowed patterns from Direct Deposit Accounts (DDA) and Plan & Track. Bill Pay had its own visual identity, but it was technically infeasible for our timeline: too much custom code and unresolved API issues.

CurrentMDS-native, shippable

Built entirely on off-the-shelf components from MDS, Chase's native design system, with Bill Pay's surface finally separated from Zelle's. More edge cases surfaced along the way, and the MVP is currently scheduled for a customer pilot.

A three-step flow whose only job is the first payment.

Bill Pay had a dedicated onboarding flow, but its welcome screen opened with one generic sentence that could have described any payments product. I restructured the content around three distinct value props: specific enough to stick, and compressed onto one screen so the flow didn't add friction to a segment already struggling to complete.

01Welcome & value

I swapped the original one-line pitch for three value props, each naming something Bill Pay actually does instead of marketing speak. The legal agreement sits up front, and there's just one primary action to take.

02Pick an account

Just one question here. I added a reassurance line, "You can choose a different account later," to answer the "am I locked in?" hesitation that kept coming up in testing.

03Land with momentum

The confirmation screen doubles as a launchpad. Instead of a generic success state, it says "You've set up Bill Pay. Next: add a payee," with the CTA right there, so users carry straight into their first payment.

What we tested, what we'll measure, and where it stands.

Baseline. The evaluative usability round hit 92% task completion. The post-launch framework below builds on that baseline to track whether the redesign holds in production.

Post-launch framework instrumented at launch

Primary

Time to engage

From landing → first interaction

Initiation rate

% of new users starting onboarding

Activation

First scheduled payment within 7 days

Secondary

Send Money flow completion

Measuring drop-off rates

Help-content open rate

Payments Due icon

Re-entry

% returning within 30 days

Guardrail

Channel switch rate

Chase → accessing a different bank

Complaint volume

4-hour post-payment window

Support contacts

Bill Pay-tagged tickets

What shipped, what's next, and what I'd do differently.

#7→#2

Chase app’s J.D. Power ranking, during my time on Bill Pay

The Chase app rose from 7th in 2025 to 2nd in 2026, while I was on Bill Pay and its redesign reached customers. It ranks the whole app, so it reflects many teams’ work, Bill Pay included.

What shipped

MDS-native MVP

On off-the-shelf components inside our timeline. No custom-code debt.

First-payee onboarding

Three-step flow with compressed value props on one screen, closing the activation gap behind the 40% submission rate.

Cross-product alignment

Shared IA vocabulary with Zelle and Transfer, reducing the conflated experience flagged in research.

Measurement framework

Primary, secondary, and guardrail metrics instrumented and ready. First time Bill Pay had a dashboard tied to design intent.

Reflection

The hardest part wasn't the design. It was deciding what not to ship. The Concept Design was more ambitious, but the MVP is the version that reaches a customer opening the Chase app for the first time. It leaned on proven patterns and stayed compliant with ADA guidance, not because it was flashier, but because it was the safer, more accountable bet for that customer. I'd make that tradeoff again.

Two things I'd change. First, I'd start the onboarding workstream before getting deep into the landing page. Every research round pointed there, and I waited too long to make the case. Second, I'd loop in legal from the start, since the onboarding content went through multiple revisions because value-prop claims had to be carefully vetted. Knowing those constraints earlier would have meant sharper content from the first prototype.

The highest leverage decisions on this project were content, IA, and scope.

How I work

My best work usually isn't the design that impresses in a review. It's clearly laying out the tradeoffs so everyone leaves aligned on the same scope. At enterprise scale, that alignment is the real craft.