The Citi Design System.

40 products, 40 dialects.

When I moved into a senior design role 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 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 use.

I'll be honest: it was also my first design system, and the scope was overwhelming at first. But I knew that getting it right would matter for every designer and developer who came after us.

Learn it. Build it. Get people to use it.

Before I opened Figma, I studied the systems I admired: 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 them: usage guidelines, accessibility standards, and examples, all written as we went so adoption wouldn't depend on anyone figuring 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.

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.

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.

Two years in, it became the default.

It became the 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.

A system is a community, not a library.

What I learned is that the Figma file matters less than the people around it. 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.