Context

At Citi, I served as VP of User Experience Design on Helios — a large-scale internal platform for creating, evaluating, distributing, and managing corporate loans and lines of credit. I led design across five simultaneous initiatives, including two products built from the ground up. As work at Citi falls under NDA, I'm not able to share design artifacts, but I can speak to my role, the decisions I made, and what I built.

The environment had two defining characteristics: significant variety across projects, and no established Agile or sprint methodology when I arrived. The variety was genuinely energising — every week brought a new design puzzle — but the absence of process structure meant that embedding good practice required as much design leadership as design execution. Both shaped how I worked.

Project One: Account Status Dashboard

One of the initiatives I owned was a new feature for account managers: a live view of the current status of a loan or business account. The immediate use case was preventing an account manager from closing or adjusting an account that still had outstanding obligations to the bank. Simple in concept, but the design challenge was significant — account managers work across thousands of accounts, and the feature needed to surface the right information at the right moment to support fast, confident decisions.

I approached the research in two directions. Internally, I spoke with team members working on other parts of Helios to understand how a live status view would interact with their workflows and what data would make the biggest difference to them. Externally, I studied stock tracking software — a domain with a similar design challenge: surfacing essential, actionable information from large datasets in a way that supports quick decisions without overwhelming the user.

The key insight from that research was about hierarchy and executability. Stock tracking software has solved the problem of making vital information immediately visible and immediately actionable, even when the underlying dataset is enormous. That framing changed how I approached the account status feature — the design needed to prioritize the most critical information at a glance, make the key actions accessible without hunting for them, and give account managers a way to stay oriented across a large account portfolio.

I also worked directly with the product manager in one-on-one sessions to surface needs and requirements that hadn't been articulated in the original brief — a practice I've found consistently surfaces the most valuable design opportunities. Those conversations revealed several features worth building for: refresh tracking so account managers always knew how current their view was, favouriting to manage frequently accessed accounts across a large list, and lightweight equation tracking that would make the feature useful beyond its original scope.

The result was a significantly more usable feature than what the original request described — one that the team recognized could be packaged as a widget and reused across multiple other parts of the Helios application.

Project Two: The Local Pattern Library

The second project I'm most proud of was the Helios Local Pattern Library, and it's a story about seeing a problem before it was officially acknowledged as one.

Citi released a new company-wide design system. Helios's existing LPL — the local library of components used across our product — was built on the old system and needed to be updated. But the existing LPL had deeper problems than simply being on the wrong system. It had been built piecemeal over time, on an as-needed basis. Most components weren't properly layered, weren't adjustable through Figma properties, and in many cases weren't true components at all — just one-off designs that happened to be reused. Duplicate components existed for things that could have been unified. There were no base page designs, no functional indicators, no standardized small components, not even an SVG version of the product logo.

I started building a new LPL shortly after the new system was released — not just rebuilding what existed, but designing for what would be needed: charts, indicators, icons, sidebars, notifications, nested tables, and a range of usable chart components. Several of those contributions were reviewed and integrated into the company-wide design system itself. The work happened in the margins of other projects, when time allowed, because the need wasn't yet formally recognized.

That changed when leadership declared that all teams needed to complete the transition to the new system, LPLs included. When an attempt was made to migrate the old LPL by applying the new system directly, it caused significant breakage within Figma — components disappeared as naming conventions changed, old and new components became mixed, and sizing lost consistency throughout. It could have been untangled, but only with considerable effort and time.

At that point the LPL I had been building was 90% complete. A focused two-week sprint finished it, and our team became the first in our silo to complete the transition. The completed LPL was then shared as a foundation for other teams going through the same process, and I helped lead their conversion work.

What I'm proudest of in this project isn't the technical execution — it's the design leadership it required. Seeing the problem before it was a crisis, investing in the solution without a formal mandate, and having the work ready when the need became urgent is the kind of proactive systems thinking that makes a design team genuinely better over time.

What the Helios Work Represents

Across both projects, the common thread was doing more than the request asked for. The account status feature became a reusable widget. The LPL became a foundation other teams built from. That instinct — to design for what will be needed, not just what was specified — is how I try to work, and Helios gave me the opportunity to practice it at enterprise scale.