Fidelity Design System — iOS Mobile Workstream

Overview

Fidelity Investments is one of the largest financial services companies in the world, with a design organization of 150+ UX designers and researchers working across dozens of products — mobile apps, web platforms, internal tools, and customer-facing experiences. In 2022, the company made a strategic decision to unify all of those surfaces under a single design system: FDS.

I was brought onto the FDS team as a Principal UX Designer and led the iOS mobile workstream — responsible for designing, structuring, and delivering the Figma component library and templates that would serve as the source of truth for every iOS experience at Fidelity. We had nine months to launch version 1.0. We shipped on time.

The Problem

Fidelity's design organization had grown organically over years. Individual product teams had built their own component libraries, their own patterns, and their own interpretations of the brand. The result was an ecosystem of inconsistency: similar UI patterns built differently across products, design decisions made in isolation, and no shared language between the teams building iOS, web, and internal tools.

For a company where customers interact with their retirement savings, investment accounts, and financial planning tools, inconsistency isn't just a design problem — it's a trust problem. When the experience feels different from one screen to the next, it introduces friction and doubt at exactly the moments that require confidence.

The challenge was not just to build a library. It was to build one that all the designers would actually adopt and trust — across different product areas, different levels of seniority, and different ways of working.

My Role: iOS Mobile Workstream Lead

Defining the iOS component architecture

I established which components were needed for v1.0, how they would be structured within Figma, and how they would map to iOS native patterns while staying aligned with Fidelity's brand. This required balancing fidelity to Apple's Human Interface Guidelines with the design language the FDS team was building — knowing when to follow platform conventions and when to establish Fidelity-specific patterns.

Building the Figma library

I designed and built the iOS component library in Figma from the ground up — variants, auto layout, interactive components, and documentation annotations baked directly into the file. The library was structured to be intuitive for designers who had never used a shared system before, not just designers who understood how to work in Figma at a technical level.

Coordinating with the broader FDS team

iOS components don't exist in isolation — they needed to align with the token system, the web component library, and the overall FDS design language being developed in parallel. I worked closely with the other workstream leads to ensure visual and behavioral consistency across surfaces without creating bottlenecks.

Supporting adoption

After launch, the work didn't stop. I participated in the team's ongoing support structure — office hours, Teams channels, and direct designer support — helping iOS-focused product teams understand how to use the library, when to use it as-is, and how to flag gaps for v1.1.

The Approach

Starting with inventory, not components

Before building anything, I audited the existing iOS design files across Fidelity's product teams to understand what patterns were already in use. The goal was not to start from scratch but to identify what was working, what was inconsistent, and what was missing entirely. This inventory work shaped the component priority list for v1.0 — ensuring we shipped the things designers needed most, not just the things that were easiest to build.

Tokens first, components second

In close coordination with the tokens workstream, I ensured every iOS component was built on the FDS token system — color, typography, spacing, and elevation values that could be updated globally rather than component by component. This was a deliberate investment in the long-term maintainability of the library and a decision that would pay dividends as FDS evolved past v1.0.

Designing for designers

A design system is a product. Its users are designers. I treated the Figma library with the same UX rigor I would apply to a consumer product — thinking about how designers would navigate it, how they would understand the component variants, and how much they would need to read before they could use it. Components were named predictably. Variants were structured to match how designers think about states, not how engineers think about props. Documentation was embedded in the file itself, not in a separate wiki that would fall out of date.

Phasing scope ruthlessly

Nine months is not a lot of time to build a comprehensive iOS component library for one of the world's largest financial institutions. I worked with the team to phase v1.0 scope aggressively — prioritizing the components that would unblock the most product teams and deferring edge cases and lower-frequency patterns to v1.1. Shipping a solid, trusted v1.0 on time was more valuable than shipping a comprehensive v1.0 late.

Launch & Adoption

FDS v1.0 launched on schedule, with the iOS library fully delivered alongside the web and Android components and Figma templates. The 150+ person design organization was onboarded through a structured rollout: documentation, live training sessions, dedicated Teams channels for questions, and recurring open office hours where designers could bring real problems and get real answers.

The qualitative signal from the iOS workstream was strong. Product teams that had previously maintained their own ad hoc component sets adopted the FDS library because it solved a real problem — they no longer had to make foundational decisions from scratch on every project. The shared language created by FDS made design reviews faster, design handoff cleaner, and cross-team collaboration more natural.

Perhaps most importantly, the system earned trust. Trust that it would be maintained. Trust that questions would be answered. Trust that when a designer built on FDS, they were building on something stable.

What This Work Demonstrates

Design systems are infrastructure. They're unglamorous, they're complex, and their value is most visible in the work they make possible rather than the work themselves. Leading the iOS workstream on FDS required technical depth in Figma and iOS patterns, strategic judgment about scope and prioritization, cross-functional collaboration across a large organization, and a genuine conviction that the designers using the system deserved something that worked as well as the products they were building.

Shipping v1.0 in nine months at Fidelity's scale wasn't just a delivery achievement. It was a systems thinking challenge — and one of the most consequential design contributions I've made.