Unifying Payment Experiences at Scale

01 — The Challenge

A dozen teams, a dozen conventions, zero alignment

SafePay — JPMorgan's digital wallet — needed to be integrated into the Payment Design Library (PDL), the shared component system powering payment experiences across the bank. On paper, it sounded straightforward: add a new payment method to existing flows.

In practice, it was an alignment problem masquerading as a design problem. Each banking team owned a piece of the payment journey and had developed their own conventions. Dropdown behaviors differed. Payment method categorization varied. Balance surfacing was inconsistent. And nobody agreed on where "Link External Account" should live.

Why This Was Hard

This wasn't a greenfield design challenge — it was a retrofit into a complex, live ecosystem with real revenue implications. Every decision affected multiple teams, millions of transactions, and deeply embedded technical assumptions.

Without alignment, SafePay would ship as a patchwork — different experiences depending on which team's flow a customer happened to enter. That's not a design library. That's a contradiction.

02 — Discovery

Mapping the invisible landscape

Before proposing any solutions, I needed to understand the real shape of the problem — not the org-chart version, but the actual experience fragmentation across teams.

Audit: How different teams handled the same flows

I conducted a comprehensive audit of existing payment flows across all teams that would be affected by SafePay integration. The goal wasn't just to document differences — it was to understand why each team had made their choices.

Note on confidentiality

Due to a confidentiality agreement, I'm unable to display the BAU screens from the audit. The inconsistencies below are drawn directly from my findings.

Inconsistent capitalization across screens — Account labels, balance strings, and action text followed no shared casing convention. Some screens used title case, others sentence case, others all-caps — often within the same flow.

Inconsistent vertical spacing between account options — The gap between selectable account rows varied noticeably across teams, making the list feel dense on some surfaces and spaced-out on others with no clear rationale.

Selected account displayed as a blue link — On some screens, the selected account was styled in blue or teal, causing it to read as a hyperlink rather than a selected state — a meaningful and misleading distinction for users.

Checkmark used as a single-select indicator — Several screens relied on a checkmark to signal the selected account. While familiar in multi-select contexts, a lone checkmark does not clearly communicate that the list is interactive — particularly for users with low vision who rely on explicit affordances.

Identifying the four key decision points

The audit surfaced that alignment needed to happen on four specific design decisions — everything else could remain team-specific. This reframing was critical: instead of asking teams to change everything, I identified the minimum surface area for maximum coherence.

Dropdown styling — How payment methods are presented and selected

Payment method categorization — The taxonomy for grouping methods

Available balance surfacing — When and how to show account balances

Link External Account placement — Where this action lives in the flow

03 — Alignment

Influencing without authority

The hardest part of this project wasn't the design — it was getting a dozen teams to agree on anything. I didn't have authority over any of them. Success required influence, not mandate.

Workshop design

I designed and facilitated a cross-team alignment workshop structured to surface disagreements constructively rather than paper over them. The session architecture was deliberate:

1

Shared evidence base

Opened with the audit findings — grounding the conversation in observable reality rather than assumptions or preferences.

2

Divergent exploration

Each team presented their rationale for their current approach. This built respect for existing decisions before asking anyone to change.

3

Convergence on solutions

We presented each option side-by-side and asked teams to vote on what worked for them — and, critically, why. Surfacing the reasoning behind each vote helped us reach alignment rather than just a majority decision.

4

Decision capture

Each of the four key decisions was resolved in-session, documented with rationale, and assigned ownership for implementation.

Decision	Options Considered	What We Aligned On
Dropdown Styling	Relaxe & Centered-aligned, Condensed & Center-aligned, Relaxed & Left-aligned, Condensed & Left-aligned	Keep relaxed and center-aligned layout
Categorization	No cagegory, Categories on the MoPs	Optional categorization
Link External Account	Button & 12px padding at the top, Padding reduced to 4px, Link an external account with supplemtal link	Supplemnental link
Available Balance	Popover, Reduced padding & Upladed to Flyout, Static text with shorter content, Contextual Help Flyout for available balance	Contexual Help or read-only content area for definition

The breakthrough wasn't finding the "right" answer — it was structuring a conversation where twelve teams could discover the answer together.

04 — Design Decisions

Craft in the details

With a shared understanding of the context and a solution that could scale, the design work shifted to the specifics — getting each of the four decision points right at the component level.

Categorization: How should payment methods be grouped?

Categorizing payment methods in dropdown keeps options organized and easy to navigate, especially when both card art and logos are present, enhancing user experience and providing flexibility for complex payment journeys.

Balance surfacing: When should available balance be shown?

The Help icon opening a flyout is more compact and scalable for journey teams that manage multiple tasks and information on a single page. We also provided additional placement for available balance in the bottom of the screen to enforce the association between the dollar figure and the available balance definition.

Link External Account: Where does this action live?

The supplemtal information reduce visual clutter and is aligned with other Pay/ACH patterns.

05 — Outcome

What we shipped

10

Teams aligned on shared payment conventions

4

Key design decisions resolved in a single workshop

1

Unified SafePay integration in the PDL

SafePay shipped as a coherent, consistent experience across all payment journeys — not because every team was forced into compliance, but because they co-created the standard together.

The process we built didn't just solve SafePay — it gave the PDL teams a reusable model for making cross-functional design decisions at scale.

06 — Reflection

What I learned

On enterprise alignment

SafePay's internal audit gave us a strong foundation, but it could only show us what we could see from the inside. Sitting with journey teams and understanding their specific contexts surfaced gaps and constraints that no self-directed audit would have caught. The biggest lesson: the people closest to the problem always know something you don't.

On trust as a design material

Alignment didn't happen because we had the right answer — it happened because teams felt heard. When we named what SafePay offered and why it was designed the way it was, journey teams stopped treating it as an imposition and started treating it as a shared resource. That shift — from compliance to ownership — is exactly what trust looks like in a design system context.