The Citi Design System.
How I co-founded and built one shared design language for an over 200-year-old bank, and got 150+ designers across the world to actually use it.
The brief
40 products, 40 dialects.
When I joined the Senior Designer team at Citi in 2022, there was no design system. There were design files, lots of them. Components that looked slightly different from team to team, buttons in four different shades of blue, spacing values that were more suggestion than rule. With 150+ designers working across web, iOS, and Android products, the inconsistency wasn't just aesthetic, it was slowing everyone down and creating real developer debt.
I was one of the founding designers brought in to change that. No internal playbook, no prior art to follow, just a mandate to build something the whole organization would actually use.
I'll be honest: it was also my first design system. I had never built one before, and the scope was overwhelming at first. But I was excited about the problem, and I knew that getting it right would matter for every designer and developer who came after us.
The approach
Learn it. Build it. Get people to use it.
Before I opened Figma, I spent time learning, reading everything I could find and studying design systems from companies I respected: Atlassian, Shopify, IBM, Adobe. Then came the audit. I pulled screenshots from dozens of products across the organization, every modal, every form field, every error state. When I laid seven shades of warning yellow side by side, the case for the system made itself.
I used atomic design methodology and started with the most-used elements across our products, making sure every component was scalable across iOS, Web, and Android. Documentation grew alongside the components, not after, usage guidelines, accessibility standards, examples, all written as we went so adoption wouldn't depend on anyone having to figure things out alone.
The decision I'm most proud of was getting engineering in the room from day one, not for review, but as working partners. I ran workshops every other week where designers and developers worked side by side. Components that look great in a design file but can't be implemented cleanly are just mockups. I wanted to build the real thing.
We launched with the smallest viable kit: typography, color, spacing, and ten core components. Then we shipped weekly. But the strategy wasn't just about what we shipped, it was about how we showed up. Training sessions and roadshows instead of announcements. Office hours every Friday. A Slack channel where any designer could ask anything without judgment.
I wanted people to feel like they helped build the system, not like it had been handed to them. That distinction mattered more than any component we designed.
The shift
From scattered to shared.
Before the system, every new product started from scratch. Designers rebuilt the same components every sprint. Engineers wrote the same code in five different ways. Inconsistency wasn't just a design problem, it was slowing down shipping across the entire org.
After, teams started from a shared foundation. The conversation between designers and engineers changed from "this doesn't match what I have" to "can we extend this component to handle this edge case?" That shift, small as it sounds, was the whole point.
The outcome
Two years in.
The system launched successfully and received positive feedback from both designers and developers. Over time, it became the default starting point for every new product in the design org, and several teams outside it migrated voluntarily.
Beyond the numbers: designers stopped rebuilding from scratch, which meant faster shipping and more consistent products. Developer debt went down. And when Citi later went through a rebrand, refreshing the system meant updating shared values, not hunting through hundreds of individual files.
What I took with me
A system is a community, not a library.
Co-founding the Citi Design System was one of the most challenging and rewarding things I worked on at Citi. The learning curve was steep, the scope was bigger than anything I had tackled before, and there were moments where I had to figure things out with no playbook.
What I learned is that the Figma file matters less than the people around it. What made this work wasn't the quality of the components, it was the office hours, the openness to dumb questions, the willingness to say "the system is wrong, let's fix it" out loud.
I started this project thinking my job was to design components. I finished it understanding that the components were just the artifact. The real work was building enough trust that 150 people would change how they worked every day.