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.
Lead designer influencing product strategies in payment scheduling redesign.
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
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 tensions:
Speed vs. accuracy: Product wanted to move fast; questioning assumptions felt like delay
Confidence vs. curiosity: Team was aligned on Platform B's logic; challenging it risked credibility
Platform migration complexity: Which system's logic is the "correct" one to migrate?
"Can you confirm the backend API behavior? Does it expect send date or delivery date? Because if we're migrating Platform A, I want to make sure we're using the right logic."
What I prioritized:
Understanding which platform's logic matched the actual backend API
Validating assumptions with subject matter experts before finalizing design
What I deprioritized:
Assuming Platform B's current logic was correct
Moving forward with design based on unverified platform assumptions
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)
Aligned both platforms' backend logic, then changed all labels.
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
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.
Technical validation as design practice: Verified backend API behavior before designing front-end logic. As a new team member, asking 'basic' validation questions created a safe space to uncover a misunderstanding everyone else had accepted.
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). 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.
Systems thinking: One architectural fix aligned both platforms and eliminated the category of confusion. When migrating between platforms, don't assume either platform's current logic is 'correct.' Validate which one matches the source of truth before designing.
