This case study is confidentials-only, so it's lightly locked. If we've chatted 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
UX Designer
January 2022 – Present
Early Warning Services, Zelle®
Phoenix, AZ · New York City, NY
Zelle doesn't exist as a standalone app for most people. It lives inside their bank. So the experience I design doesn't ship once, it ships across thousands of financial institutions, on mobile and desktop, each with their own implementation. My job is making all of that feel like one product.
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.
#01 THE PROBLEM
When I joined, the design system was still in Sketch. Components were built on older platform standards. Teams were starting to improvise because the system wasn’t keeping up, and in a regulated financial product, that’s a real problem.
It needed more than an update. It needed a full migration and rethink.
#02 WHAT I DID
I led the migration to Figma and upgraded every component to current platform standards. But honestly, the bigger piece was figuring out how the system actually gets maintained. Who reviews components, how they get adopted, what happens when a partner needs something custom.
Rebuilt to work across platforms and screen sizes. Less back-and-forth with engineering, cleaner handoffs.
Updated to align with current mobile conventions and accessibility standards, both visually and structurally.
Set up review and adoption workflows so the system doesn't just look consistent on day one, it actually stays that way.
Designed with cross-platform in mind from the start, knowing desktop was next.
#03 THE NEXT CHALLENGE
Mobile had a system. Desktop didn’t. As Zelle expanded into new use cases like bill payments and financial services, that gap started showing. Users on desktop were getting wildly different experiences depending on which bank they used.
So I started from the beginning: what does the desktop experience actually look like right now?
Benchmarking // Audited how the desktop experience currently lives across different types of financial institutions
Desktop design system // Built foundational components tailored for desktop, not just resized mobile screens
UX guidelines // Partner-facing documentation so implementations are consistent and accessible across the network
The point wasn't to make desktop look like mobile. It was to make sure someone paying a bill on their laptop has the same clarity and confidence as someone splitting dinner on their phone.
#04 THE SENSITIVE STUFF
Here's the thing about designing fraud prevention: legal wants more warnings, product wants fewer steps, and the user just wants to pay their friend back for lunch. Everyone's right. And the requirements often contradict each other.
I worked with product, engineering, research, and risk to figure out where friction actually helps and where it just annoys people.
Abstract requirements go in circles. Tangible prototypes get people aligned. I learned to put something concrete in front of stakeholders early.
A well-placed warning at the right moment can prevent a scam. A poorly placed one just annoys people. The difference is context and timing.
Regulatory requirements aren't things to work around, they're inputs. Some of my tightest solutions came from the tightest restrictions.
In these projects, I'm in rooms with legal, risk, engineering, and product. Documented design rationale and clear flows became my best tools for alignment.
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 — and translating between all of them without losing the user somewhere in the middle.
Available for freelance work
or we can have a coffee chat ♡
ritikarramesh@gmail.com