Work

About

Resume

Enter Password

Enter the password to continue. If you don't have it please contact me

Enterprise Design System · Ameriprise Financial · Fintech

One system that finally spoke client and advisor and cut handoff time by 40%.

One language.

Two worlds.

A unified system.

Introduction

Ameriprise runs two very different experiences under one brand: Client, the simple, guided app individual investors use to track their money, and Advisor, the denser, data-heavy tool financial advisors use to manage it for them.

Both had their own design system. Neither was maintained.

It wasn't really a design system problem. It was a decision problem.

Every small UI choice turned into a debate. Patterns weren't shared. Components couldn't evolve. "If it's not in the library, we don't build it" was the unofficial rule, which in practice meant: build it yourself, quietly, and hope no one asks.

Client and Advisor were supposed to share a foundation. Instead they drifted further apart every quarter and across 15+ products built on top of them, that adds up fast.

So I pushed to rebuild the system into something teams would actually use.

This project has been anonymized for confidentiality.

Type

Type

Design System · Fintech

Design System · Fintech

My Role

My Role

Senior UX Designer

Senior UX Designer

Timeline

Timeline

Shipped & still evolving

Shipped & still evolving

Problems
Problems

  • No governance, no system: two themes drifting apart, nobody owning either.

  • Every small UI choice became a debate nobody had authority to settle.

  • Inconsistencies slowed down delivery.

Solution
Solution

  • Rebuilt the system from the inside out.

  • Defined tokens, patterns, and rules that map straight to code.

  • Focused on adoption over completeness.

Result
Result

  • 40% faster design-to-dev handoff.

  • 50% of redundant component code gone.

  • 2× faster cycles, 100% WCAG AA.

Process

Setting the scene

Two themes. Zero governance. It looked fine until you tried to build anything in it

Two themes. Zero governance. It looked fine until you tried to build anything in it

A design system already existed, one theme for client, one for advisor, visually nothing alike, and nobody maintaining either. The component library was too limited to be useful and too rigid to evolve, so "if it's not in the library, we don't build it" became the default answer to most things. Teams argued, hacked around it, or shipped it anyway. Delivery slowed. Issues piled up.

That was the state of things when I joined.

It was clear this wasn't sustainable. So I pushed for a proper design system, not an easy sell, but the need became obvious fast.

👀 This was never really a component problem. It was a decision problem wearing a component problem's clothes.

Standard conversation between designers

Constraints

With no full-time team, I chose speed and adoption over purity.

With no full-time team, I chose speed and adoption over purity.

No one was working on the system full-time, so aiming for a “perfect” system wasn’t realistic. For us, the biggest goal was adoption, and that meant making trade-offs.

I worked closely with developers to accelerate setup. Instead of building everything from scratch, we agreed to use existing foundations what already existed, Figma, Storybook, React underneath instead of rebuilding from zero, and align the UI to brand rather than rearchitecting component logic.

To keep the system manageable, we set a few clear rules:

  • Add a component only if at least two teams need it

  • Build for current needs, not hypothetical ones

    This reduced complexity for developers and sped up their work a lot.

To keep the system manageable, we set a few clear rules:

  • Add a component only if at least two teams need it

  • Build for current needs, not hypothetical ones

    This reduced complexity for developers and sped up their work a lot.

The Foundations

Setting up a solid token structure

Setting up a solid token structure

We built the system on an Atomic Design approach, supported by a shared token system between figma and code.

I set tokens for color, typography, spacing, radii, and height, split into a three-layer structure:

  • Primitive: raw values

  • Semantic: meaning-based tokens

  • Component: specific overrides when needed

💡 Genuinely painful to set up. Paid for itself the first time a brand update propagated across the whole library instead of taking days of manual edits.

Systemic fixes

Making good UX the default, not a debate.

Making good UX the default, not a debate.

Some fixes I didn't want to turn into tickets that would sit in a backlog forever, so they went straight into the foundation instead.

✓ Accessibility by default: color tokens set so every text-and-surface pairing passes WCAG 2.1 AA without anyone having to check.

✓ Safer destructive actions: one consistent pattern instead of every team handling delete/remove differently.

✓Predictable feedback states: the same system states behave the same way on both platforms.

Nobody had to opt in. It just came with the system.

Design Patterns

Reducing guesswork by defining clear patterns.

Reducing guesswork by defining clear patterns.

With the component base solid, now the focus area was Patterns.

I audited other design systems and our own products to define clear guidelines for recurring problems, areas with no single “correct” solution that were causing inconsistency and unnecessary debate.

  • Action hierarchy and button placement

  • Tables: filtering, sorting, bulk actions

  • Forms and validation

  • Cards.

    Client and advisor used almost the same patterns underneath, the real difference was density.

    Advisor screens carry a lot more data, so the same pattern had to flex without breaking.

Not clickable folders right now, PS: Still working on the files

Full workflow

From Figma to production, including the AI part

From Figma to production, including the AI part

Any designer working on a Design system knows it’s only as good as the frontend dev building it, luckily we had three good ones, so that part was never the risk.

We connected Figma to Storybook for web and Widgetbook for mobile through Supernova, which became the actual source of truth devs worked from day to day.

Then we pushed it further: Figma's Code Connect and MCP servers, so the system could feed AI-assisted code generation directly instead of a designer translating specs by hand.

My part there was mostly support:

  • Aligning naming conventions with code standards

  • Adjusting variants so they actually matched component props.

Documentation and enforcement

Documentation alone wasn't enough to drive adoption.

Documentation alone wasn't enough to drive adoption.

I assumed that once the guidelines existed, people would just use them. but no one really reads documentation. Shocking, I know.

So I got proactive:

  • Pushing proper component and pattern usage during design reviews

  • Nudging designers back toward the system instead of around it. Uncomfortable at first. Eventually it just became normal.

    On the dev side, the frontend team ran Figma Dev Mode workshops so other devs could get comfortable working inside the system instead of guessing at it.

Results

40%

Reduction in design-to-dev handoff time.

Measured across both platforms, six months post-launch

50%
50%

Redundant component code eliminated by consolidating two libraries into one.

2x
2x

Faster feature development teams stopped rebuilding foundational components.

100%
100%

WCAG 2.1 AA compliance across every unified component, by default.

A design system is never really "done." But within six months, two platforms that used to argue about the same button were shipping off the same one and the debates that used to eat a sprint mostly just stopped happening.

"We went from two teams building the same button to one system every team trusts."

"We went from two teams building the same button to one system every team trusts."

Most of what looked like design problems were actually alignment problems.

Most of what looked like design problems were actually alignment problems.

Once a decision had one clear place to live, most of the debate around it just stopped — not because everyone suddenly agreed, but because there was finally something concrete to agree against. Talk to the people first. The tokens are the easy part.

Let’s bring your vision to life...

Think I'd be a great fit for your team, or just want to chat about design and cheesecake? I'd love to hear from you.

Download Resume

Connect on Linkedin

I’m currently open to full-time opportunities! Let’s create something amazing together! ✨

© 2026 Srishti Bhurani

Built with love 💙 & lots of coffee ☕️

Let’s bring your vision to life...

Think I'd be a great fit for your team, or just want to chat about design and cheesecake? I'd love to hear from you.

Download Resume

Connect on Linkedin

I’m currently open to full-time opportunities! Let’s create something amazing together! ✨

© 2026 Srishti Bhurani

Built with love 💙 & lots of coffee ☕️

Let’s bring your vision to life...

Think I'd be a great fit for your team, or just want to chat about design and cheesecake? I'd love to hear from you.

Download Resume

Connect on Linkedin

I’m currently open to full-time opportunities! Let’s create something amazing together! ✨

© 2026 Srishti Bhurani

Built with love 💙 & lots of coffee ☕️

Create a free website with Framer, the website builder loved by startups, designers and agencies.