Bill Pay Migration Part 1 - Reducing Payment Anxiety
( 01 )
Business Context
A Fortune 100 financial services firm with two major fintech platforms needed to migrate from Platform B to Platform A’s bill payment experience, while fixing late payment issues affecting high-value clients in Platform A. Surprisingly, it revealed our own team’s fundamentally misunderstood how payment scheduling worked.
( 02)
My Role
Lead designer influencing product strategies in payment scheduling redesign.
( 03 )
Impacts
For Users
Prevented late payment penalties through timely system messages
Improved task completion and higher satisfaction scores
Cognitive load reduced through auto-populated date recovery
For Business
On track for vendor contract deadline without operational disruption
Projected significant reduction in late payment support tickets
Platform consolidation: Single codebase replaced dual front-end systems
For the Team
Logic diagram became team standard for complex feature alignment
Cross-functional velocity improved through early stakeholder alignment
( 04 )
The Core Problem
What was tricky:
When I joined mid-project, the team was confidently executing on a clear solution: "Manual payees get checks that take longer, so show users estimated arrival dates."
But we had a hidden complexity: Two platforms, same backend API, completely different front-end logic.
Platform A's date picker showed three dates:
Delivery date (what users select—when they want payment to arrive)
Send-out date (calculated by system)
Expedited delivery option (with fee)
Platform B's date picker worked differently:
Send-by date (what users select—when to send payment)
Delivered-by date (calculated, e.g., +5 business days)
The team assumed we'd follow Platform B's logic for the migration: Let users pick send date, calculate arrival date as send + 2 days (ACH) or + 5 days (check).
But the math didn't feel right to me. If we have send date AND we're calculating arrival date, that means two date fields. Why would the backend need both?
The real challenge:
This wasn't a user problem—it was a technical misunderstanding about which platform's logic matched the actual backend API.
The tensions:
This wasn't a user problem—it was a technical misunderstanding about which platform's logic matched the actual backend API.
( 05 )
My Strategic Approach
Instead of "How do we show estimated arrival dates based on send date?" I asked: "If we're migrating Platform A's feature to Platform B, shouldn't we follow Platform A's backend logic?"
( 06 )
Discovery & Building Alignment
The team-wide realization:
We'd all been working with the wrong assumption about which platform's logic matched the actual backend behavior.
Designer: "I thought we were using send date..." ❌
Product Manager: "I thought it was send date too..." ❌
Engineers: "We all assumed Platform B's logic was correct..." ❌
Backend API: Payment date is actually payment delivery date. ✓
The revelation:
Platform A's logic: User selects delivery date → System calculates send date ✓ (Matches backend API)
Platform B's logic: User selects send date → System shows delivery date ❌ (Workaround, misaligned with API)
What we almost did: Import Platform B's incorrect logic into the migration ❌
Platform A's logic flow: User selects delivery date → Backend calculates send date → Shows 3 dates (delivery, send-out, expedited)
Platform B's logic flow: User selects send date → Frontend calculates delivery → Shows 2 dates (send, delivered-by)
Backend API truth: Expects delivery date input (Platform A matches, Platform B doesn't)
( 07)
Key Decisions & Tradeoffs
Aligned both platforms' backend logic
Correct the logic: Both platforms now use delivery date (matches backend API)
Clarify the label: "Payment Date" → "Payment Delivery Date" (makes it explicit)
Unify platforms: Single mental model across both platforms
( 08 )
Outcome
It demonstrated:
Technical validation as design practice: Verified backend API behavior before designing front-end logic
Root cause thinking: Found the real problem (Platform B's API misalignment), not just symptoms (user confusion)
Strategic influence: Changed product direction by surfacing technical truth, not just user preference
Cross-functional leadership: Built alignment through evidence (API validation) and visualization (logic diagram)
Systems thinking: One architectural fix aligned both platforms and eliminated category of confusion
The foundation fix eliminated technical debt (Platform B's workaround), user confusion (ambiguous label), and platform inconsistency (different mental models)—a triple win.
( 09 )
What I Learned
When migrating between platforms, don't assume either platform's current logic is 'correct.' Validate which one matches the source of truth—the backend API—before designing. This discovery prevented us from importing Platform B's technically incorrect logic into the migration.
As a new team member, asking 'basic' validation questions created a safe space to uncover a misunderstanding everyone else had accepted. Sometimes being new is an advantage—you can question assumptions without it sounding like blame.
The logic diagram didn't just align the team—it revealed the architectural truth. Visualizing both platforms' logic side-by-side made the API misalignment instantly clear.
DISCOVER MORE
