This case study is confidential, so it's lightly locked. If we've talked and you have the access code, drop it in below.
Hmm, that's not it. Try again.
No code? Reach out and I'll share it.
OVERVIEW
A little context before we dive in. Designing at Zelle is a bit different from most product design roles. Zelle isn’t a standalone app. Instead, it’s built directly into our partner banks’ mobile apps, which means every design decision has to work across thousands of implementations while meeting the needs of both the banks integrating it and the people using it.
Most of this page gives a look into that world and the different kinds of work that come with it.
Zelle Structure
Zelle is embedded inside the mobile banking apps of its partner banks, not a standalone product. Every design decision has to work across thousands of implementations, and serve both the banks who ship it and the people who use it.
B2B2C
WHAT I CURRENTLY DO AT ZELLE
A few of the threads I’m actively shaping right now, from research and benchmarking to the design system that ships across every partner bank.
Zelle lives inside 2,000+ banking apps but had no desktop standard. I ran a click-by-click teardown of how the biggest banks build their send-money flows on web, counting steps and mapping patterns to define Zelle’s first desktop design system.
Every partner bank ships its own Zelle experience. I review each one against Zelle brand guidelines and Nielsen Norman heuristics, grade it red / amber / green, and hand back prioritized, DFIUX-required fixes.
A single avatar hex has to say who you’re paying, that they’re verified, and that the payment is protected. I’m designing it at the component level with a phased rollout across business, SMB, and purchase-protection states.
The Zelle mobile system carried years of drift from Sketch and iOS 8. I’m rebuilding it in Figma for iOS 16, tightening every screen of the send flow so 2,000+ partner banks inherit one consistent, current experience.
MY JOURNEY AT ZELLE
Joined Early Warning Services (the company behind Zelle) and spent my first few months creating product playbooks that documented how each of their products worked and how teams actually used them day-to-day. Those playbooks are still being referenced by employees today.
Stepped into full ownership as the sole designer shipping features alongside product managers. Led the Zelle design system migration from Sketch to Figma, partnered with a UX writer to rebuild internal branding and style guidelines, and helped set the foundation for how the team shares work across the company.
Contributing to Zelle’s design system across 20+ financial institutions. Helped ship a small business payments experience, authored Bill Pay guidelines, and supported UX review frameworks that partner banks use to ship consistent experiences. Along the way, I mentor design interns and share methodologies across teams.
FEATURED PROJECT
A trust and safety feature that finally gave people a way to shut down harassment reaching them through their own banking app.
THE PROBLEM
People were using Zelle to harass each other. A small payment, or a request with a note attached, was enough to reach someone who did not want to be reached, and it landed right inside their banking app.
The targets were ex-partners, stalkers and strangers who had gotten hold of a phone number. Some people closed their Zelle account entirely just to make it stop.
Users had no way to
Because Zelle lives inside partner banks and not as its own app, there was no block anywhere in the network to fall back on.
STRAIGHT FROM THE INBOX
These are real messages Zelle’s customer-service team received. I pulled them so the work stayed anchored to what people were actually dealing with.
I would like help on blocking someone due to harassment. If I could get a response back, I would appreciate it.
This should not be allowed by Zelle. It is harassment from my ex-husband trying to contact me. I have had to close my Zelle accounts to avoid these messages.
We received an unauthorized payment through Zelle along with a harassing message. We would like to block this user.
They stalk me often and have now found me on here, so they keep sending me random amounts to try and get my attention.
COMPETITIVE ANALYSIS
Before touching our own screens I looked at how Venmo, Cash App and PayPal treat a block, and how honest each one is when a blocked person tries to pay.
A full social cutoff. The blocked person cannot pay, request, view your profile or find you, and they drop out of your contacts. Strong, but unblocking is buried deep in settings, so it is easy to block and hard to undo.
A financial cutoff. It cancels pending transactions and stops sends and requests, but the person stays in your contacts and unblocking is quick. Block and Report sit side by side.
The middle ground. It cuts payments both ways and hides the person while keeping your history intact. Unblocking is one tap from recent activity.
The sharper question was honesty. When a blocked person tries to send, what do they see? Cash App names it plainly, telling them the recipient does not want to exchange money. Venmo and PayPal quietly make the blocker vanish. That call, how much to reveal, shaped how we wrote our own messaging.
EXPLORATION
There were two natural places to start a block. From Zelle Preferences, where people manage their recipients, or from Zelle Activity, on the exact transaction where the harassment showed up.
Preferences already had a Delete option. Putting Block right next to it made people unsure which one did what, and whether one was more final than the other.
If I delete a user, will they be banned from sending or getting money?
Deleting them feels more permanent than blocking them. Is that right?
There was a technical cost too. Reflecting a blocked note across every activity detail screen was expensive on the engineering side.
So I split the job. People block from the transaction in Activity, where the intent is obvious, and manage or undo blocks in one place under Zelle Preferences.
THE SOLUTION
On any transaction in Activity, a Block Contact action opens a short alert that explains what a block actually does, then confirms it. The alert answers the question people kept asking, what does blocking mean, before they commit to it.
A new Manage Blocked Contacts area lists everyone you have blocked and gives a clean path to unblock, with the same plain-language explanation of what changes.
EDGE CASES
A block is only worth anything if there is no way around it. I mapped seven scenarios so a blocked person could not slip back in through a side door.
FROM DESIGN TO GUIDELINES
Zelle does not ship screens directly. It ships guidelines that partner banks build against, called DFIUX, short for Digital Financial Institution User Experience. So the real deliverable was a set of clear, testable specs each bank could implement on its own.
We do not have a dedicated UX writer, so I leaned on the team’s enterprise ChatGPT setup to keep the guideline language clean and consistent for banks to review. Every line still went through legal.
Legal review // Every word checked against policy and disclosure requirements
Update & iterate // Rewrite and loop back until the language holds up
Legal approval // Sign-off on the final guideline
Share with banks // Published to the network through DFIUX
What happens next
LOOKING BACK
When your work ships to thousands of partners, individual screens matter less than the patterns that hold them together. You stop asking “does this look right?” and start asking “does this scale?” That shift changed how I approach every design.
Regulatory, technical, and organizational constraints narrow the problem. At first they feel like walls. Eventually you realize they’re guardrails. They force focus, and focus usually leads to better, more confident solutions.
In payments, every interaction either builds trust or chips at it. There’s no neutral touchpoint. A confusing error message isn’t just bad UX. It’s someone hesitating before sending rent to a friend. I carry that weight into every decision.
The most valuable skill I’ve picked up here isn’t in Figma. It’s knowing how to advocate for users when I’m in rooms with engineering, legal, risk and product, then translating between all of them without losing the user somewhere in the middle.
