↖ ALL PROJECTS
Bill Pay Migration
E*Trade
[
SUMMARY
]
When I joined this project, Bill Pay’s payment logic rested on an unverified assumption inherited from a legacy vendor system, one the team had stopped questioning. I built an end-to-end logic diagram, drove cross-functional validation across engineering, backend, and API teams, and used the findings to align Product Leadership on a corrected delivery-date model. When a late vendor constraint forced a pivot, I authored a two-state architecture, shipping a compliant Interim State while preserving the Target State I had designed.
[
FEATURE 1
]
Catching Payment Method Changes Before They Cause a Late Payment
Sometimes a payment that was supposed to go through electronically can’t be, and has to be mailed as a paper check instead, which takes longer to arrive. Instead of letting users find out too late, this flow catches the change the moment it happens. Right before the payment is submitted, a warning banner explains that it will now arrive by check and shows the earliest possible delivery date. Users can adjust their payment date on the spot, and the confirmation screen repeats the new method and delivery estimate. This way, nobody is caught off guard by a late payment.
[
FEATURE 2
]
A Guided Tour That Introduces What Changed, Not Just What’s New
When the bill pay page got a redesign, existing users needed a quick way to reorient without feeling lost. This four step walkthrough greets returning users, points out that everything they used before is still there, and then walks through what is different: bills are now organized into three simple sections, and users now pick the date they want their payment to arrive instead of the date it gets sent. The last step points people to help resources in case they still have questions. Users can also come back and take the tour again anytime from the main page.
[
FEATURE 3
]
One Consistent Table Across Every Screen Size
The old version of this page looked and worked differently depending on which device someone used, with rows that expanded in confusing ways and information that did not line up the same way twice. This feature rebuilds that experience as one consistent table that adapts cleanly across desktop, a smaller browser window, and the mobile app. Every version shows the same information, the same clear action labels like Edit, Cancel, and View, and the same way of organizing pending and completed payments, so people get a predictable experience no matter how they are checking their bills.
[
MOST MEMORABLE MOMENT
]
Certainty Is Earned, Not Assumed.
A single date field didn’t add up. Nobody could explain why, so I kept asking, even as the newest person on the team. A few weeks in, I noticed a date field claiming to be the day a payment would arrive, while an option beside it arrived even earlier, for a fee. Both couldn’t be true. As the newest person, I could have assumed I was missing context. Instead I raised it, first with the previous designer, then with engineers. Nobody could confirm the logic. So I kept pushing the question up the chain until the real answer surfaced: the two systems we were merging didn’t run on the same rules underneath. I don’t treat a rule as true just because it’s already built. If something is called fixed, I want to know who confirmed that. That question turned an assumption everyone had stopped noticing into something we could verify.
[
PROJECT INFO
]
MY ROLE
Joined the project in mid-August 2025. Partnered with the previous Senior Designer for about a month on Payment Management, then became the primary design owner, independently leading Landing Pages, First-Time User Welcome, responsive design, engineering handoff, and QA.
TEAM
2 PM/PO, 2 engineers, 1 content designer, accessibility consultants, and design leads representing the Morgan Stanley, E*TRADE, and Unified Platform design-system directions.
DURATION
14 weeks
TOOLS
Figma, Jira, testing environments
[
IMPACT
]
This project replaced a dated, minimally customizable vendor experience with a unified Bill Pay system built on verified payment logic rather than inherited assumptions. The work uncovered a mismatch between how Morgan Stanley and legacy E*TRADE calculated payment dates, expanded the scope of check-conversion risk, and translated that logic into a clear risk-communication system. Across the three Landing Page tabs, a fragmented, device-inconsistent table became one consistent interaction model, with unified payee and payment detail entry points and a more accessible table pattern carried across desktop, smaller web, and mobile. A responsive First-Time User Welcome flow guided existing users through what changed, and the full Payment Management flow set was completed end to end. When a late vendor constraint blocked the original delivery-date model from shipping, the response was a deliberate two-state architecture: a compliant Interim State that kept the release on track, and a preserved Target State for the future model switch, so earlier work was not lost.
Building One Consistent Bill Pay Experience Out of Two Banks That Never Agreed on How Payments Work
Confusion is my starting material.
User flow development
Information architecture
Dealing with ambiguity
When this project started, I inherited a payment migration built from scattered screenshots, verbal explanations, and half-finished flows, with no single document tying the logic together. I treated the confusion as material to work with, not a problem to wait out, and mapped the entire payment logic myself within two weeks, tracing single and bulk payments, one-time and recurring types, and every ACH and check branch from scratch. That diagram became the reference the whole team used, updated after every engineering and product sync. I realized that confusion is not the enemy of good design work; it is simply the raw form clarity has not been built out of yet.
Fast is not the same as right.
UX audit & heuristic evaluation
Design decision articulation
Trade-off
As discovery progressed, my manager pushed for a fast, one-to-one copy of the legacy Landing Page, expandable rows and all, straight into the new platform. I pushed back, arguing that rebuilding a pattern the team already knew was confusing, and was already scheduled to be retired, would only create more work down the road. We replaced the expandable sub-rows with a consistent table pattern and unified how payee and payment details opened across every tab. I learned that speed is not the same as progress; if a shortcut just moves today’s problem into next year, it is not actually faster.
Adjusting. Preserving. Building forward.
Feasibility assessment
UX strategy
Roadmap defining
Once the direction became clear, we hit a vendor contract constraint in April 2026 that blocked the delivery-date model I had spent months designing and validating. Instead of discarding that work, I built a two-state architecture, documenting exactly what to subtract for an Interim release while keeping the original Target design intact for a future model switch. The team shipped a compliant Interim State on schedule, and the Target design stayed alive as the confirmed long-term direction instead of becoming wasted effort. I learned that protecting a good decision does not always mean defending it unchanged; sometimes it means finding where it can still live.
