Fidelity
2025 - Now
MVP 1 Built
Many tools, one standard teams want to use
Five teams, eight tools, and one question: how do you get designers and teams to choose a shared standard when nobody has to?
Overview
Each new effort started from zero, so I built the memory our design team was missing.
Fidelity has a chapter of about 30 designers serving the institutional side of the business. Each product area owns a tool inside a larger platform. Mine owns operations and reporting, the admin tools that firms and internal teams use to set people up to do their jobs.
Here’s what I found. Our design system was built for components, not for scaling patterns across platforms, and nobody had written down how the pieces fit together. So careful, talented designers made slightly different choices, new designers joined blind, and users met one platform that behaved like many.
I’m a Senior UX Designer and a strategic partner to the product area. I don’t own the roadmap, so I couldn’t announce a fix. I built what was missing, proved it inside real work, and made it easy enough that people chose it. Three efforts prove it under real roadmap pressure, and each has its own page above.
Three questions guide this work
01
Can a designer find it?
Project pages, a getting started guide, and an intake system keep every decision in one place.
02
Do they know how to use it?
A pattern library, Figma templates, and component assets give every project the same starting point.
03
Can someone keep it going without me?
A weekly stand up shares what we learn. A RACI pilot is testing how contribution spreads across people, not just me.
What has changed so far
Stakes
One unclear word can end up as a customer phone call.
Dana runs onboarding for a service team. Monday, a new hire starts. In one tool, she clicks Assign. In the next, the same action is called Add. In the third, it hides behind a menu called More.
She picks Add. It creates a second profile instead of granting access. By 9:15, the new hire is locked out, and Dana is filing a ticket. A client waiting on that new hire gets transferred twice.
Now picture the other side of that screen. Priya joins the product area as a designer the same Monday. There's no handbook, no list of what's already been decided, and no pattern to pick up. So Priya does what any good designer would do. She builds the best version she can. It's careful, it's reasonable, and it's one more dialect.
Both scenes are composites, no real people.
01
Friction
Three names for one action
Assign, Add and a buried menu all meant the same thing, so admins had to remember each tool’s version.
02
Friction
Mistakes stayed quiet
A wrong click looked like success. The problem only showed up later, when someone couldn’t sign in.
03
Friction
Fixes stayed local
Each team patched its own tool, so the next tool still had its own wording.
Multiply that Monday by every admin and every week, and it becomes a number. About 750K to 875K avoided contacts a year, at about $8 each, comes to $6 to 7M a year in call center cost.
750k to 875k
Avoided contacts a year
My planning target, not a measured result.
Target
About $8
Cost per contact
Industry benchmark for one phone contact
Benchmark
$6 to 7M
Call center cost a year
The size of the bet.
Target
The $8 is context, not my result. The 750K to 875K is my planning target, and nobody has measured it yet.
The designers paid a different price. They rebuilt things that already existed, because no one could point them to the answer. Same root cause: a design practice that couldn't remember.
Evidence
I counted before I proposed anything.
Before I suggested a single pattern, I audited how the tools handled the same four jobs: assigning access, checking status, reporting, and telling a user what just happened. I went job by job and tool by tool, so I was comparing like with like instead of arguing from taste. Then I asked the product teams what they were afraid a shared pattern would cost them.
3 Legacy tools
Audited one job at a time
4 Jobs
Assigning access, checking status, reporting, and telling a user what happened
What the teams were afraid of
I didn't run a survey. I had conversations, and the same worries kept coming back. These are paraphrased themes, not quotes.
01
Observed
It will slow my roadmap.
A shared pattern sounded like extra work on a deadline that was already tight
02
Observed
It will flatten my tool.
Each team felt its product has a job to do that a standard might not respect
03
Observed
Nobody will keep it going.
Teams had seen standards launch and fade, and didn't want to depend on one.
None of those worries were wrong. So I stopped trying to win the argument and started designing around them.
What the audit showed
I put every finding on a board and grouped it. Four patterns came out, and each one traces back to a moment from the Monday scenes.
Illustrative notes. Grouped from the audit
Key insights
How solid is this?
The audit
3 tools, 4 jobs. I did this work myself
The worries
Paraphrased themes from conversations with product teams. Not a survey.
The savings
The $6 to 7M is a planning target. Nothing is measured until the patterns ship.
Decision
I picked the option that looked slowest because it was the only one people would choose.
There were three ways forward. I laid them out for the product area with what each one gives and what it costs.
Illustrative. Three ways to handle the same problem. The dark outline marks the one I chose.
01
Let each team solve it locally
Fast for each team. It keeps the many dialects, and the next tools start from scratch
02
Announce a platform wide standard
Clean on paper. Teams hear one more thing that slows the roadmap, and I don't own the roadmap, so I couldn't enforce it anyway.
03
Chosen
Earn Adoption
Build each Pattern inside real roadmap work, document it as a template, then show the next team the time it saves.
The tradeoff was on purpose
Option 3 looks less like a system at first. There is no launch and no big reveal. But every pattern was proven on shipping work before anyone was asked to adopt it.
The pushback was fair
Product owners worried that a shared pattern would slow their roadmap and flatten what made their tool theirs. They weren't wrong to worry. Telling them it was good for the platform didn't move anyone. What moved them was seeing the time it saved on their own backlog.
So I started small. I took the pattern a team needed that sprint, built it to the standard, and handed it over with the documentation. Trust came one small win at a time.
How I answered each worry
It will slow my roadmap.
I built the pattern they needed that sprint, so it saved time instead of costing it.
It will flatten my tool.
Patterns set the starting point, not the ending. Each tool keeps its own job.
Nobody will keep it going
Templates, a weekly stand up, and RACI pilot mean more than one person can maintain it.
The rule I held myself to: the standard has to be easier than building your own.
Solution
Three efforts, one set of patterns, and a template every time.
Each effort shipped its own answers. Each answer became a template the next team could pick up, so nobody had to start from zero.
01
Pilot
User ID Management
One place to create, edit, link accounts, and manage permissions. Investor profiles are in a pilot with participating firms. Professional profiles are in MVP 1.
02
In build
SSO Inbound
Admins get a clearer set of actions and statuses. MVP1 is in the build. MVP2 starts next month
03
Paused
Bulk Reporting
One status strip shows where a request stands, so people stop submitting twice
One way to tell people what happened
The shared communication model has four states: success, in progress, needs attention, and error. Each one uses plain words, an icon and a text label, never color alone, and is announced to screen readers.
Illustrative wording. Every state has an icon and a text label.
Before & after
Same job, one pattern. The user no longer has to remember which tool says what.
Every pattern ships with the same template
When to use it
When not to use it
its states, including error and edge cases
Accessibility notes
Plain language content guidance
An owner
System
A pattern only matters if people use it when I'm not in the room.
So every platform follows the same path, and the path doesn't depend on me remembering to push it.
Illustrative. How a pattern moves from one team's need to a shared standard.
Today, 5 of 5 teams in my product area use the toolkit. That's the number I watch most, because adoption is trust.
2 Profile types
Investor and Professional
One pattern, used across both of them.
Counted
3 Use cases
Before a new pattern enters
Real ones, with designers to document them
Rule
Every pattern ships with the same template
Weekly stand up
Designers across the product area share what they learned, so one person's answer becomes everyone's.
Onboarding guide
New designers start with the decisions already made, not a blank page.
Intake system
Every request is timestamped and written down, so the reason behind a choice outlives the person who made it.
In build
Testing how contribution spreads across people, so the library has more than one author. No results yet.
Results
Five of five teams now use the toolkit. The savings are still the thing to prove.
Here is what I can count, what I can estimate, and what I can't claim yet. I'd rather you trust my small numbers than doubt my big ones.
Adoption
Counted
5 of 5
Teams
Using the shared toolkit.
Participants
Observed
5 of 7
Choose the first direction
In landing page study.
Business impact
Target
$6 to 7M
Call center cost a year
Projected, not yet measured.
Support tickets dropped about 40% (estimated)
Source: product area ticket counts, rounded. Estimated
By effort
User ID Information
Observed
Participating firms like it
Pilot feedback, not a measured result. Numbers come once analytics are on.
Inbound SSO
In build
Results come after launch
MVP 1 is in build. MVP 2 starts next month.
Bulk Reporting
Paused
No results claimed
On hold until reprioritized.
What I can't claim yet
The $6 to 7M stays a target until the patterns ship across the tools. The RACI pilot is still running, so I have no results for it. The ticket numbers are rounded estimates, not an audited count.
Reflection
What I'd do differently, and what I'm doing next.
If I started again, I would measure before I built. The legacy tools had no analytics, so I had no baseline, and my best evidence is research and pilot feedback. That's the first thing I'd fix.
I would also bring a second designer into the pattern library sooner. A system with one author is still one person's memory, and that was the exact problem I set out to solve.
The part that surprised me: nobody needed convincing that consistency was good. They needed proof it wouldn't cost them. Turns out the most persuasive design review is a template that saves someone a Tuesday.
What's Next
01
Measure after Launch
As analytics and click paths come online, I'll replace targets with counted results.
02
Finish RACI pilot
See whether the contribution spreads beyond me, then keep or change the model based on what happens.
03
Carry it further
I'm now part of the one-to-two-year roadmap. The next step is bringing the pattern library to the other platforms the product area owns.
