John Leufray

Product Lead • Fintech & Compliance

FIS

Modernizing a Flagship Fintech Platform

Lead product designer on a white-label retirement management platform adopted by Wells Fargo, Deloitte, and T. Rowe Price, driving a full mobile and desktop redesign through three rounds of structured validation across ~1,000 pages.

Role
Lead Product Designer
Stage
Live
Platform
Web, Mobile, iOS / Android
Category
Fintech / Retirement
White-label
Product validation
Design systems
A/B Testing
Offshore team management
Accessibility
Responsive design
01 – Problem
Retirement platforms were built for compliance, not people

Two decades of financial infrastructure, and nobody considered the real user

FIS is one of the largest fintech infrastructure companies in the world, powering the back-end of banks and financial institutions across the globe. Their retirement management platform was technically robust but visually dated, difficult to navigate, and built around institutional requirements rather than the people actually managing their retirement accounts.

Banking institutions needed a platform they could brand as their own and felt native to their product ecosystem. End users needed something that simplified the financial complexity of retirement planning without hiding the information they needed to make decisions. Both needed it to work flawlessly across desktop, mobile, and tablet.

The challenge wasn't building new features. It was making two decades of complex financial infrastructure feel intuitive to someone checking their balance on a phone.
Institutional Need
White-label flexibility for major banks
Banks like Wells Fargo needed a platform they could brand entirely as their own, applying colors, logos, and style guidelines without rebuilding the underlying system.
User need
Clarity over complexity
Retirement account holders found existing platforms confusing with financial jargon, dense data tables, and navigation built for desktop workflows that broke down completely on mobile.
02 – Research & Validation
Three rounds of live testing across over 1,000 pages

Every product decision that mattered came from a user, not a brief

Rather than designing based on assumptions, the product direction was driven by structured validation with twelve participants consisting of retirement account holders, which were conducted across three rounds of live, screen-shared testing.

Each round produced specific, actionable findings that directly changed product decisions before they went to engineering. This wasn’t usability theater, it was the primary mechanism for prioritizing the redesign.

12
participants across account holders, banking reps, and financial advisors
1,000+
unique pages validated across desktop, mobile, and iOS/Android
3
rounds of live testing, each driving specific redesign decisions
Round 1
Desktop – Language & communication gaps
Users struggled with financial jargon throughout the platform. They also expected email confirmations for account changes, which was a communication gap that had never been surfaced internally. Both findings changed product requirements, not just design.
Round 2
Mobile – Data tables were unusable
The desktop data table approach translated directly to mobile and failed completely. The initial solution was to use scrolling tables, but users couldn’t navigate complex financial data on smaller screens. Tables were rebuilt from scratch for mobile, focusing on clarity and readable hierarchy.
Round 3
A/B Validation – Live adjustment during sessions
Alternate designs were tested against each other in real time. Live adjustments were made during testing sessions based on what users responded to, which was an unusual approach that compressed the iteration cycle and produced clear directional signal before engineering committed resources.
03 – Product Decisions
What the research changed and what it didn’t

Good research produces decisions, not just observations

These are the specific product directions that changed as a direct result of validation findings, and the decisions that held despite user feedback.

Changed
Mobile data tables rebuilt from scratch. The desktop pattern was not adapted, it was replaced entirely with a mobile-native card approach after Round 2 showed the adaptation was unusable.
Changed
Email confirmations added for all account changes. Users expected this as a standard banking behavior. The platform had relied on in-app confirmation only, a gap that created trust issues.
Changed
Financial language simplified throughout. “Jargon” wasn’t decoration, it was embedded in labels, form fields, and status messages. Rewrites happened at the content level, not just the UI level.
Held
Core information architecture kept intact. Users wanted simplification still needed access to the full depth of account data. Simplicity came from navigation and language, not from hiding features.
04 – Competitive Context
Where FIS had a gap, and where it had an edge

White-label flexibility was the differentiator that mattered to the banks

Vanguard and Charles Schwab represent the consumer retirement experience most users were familiar with. FIS Retirement wasn’t competing for the same user, it was competing for the institutional contract. The white-label capability and projected retirement income tools were the differentiators that mattered to the banks buying the platform.

VanguardCharles SchwabFIS Retirement
White-label customization
Email notifications
Retirement management
Projected retirement income
05 – Design System
Built to be owned by someone else

A token-based system that let enterprise customers make it entirely their own

A white-label platform has an unusual design constraint: everything you build will be reskinned. The system has to be flexible enough to absorb completely different brand identities (different colors, different logos, different typographic styles) without breaking the underlying UX logic.

The design system was built around this constraint from the ground up. Components were tokenized so that color, typography, and spacing could be overridden at the institution level without touching the structure. The result was a platform that Wells Fargo, Deloitte, and T. Rowe Price could each make look and feel entirely native to their brand.

Token Architecture
Brand applied at the variable level
Colors, spacing, and typography defined as tokens instead of hardcoded. Institutions override the token set, not the components. The system adapts without rebuilding.
Accessibility Baseline
Compliance built into the system
Accessibility documentation and UI specifications managed by an offshore team, with standards built into the component library, not added as an afterthought per platform.
Multi-Platform
One system, three surfaces
Desktop, mobile, iOS, and Android all served from the same design system. Components adapted per surface, not duplicated, so updates propagated across all four.
Team management
Offshore coordination across time zones
International design team handled accessibility documentation and UI specifications. Managing required clear documentation and precise handoff standards.
06 – Scope of Work
What I owned during product development

Design, testing, and team management from first session to final handoff

  • Product Validation: Three rounds of live usability testing across ~1,000 pages, designing the research plan, facilitating sessions, synthesizing findings, and translating them into product decisions.
  • UX Design: End-to-end information architecture, flow design, and interaction design across desktop, mobile, and iOS/Android.
  • UI Design: Visual system and component design for all platform surfaces.
  • Design System: Token-based white-label system allowing institutions to apply full brand customization without rebuilding components.
  • A/B Testing: Designed and ran alternate design tests in live user sessions; made real-time product decisions based on observed behavior.
  • Stakeholder Alignment: Presented interactive prototypes at company level to secure executive buy-in and gather institutional stakeholder feedback.
  • Team Management: Managed offshore design team responsible for accessibility documentation and UI specifications across all platforms.
07 – Solution
A platform that works for the user and the bank

The final platform served two audiences simultaneously: the end user managing their retirement account and the banking institution that needed to make it their own.

User-Friendly Dashboard: Instant account overview with balance, investment performance, and quick access to key actions. Designed to surface the information users checked most frequently without requiring navigation.

Rate of Return Widget: Real-time investment performance tracking at a glance. One of the most-requested features from user research, previously buried in a sub-page, elevated to the dashboard.

Transaction History: Full transparency over past and pending transactions. Mobile versions direct users to submit required documentation on desktop after testing showed the original table approach was unusable on smaller screens.

Distribution Center: Streamlined withdrawal and transfer flows. Simplified the process of accessing retirement funds or rolling them into new investment accounts, which was previously one of the most confusing workflows on the platform.

Email Confirmation System: Added to the product as a direct result of Round 1 research findings. Users expected confirmation of account changes to arrive in email, and the platform had relied on in-app confirmation only. A product requirement, not a design detail.

Documents Library: Centralized access to plan documents, statements, and disclosures. Designed around how users actually searched for documents (by date and type) rather than how the institution organized them internally.


Takeaways

FIS was the project where I learned that research only has value if it changes something. Three rounds of live testing across a thousand pages isn’t impressive on its own. What matters is that each round produced specific product decisions that went to engineering with confidence rather than instinct. Neither the mobile table redesign, the email confirmation system, nor the language overhaul were in the original scope. They came from users telling us what was broken.

Managing an offshore team across that timeline also clarified something about design systems: the discipline required to hand off work to someone in a different time zone is exactly the discipline that makes a system good. If a component isn’t documented clearly enough for an offshore designer to implement correctly, it isn’t documented clearly enough for the institution to customize it either. That constraint made the system better.

Next Post

Previous Post

© 2026 John Leufray. All Rights Reserved.