Zelle is a peer-to-peer payment network owned by Early Warning Services, a consortium of major US banks. When Fifth Third Bank integrated Zelle into their consumer mobile app, it represented one of the bank's most prominent public-facing mobile feature launches to date. For a lot of Fifth Third customers, this would be their first meaningful mobile payments experience with the bank.
The stakes were high and the timeline was tight. We ran as a lightweight scrum team, moving fast on a feature that would be visible to a very large consumer audience.
The Constraints
Three constraints defined this project before design started.
First, Zelle's corporate UX requirements. Early Warning Services published a 98-page User Experience Guide that specified exactly how the integration had to work. Flows, layouts, labeling, button behavior, motion, color, typography. Requirements were categorized as Core, meaning mandatory and non-negotiable, Flexible, meaning adaptable within limits, and Optional. The document was thorough to the point of being restrictive, and several of its Core requirements conflicted with what we knew would make a better experience inside Fifth Third's app.
Second, Fifth Third's internal mobile design system at the time of project kickoff was not well suited for a feature of this nature. The contact list and contact card components the Zelle integration required simply did not exist in a form that would work.
Third, the timeline was fixed. There was no room to relitigate scope.
Before designing anything, we audited how other financial institutions had already integrated Zelle. Understanding where they had succeeded, cut corners, or simply accepted Zelle's defaults without pushing back gave us a clear picture of what good looked like and where the bar had been set.
Three constraints defined this project before design started.
First, Zelle's corporate UX requirements. Early Warning Services published a 98-page User Experience Guide that specified exactly how the integration had to work. Flows, layouts, labeling, button behavior, motion, color, typography. Requirements were categorized as Core, meaning mandatory and non-negotiable, Flexible, meaning adaptable within limits, and Optional. The document was thorough to the point of being restrictive, and several of its Core requirements conflicted with what we knew would make a better experience inside Fifth Third's app.
Second, Fifth Third's internal mobile design system at the time of project kickoff was not well suited for a feature of this nature. The contact list and contact card components the Zelle integration required simply did not exist in a form that would work.
Third, the timeline was fixed. There was no room to relitigate scope.
Before designing anything, we audited how other financial institutions had already integrated Zelle. Understanding where they had succeeded, cut corners, or simply accepted Zelle's defaults without pushing back gave us a clear picture of what good looked like and where the bar had been set.
Pushing Back On Zelle
The natural instinct when handed a 98-page requirements document from a corporate partner is to treat it as a ceiling. We treated it as a starting point.
Several of Zelle's Core requirements added unnecessary steps to flows that could be streamlined. Certain layout mandates made sense in the context of the standalone Zelle app but created friction when integrated into an existing banking application with its own navigation patterns and user expectations. We documented our objections, made the case for each one, and submitted them through Zelle's certification process.
We won the vast majority of those arguments. What had been classified as Core requirements in several areas were reclassified as Flexible, giving us room to design flows that felt native to Fifth Third's app rather than bolted on from outside.
The natural instinct when handed a 98-page requirements document from a corporate partner is to treat it as a ceiling. We treated it as a starting point.
Several of Zelle's Core requirements added unnecessary steps to flows that could be streamlined. Certain layout mandates made sense in the context of the standalone Zelle app but created friction when integrated into an existing banking application with its own navigation patterns and user expectations. We documented our objections, made the case for each one, and submitted them through Zelle's certification process.
We won the vast majority of those arguments. What had been classified as Core requirements in several areas were reclassified as Flexible, giving us room to design flows that felt native to Fifth Third's app rather than bolted on from outside.
The Split Bill Problem
The internal friction on this project came from a specific UX edge case in the Split Bill flow, and it is worth documenting because it illustrates how consequential seemingly small product decisions can be.
The scenario: a user wants to split a $100 bill between three people. They enter Person A as owing $20, and Person B as owing $30. What should Person C's field show? And what happens when the user goes back and changes Person A's amount after already entering all three? What happens if they change the total bill amount?
The cascading math logic had to be resolved consistently across every possible editing sequence, and the product owner and I disagreed on how it should work. The debate ran for a couple of weeks. He ultimately went around to other product owners to pressure-test both approaches, came back, and said: you're right, let's go with your idea.
The right answer was the one that gave users the most predictable, recoverable experience regardless of the order in which they made edits. Predictability in payment flows is not a nice-to-have.
The internal friction on this project came from a specific UX edge case in the Split Bill flow, and it is worth documenting because it illustrates how consequential seemingly small product decisions can be.
The scenario: a user wants to split a $100 bill between three people. They enter Person A as owing $20, and Person B as owing $30. What should Person C's field show? And what happens when the user goes back and changes Person A's amount after already entering all three? What happens if they change the total bill amount?
The cascading math logic had to be resolved consistently across every possible editing sequence, and the product owner and I disagreed on how it should work. The debate ran for a couple of weeks. He ultimately went around to other product owners to pressure-test both approaches, came back, and said: you're right, let's go with your idea.
The right answer was the one that gave users the most predictable, recoverable experience regardless of the order in which they made edits. Predictability in payment flows is not a nice-to-have.
The Flow
Three user journeys. Send Money, Receive Money, and Split Bill. Each one had to work independently, connect cleanly to the others, and handle every edge case: unknown recipients, enrollment prompts, pending payments, edit states, cancellation paths.
The flow diagram captures the high-level architecture of all three journeys, giving the scrum team a shared reference point to build from.
Three user journeys. Send Money, Receive Money, and Split Bill. Each one had to work independently, connect cleanly to the others, and handle every edge case: unknown recipients, enrollment prompts, pending payments, edit states, cancellation paths.
The flow diagram captures the high-level architecture of all three journeys, giving the scrum team a shared reference point to build from.
The Design
The polished screens reflect a deliberate decision made early: we were not going to inherit Fifth Third's existing mobile design system as-is for this feature. The system at the time was not equipped for a contact-driven payments experience. Instead of working around its limitations, we extended it.
The contact list and contact card components were designed from scratch but with the broader app in mind. The goal was components that felt native to Fifth Third while being purpose-built for the social dynamics of peer-to-peer payments: recent contacts, suggested recipients, pending requests, multi-person splits. These components were designed to be reusable across the app, not just within the Zelle integration.
The polished screens reflect a deliberate decision made early: we were not going to inherit Fifth Third's existing mobile design system as-is for this feature. The system at the time was not equipped for a contact-driven payments experience. Instead of working around its limitations, we extended it.
The contact list and contact card components were designed from scratch but with the broader app in mind. The goal was components that felt native to Fifth Third while being purpose-built for the social dynamics of peer-to-peer payments: recent contacts, suggested recipients, pending requests, multi-person splits. These components were designed to be reusable across the app, not just within the Zelle integration.
Outcomes
The feature launched as one of Fifth Third's most widely visible consumer mobile experiences to date. The combination of pushing back successfully on Zelle's corporate requirements, resolving the internal product disagreements, and building a custom component set that extended the design system gracefully meant the shipped product felt intentional rather than assembled.
A peer-to-peer payments feature lives or dies on trust. Every friction point in a payment flow is a moment where a user questions whether to proceed. Getting the flows right was not a UX nicety. It was the product.
The feature launched as one of Fifth Third's most widely visible consumer mobile experiences to date. The combination of pushing back successfully on Zelle's corporate requirements, resolving the internal product disagreements, and building a custom component set that extended the design system gracefully meant the shipped product felt intentional rather than assembled.
A peer-to-peer payments feature lives or dies on trust. Every friction point in a payment flow is a moment where a user questions whether to proceed. Getting the flows right was not a UX nicety. It was the product.
