Only about 10% of Wells Fargo’s native app used design system components.
I helped rebuild 30+ components across three systems, helped introduce a review step that nearly eliminated unnecessary detachment, and trained around 20 designers to use the new components.
Solution - a centralized tracker was introduced.
The problem: the system was failing designers
Detached instances were everywhere.
Designers weren’t ignoring the system. Components were missing properties, couldn’t flex, and didn’t scale. So they detached.
.png)
The ecosystem: one umbrella, three systems
Fusion (umbrella)
I worked across all three, building components, guidelines and quality checks for each.
Native
iOS & Android apps
The highest priority, with the toughest challenges.
Responsive
Web & responsive experiences
The biggest room for improvement.
Fargo
Conversational chatbot
Newer territory, with more motion and animation.
Challenge #1
Detachment was a signal, not a mistake.
The product was also evolving (softer corners, minimal layouts, bolder hierarchy), and Figma now offered variants, booleans and instance swaps that our old components didn’t use.
The approach: start with what designers use most
Fusion 2.0 didn’t begin with a rewrite. We rebuilt the most-used components first, guided by real design requirements. I owned the full lifecycle:
Research → Build → Stress-test → QA → Document → Train
My biggest contribution:the thinking behind every component
Building components was the visible part. The bigger contribution was the research process that decided what to build:
-
Internal audit: where does the current component work, and where does it break?
-
Scenario mapping: every context it appears in, from short tasks to long flows
-
Designer conversations: what workarounds are people using?
-
Competitive research: banking, e-commerce, productivity, plus other design systems
-
Best-in-class insights: what to adopt, what to avoid, where we already lead
Every component started from evidence, not opinion.
Case study: the Progress Bar
One component shown in depth. The same process applied to 30+.
Before: a single progress bar. No target indicator, limited colors, thin states.
After: a flexible family
-
Single progress bar, with and without leading labels
-
Incremental progress bar (up to 5 steps)
-
Progress gauge
-
Target indicator, richer states, more color options
Built to be toggled, not detached. Title, labels, target indicator and support text are modular parts. Accessibility is built in: contrast, keyboard navigation, screen readers.
What I found in responsive components
Auditing and VQA-ing the responsive components showed that small structural issues caused big breakage:
-
Auto layout wasn’t set up properly, so components didn’t scale
-
No instance swaps, so adding content meant detaching
-
Changing a simple width or height often meant detaching
We rebuilt them with proper auto layout, instance swaps and flexible properties. Most of what designers needed became a property change, not a detach.
Making it hold: break it, then check it
Stress testing: “Can this component break?”
Several designers used each component on live screens. Edge cases and misuse surfaced early, and fixes went straight back into the component.
Visual QA: “Does it meet our standards?”
Using KitchenSync (our Android and iOS test app), I checked states, variants, typography, spacing, color tokens and interactions. Every discrepancy was logged for developers, and every fix was re-verified before release.
One template for every component
I was on the core team that revamped the guidelines framework with the Design Lead and the US Content Head. Every component now follows the same structure:
Overview · Anatomy · Tap targets · Best practices · Variants · Figma usage · Properties and tokens · Accessibility (including 200% text zoom) · What’s new
The hard part: changing how the team worked
When I joined, components went through no dedicated design-system review. Adding one was not popular. Stakeholders across lines of business worried about slower delivery.
I held my position, and together with the Fusion team we built the case and got leadership approval.
The result: one added review step. If a designer needs to break a component, they declare it upfront. A design system member checks whether a small fix or variant can solve it, or whether the detachment is truly needed.
Every detachment became a conversation, and every conversation made the system better.
Impact
Native
iOS & Android apps
The highest priority, with the toughest challenges.
Responsive
Web & responsive experiences
The biggest room for improvement.
Fargo
Conversational chatbot
Newer territory, with more motion and animation.
Adoption: training the team
I ran in-person training for the India Design and XT teams, about 20 people: guideline walkthroughs, new properties and variants, and short hands-on tasks.
Training Approach
-
Walkthrough of updated guidelines and recent component changes
-
Explanation of new properties, variants, and usage patterns
-
Quick, task-based exercises for hands-on learning
Bonus - Indirect Stress Testing
Group usage during training naturally revealed edge cases and usability gaps, which were fed back into component improvements.
Our Story in Numbers
30K
Item Title
Use this space to explain the above number.
+27%
Item Title
Use this space to explain the above number.
15M
Item Title
Use this space to explain the above number.
890
Item Title
Use this space to explain the above number.
Impact
30+
Components rebuilt across Native, Responsive and Fargo.
Use this space to explain the above number.
+27%
Item Title
Use this space to explain the above number.
15M
Item Title
Use this space to explain the above number.
890
Item Title
Use this space to explain the above number.
890
Item Title
Use this space to explain the above number.
Impact
30+
Components rebuilt across Native, Responsive and Fargo.
~20
Designers trained in person, now using the components correctly.
1
Guideline format, consistent across every component.
Minimal
Detachment. Variants and properties meet most needs, and the rest go through review.
End to end
A process that now runs from research to stress test, VQA and review.
What I took away
-
Detachment data is user research. It shows what the system is missing.
-
Flexibility beats volume. Good properties beat dozens of variants.
-
Process is part of the product. The review step mattered as much as any component.
-
A component isn’t done at handoff. It’s done when designers use it well.
Fusion 2.0:A Component- Led Design System Evolution
2024-25
Agency
Wells Fargo, Bangalore
My Role
Research, Design system
Tools
Figma
Contributed to the evolution of Fusion into a scalable, component-led design system by working on core component creation, guidelines, stress testing, VQA, and designer enablement. Helped reduce component detachment and improve consistency across design and development through structured processes and hands-on collaboration.