I led content design for Zelle's recurring and scheduled payments, a high-visibility initiative that closed a major competitive gap. The work required introducing new functionality into a flow that hadn't significantly changed in years, so the content had to guide users through new behavior without disrupting what 30M+ users already knew.
Zelle only allowed users to manually send one-time payments. No scheduling, no automation. For people managing rent, shared expenses, or regular transfers to friends and family, that meant remembering timing, re-entering details, and manually managing recurring financial obligations.
This risked customers missing or sending late payments, losing confidence, and potentially turning to competitors who already offered scheduling.
Primary user research wasn't available due to time and scope constraints. So, I used competitive analysis to understand how other banks approached scheduled and recurring payments, reviewing common patterns for scheduling and frequency selection, how key information was surfaced, and where clarity broke down.
Three things stood out. Users were often required to remember previously entered details across steps, increasing cognitive load. Critical information like timing, amount, and frequency was inconsistently surfaced. And few experiences provided persistent, real-time feedback as users configured payments.
This shaped a clear job to be done: when someone needs to send money on a schedule, they want to set it up once and trust that it will go through smoothly, so they don't have to remember, worry, or risk missing a payment.
I owned end-to-end UX content for this initiative. That meant content strategy across the flow, defining content placement to guide users through multi-step interactions, and writing all user-facing copy. I also designed a notifications content system covering 7 trigger states.
Beyond writing, I influenced the structure of the user flow itself, including where and how critical information appears. I partnered closely with product and design in working sessions, contributed to defining interaction patterns where content functions as part of the UI, and aligned with legal, compliance, and EWS to ensure accuracy without sacrificing clarity.
Since this was a new feature launching within a familiar product, the content strategy prioritized clarity and trust. I used plain, scannable language and leaned on content placement as a working part of the design. Key details like amount, timing, and frequency weren't just field labels, they were reinforced throughout the experience.
The experience was shaped by three key content decisions.
In an effort to minimize the number of screens, similar to competitors' experiences, our first iteration kept the entire setup flow on the enter amount screen. It used bottom sheets to display frequency, timing, and duration. The issue was that users wouldn't see the full scope of their selections until they finished making them. I wanted our experience to reduce that cognitive load and reduce the risk of errors.
I introduced a dynamic summary card that updates in real time and persists across the entire setup flow, which became the centerpiece of the experience.
Outside of the setup flow, users also needed to view, manage, and cancel existing scheduled and recurring payments. It was important not to bury key details behind additional taps, forcing users to dig before they could make a decision.
I structured each payment entry on the scheduled screen to show the recipient name, amount, frequency, and next payment date all in one simple row of text. A user deciding whether to cancel or modify a payment has everything they need without tapping into the full payment overview.
The same principle exists in setup. On the picker for selecting an end date, I added "Starts on (date)" below the calendar so users could see the full series length in context without having to remember or go back.
One of my goals for this project was to create scalable frameworks that could be used not only across different flows in this project, but in future projects alike. With the exception of setup-specific language, the majority of the content, design, and interactions from this flow will be reused when we launch the request feature for Zelle recurring payments. For this project specifically, I wrote a reusable disclosure that appeared on multiple review, setup, and series overview screens, that explained the deadline to skip or cancel payments. The language flexed depending on context: skip terminology for recurring payments, cancel-only for one-time scheduled payments.
This single piece of reusable content covered multiple contexts, so we could work efficiently without needing to rewrite copy for each flow.
I surfaced an edge case where a user may schedule payments on the 31st of each month, potentially causing confusion for months with fewer than 31 days. On the calendar picker, I added a disclosure explaining that payments scheduled for after the month ends would send on the last available day. Without it, a user could set up a payment expecting it on the 31st and have it go out on a different day with no explanation.
This came in handy when writing the toggle label. My first iteration used "recurring payment". Since we didn't have our own research to leverage, I connected with our AI voice assistant (Fargo) team to pull utterance data on how users naturally spoke about recurring payments. "Repeating" was the most common utterance over "recurring" or "reoccurring", which is how we landed on the label. The words our users were actually using, became the ones they saw in the experience.
Zelle users can now set up scheduled and one-time future-dated payments, as well as recurring payment series. They can view, manage, and cancel these payments from a single screen.
This closed a major competitive gap and gave 30M+ users a reason to handle recurring financial obligations inside Zelle instead of leaving for another product. The content we used also established a scalable foundation for future features like requesting scheduled payments.
Without primary user research, competitive analysis shaped the direction of this project. I believe having a direct signal from users would've allowed our team to cover more edge cases in scheduling logic.
The biggest content flaw in the current state is that users have to toggle on "Repeat payment" to schedule a one-time payment. I pushed back on this for multiple rounds with executive leadership, proposing we either add a frequency field to the Send money screen instead of the toggle, or change the toggle label to "schedule payments." Unfortunately, I was unsuccessful.
My biggest takeaway is that where content sits in a flow matters as much as what it says. Something I already believed, but this project helped reinforce it.