Sharilyn Johnson

Citibank: Zelle Repeating Payments

Client: Citibank  //  Agency: Critical Mass // Date: 2019 // Medium: Website, mobile app

Our client, Citi, wanted to expand the recurring payment options available to its users of Zelle, the person-to-person money transfer system.


The world was our oyster. The folks at Zelle wouldn’t provide recommended logic, and Citi left it to our discretion. Time to reinvent a wheel. 

I worked with our designers to brainstorm scenarios of when users were most likely to take advantage of recurring payments. Occasions such as a weekly league fee or bi-weekly payments to coincide with paydays.

We also decided how far to take this, as to not overwhelm users with too many options.


What went wrong? The before:

It all looks sound at first glance, but it didn’t take me long to realize: this logic didn’t work. 

These 7 screens provide plenty of options, but the “Send Date” and “Repeat” (recurring) options conflict.

It was possible for the Send Date to not match the day of the week of the Repeat payment.

Pretend you want to send Jane $300 every Sunday, and you’re setting this up on a Wednesday:

If today is a Wednesday and the user selects “every 1 week on Sunday.”

When will the first payment send? “Today” or Sunday?

When dealing with people’s money, there should be no question.



My solution

The team let me take the wheel on this one. I went back to what I knew about our users and what their intent is when scheduling a repeating payment.

If a payment was to happen on a specific day of every week or month, it was unlikely they intend it to be preceded by a one-off payment – in the same amount – on a different day.

That means if a user chose mismatched days, their intent was to select a Start Date in the future. Neglecting to edit “Today” in the “Send date” field was effectively a user error — one I needed to prevent.

Initially I contemplated an alert that would notify the user if their selections didn’t work, so they could go back to fix them. But this would just add friction and back-and-forth to the process.

Instead? I limited the Repeating options to only variations on the Send Date, and added a clear summary on the Repeating options screen.

For most users, this would be expected behavior. They set up a payment to send Thursday, June 1, and the only options available in the next stop are variations on this:  Thursdays, the 1st of the month, or every June 1. 

For the users who meant to do something different? This was a gentler way to alert them that they needed to go back one screen and select a different start date. We never had to explicitly tell them they did something wrong.


In this revised scenario, the user entered this screen after selecting a Thursday as their Send Date. That dictated the Repeat options available to them (only Thursdays when they select Weekly).

A static banner explains the start date, while dynamic copy summarizes the selections.

No more ambiguity.