01 — The Problem
Points you earn paying for travel, you couldn't use to pay your bill
Chase credit card customers earn Ultimate Rewards points on every purchase —
but when it came time to pay their card bill, those points were useless.
You could pay your statement balance with a bank account. You couldn't
apply points. Not even partially.
The constraint isn't arbitrary: you can't pay a credit card bill with a
credit card. But a bank account plus points? That's two completely valid
funding sources — and the system treated them as incompatible.
Why this context matters for the design
Unlike other payment contexts, bill pay has a fixed, known amount —
the statement balance — and a well-understood set of funding options.
The constraint (no CC-to-CC) actually clarifies the problem: the only
tender pair that makes sense is a bank account plus UR points.
That tight scope made MVP tractable, and shaped every design decision
that followed.
$2.55B
in split Points + Credit Card transactions via Travel in 2023 — the appetite was proven
100%
of prior usability participants expected one-step split — it was table stakes, not a differentiator
0
existing ways to apply UR points to a bill payment — the gap was complete
02 — Defining the Scope
Constrained by design, not by accident
The MVP scope was tight — deliberately. Rather than trying to solve split
tender for every context at once, we focused on the bill pay journey,
where the tender pair was already determined by the constraints of the
product: a Chase DDA account, combined with Ultimate Rewards
points from the card being paid.
Aligning on what was explicitly out of scope was as important as defining
what was in. Several items that users might reasonably expect — external
accounts, available credit surfacing — were decisions that needed to be
made explicitly rather than left open.
UR Points as a tender source (dollar value entry with real-time points equivalency)
In scope
Internal Chase DDA / checking account as second tender
In scope
Toggle-activated split mode, revealing inline on the same screen
In scope
Real-time remaining balance calculation (DDA auto-fills after points entry)
In scope
External bank accounts (Wells Fargo, etc.) as a split tender source
Deferred
Available credit surfacing in the payment method selector
Deferred
Credit card as a tender source (structurally impossible for bill pay)
N/A
External accounts appeared in the method selector as an option ("Wells Fargo
Everyday Checking" was visible in early flows) but were explicitly out of
scope for the split path in MVP.
03 — The Design
A mode change, not a new page
The core design decision was how split activates. The answer: a toggle
that changes the payment form into split mode — inline, on the same screen,
without losing the context of what's being paid or for how much.
When split is off, the user sees a standard account selector. When split
is toggled on, the UR points tile appears — a distinct input component
that lets users enter a dollar amount, with the points equivalency
updating in real time beneath it. The bank account row stays, and
automatically updates to show the remaining balance as the user enters
their points amount.
Points entry: dollars first, points always visible
Users enter a dollar amount — not a raw points number. The points
equivalency updates live as they type ("Redeeming 5,000 of 20,000 points")
so they always know the impact without doing any conversion math themselves.
The system resolves the tension between "I think in dollars" and "I want
to know my points balance" by showing both, in real time.
✦ Ultimate Rewards® points (…4555)
Redeeming 5,000 of 20,000 points
The DDA row as the system's half of the math
After the user enters their points amount, the DDA account row auto-fills
with the remaining balance. The user declared their intent — how much
points to use — and the system completes the equation. The review screen
confirms the full split before submission: two line items, one total,
no ambiguity.
1
User selects their DDA account, then enables the split toggle
The UR points tile appears inline beneath the account selector. Available balance shown on each row for confidence.
2
User taps the points tile — numberpad appears
Dollar entry with live points equivalency. Amount is capped at available points balance. "of $200.00" shows the ceiling at all times.
3
DDA auto-fills with the remainder
As the user enters a points amount, the checking account row updates instantly. Total payment always equals the statement balance.
4
Review screen confirms the full split before submission
"Does everything look OK?" — both sources itemized, total confirmed, one CTA to submit.
04 — Usability Testing
What the research confirmed — and what it challenged
We ran usability testing on the MVP design before shipping, generating
20 key insights across the experience. The findings split cleanly into
what was working, what needed immediate correction, and what to carry
into future planning.
What was working
✓
Points-to-cash equivalency eliminated mental math.
Users appreciated seeing the dollar value and points count update
simultaneously. The dual display resolved the tension between
"how much am I spending?" and "how many points am I using?" without
requiring users to hold either number in their head.
✓
The toggle was understood as a mode change.
Users correctly interpreted the toggle as activating a distinct split
payment mode — not just showing additional options. The "mode change"
mental model came through clearly, validating the design approach.
✓
Manual points entry gave users the control they wanted.
Users valued the ability to set their own points amount rather than
having the system allocate for them. Partial redemption — using some
but not all available points — was well understood and appreciated.
✓
Account balances on each row reduced anxiety.
Seeing available balance alongside each payment option helped users
make confident decisions without switching to another app to check.
This was especially valued for avoiding overdraft concerns.
What needed to change
!
The split toggle wasn't prominent enough.
Some users missed it. The toggle blended into the payment form rather than
standing out as a meaningful feature entry point. It needed more visual
weight — not just as a control, but as an invitation to a distinct capability.
!
Inconsistent selectors created confusion.
The design used both radio buttons and a quick-select pattern in
different parts of the flow. Users noticed the inconsistency.
One selector type needed to win throughout the split experience.
!
Notifications needed to be context-aware and actionable.
Insufficient funds warnings that included a suggested corrective action
("try paying $X instead") were highly valued. Passive warnings that
just flagged a problem without offering a path forward frustrated users.
05 — What Changed
The research-to-decision translation
The usability findings were synthesized into a formal Continue / Change /
Consider framework — a structured way to separate what to protect in the
shipped design, what to fix immediately, and what to carry into future
planning without letting it delay the current release.
Always show points-to-cash equivalency in real time — eliminates mental math and increases confidence
Use a toggle as the mode-change mechanism — users understood and accepted it as the signal that split was activating
Provide actionable, concise messaging about available funds and remaining balance at each step
Use list view for the account selector — scan-ability was critical for informed decision-making
Let users manually enter their desired points amount — control over partial redemption was valued
Increase the visual prominence of the split toggle — users missed it; the entry point needs to be an invitation, not a footnote
Remove the inconsistency between radio buttons and quick-select — use one selector pattern throughout the split flow
Make all error notifications context-aware and actionable — insufficient funds warnings must include a corrective path, not just a flag
On Web: implement split in the full container view only — not in the dropdown; the dropdown doesn't support the necessary interaction pattern
Surface account balances across all payment methods — users wanted this for every option, not just the split path
Explore simple animation for the split toggle activation — the mode change is novel; motion can communicate the transition faster than copy
Use approachable, non-urgent tone for notifications — "Heads Up!" tested better than warning-style language for non-critical information
The "Consider" list didn't just inform future design — it became the
seed of the V2 brief. Auto-allocation across more than two accounts,
broader account type support, and animation to communicate mode changes
are all open questions V3 is now investigating.
06 — Outcome
Shipped in employee pilot
20
Usability insights synthesized into a structured Continue / Change / Consider framework
Live
Employee pilot — Chase's first bill pay split tender experience in production
iOS
First platform shipped; Web implementation scoped to full-container view only
MVP is now in employee pilot — the final validation gate before broader
rollout. It ships the core of what users said they needed: one-step split,
manual points control, real-time equivalency, and a DDA that fills itself.
The toggle prominence and selector consistency changes from the "Change
immediately" list were incorporated before launch.
Success metrics tracking: transaction count and dollar value of split bill
payments, completion rate versus abandonment at the points entry step,
and error rate on the insufficient-funds state. These metrics are designed
to tell us not just whether split is being used, but where it's breaking
down — feeding directly into V2.
07 — What's Next
V2: When the constraints come off
MVP worked precisely because the problem was constrained: one context
(bill pay), one tender pair (DDA + UR points), one platform (iOS first).
V2 asks what happens when you remove those constraints — and whether
the design model holds.
The V2 scope is genuinely open: other payment contexts beyond bill pay,
external accounts as tenders, cards where structurally applicable,
and more than two funding sources in a single transaction. That openness
is what makes V2 a different kind of design problem — and why it began
with a feasibility spike rather than a design brief.
The feasibility spike
Before any V2 design could start, the team needed answers to a set
of technical and regulatory questions that MVP's constraints had made
irrelevant. I structured the spike as a set of investigation areas
grounded in specific user-facing behaviors — so engineering and compliance
could evaluate feasibility in context, not in the abstract.
V3 — Design spike in progress
Key questions the spike is answering
Each item below is an investigation area with a feasibility verdict:
feasible, feasible with constraints, or not feasible for MVP.
Can the split panel support N tenders without redesign — just configuration? (N-ready row model)
Does auto-fill logic hold for 3+ tenders, or does it need a "Fill remaining" escape valve?
Can external accounts (Wells Fargo, etc.) be included as tenders — regulatory, compliance, and settlement timing constraints?
Where credit cards can be a tender source (non-bill-pay contexts): what are the risk constraints?
The "Consider" items from MVP testing — auto-allocation, broader account
types, animation — are now formal V3 investigation areas. MVP didn't just
ship a feature; it generated a structured brief for what comes next.