Ashley Kim · Lead Designer · J.P. Morgan Global Private Bank Design Studio

After the U.S. platform shipped, the harder question arrived.

Can four banking products share one workflow, without breaking any of them?

ACE is the cloud system replacing every International Private Bank platform with one. I lead design for Asset transfer and Lending, and for the design system underneath all of it. One workflow pattern now runs Payment, Lending, Asset transfer, and Deposit. Launched 2025. 25% of IPB products migrated so far.

ACE Transfer: shared header with three stage tabs

workflow pattern, 4 products

600+

advisor, client service, and ops users

25%

of IPB products migrated

2027

full platform target

Try the prototype See the numbers

The numbers The problem The journey The product The decisions Scale Reflection

RoleLead designer for Asset transfer, Lending, and the design system. Two designers total on ACE: I lead those three, my partner leads Payment and Deposit.

WhenMarch 2024 to 2027 · internal product · in flight

StatusLaunched 2025 · 25% of IPB products migrated · full migration targeted 2027

02 · The journey

From four workflows to one shared pattern, step by step.

March 2024 · the starting state

A platform migration with four product teams, each carrying years of habits from their own legacy tools.

Discovery

I researched all four products’ workflows: what was manual, where tickets got lost, and which feature upgrades the legacy platform had blocked. User interviews across advisors, client service, and operations, plus workshops where each product owner walked me through their workflow, and I mapped every workflow side by side as I went.

Finding the pattern

I took the two most complex flows and detailed them until the common pattern surfaced. If the pattern held for the hardest two, the other workflows could fit inside it.

Present and iterate

I presented the pattern to all four product teams with one question: does this fit your product? The side-by-side workflow map made the shared stages easy to see, and team feedback drove iterations until every product could see its own workflow inside the shared one.

Test and lock

I validated the pattern on a Lending workflow it had never seen, then user testing with 4 users confirmed the flow. The pattern was locked as the platform standard.

Scale by governance

The governance model scaled the pattern to every product: teams flag workflows that do not fit, I take the requirement, apply it to the shared workflow, and extend the pattern. Master design hand-off files and documentation put the pattern in front of stakeholders before requirement decisions are made, and each new requirement widens the platform instead of forking it.

Launch · 2025

QA, pilot testing, then launch. 25% of IPB products migrated, with user testing feeding the next wave.

03 · The product

Try the Asset transfer workflow. Every stage is clickable.

One shared header holds the client, the case, and the risk lights. The three tabs are the three stages of the pattern. Only the content below the tabs changes.

Reconstructed prototype with dummy data · Transfer initiation → Control check → Ops processing

How to read the design

InitiationGates before anything moves: signature check, "is this party authorised," a registered sender email, and quantities confirmed twice, in a select table and again in a finalise table.

Control checkAutomated controls run on submit. A failed check is never just a red icon: the same row carries the reason, the next step, and who it was assigned to.

Ops processingA staged pipeline per security. Approvals move forward, rejects route back or conclude, and only Swift exceptions (ALR block, On hold) pull a human into manual settlement.

The ops pipeline was A/B tested

Version A, three-stage maker checker pipeline

Version A. Three stages: Maker, Checker, Completed. Simple, but after submission a security's backend state is invisible. Real screen, dummy data.

Version B, shipped. Initial approval, Ready to release, Pre-settlement check, Concluded. Each stage carries its own actions, and Swift exceptions surface as a stage. Users chose visibility. Real screen, dummy data.

04 · Major decisions

Four calls that shaped the platform.

DECISION 1

One workflow pattern for four products.

Alternatives

Each product team wanted a custom workflow optimized for itself. That is how the legacy platforms became four different tools nobody could move between.

The call

I proposed one pattern with small variations, and laid all four products' workflows side by side, stage by stage, on one map. Seeing the shared stages next to each other is what won the room: Initiation, Approval, Control check everywhere, and a per-product final stage where products genuinely differ. That side-by-side comparison is also what got all four products to one learnable pattern.

Outcome

Consistency and easier onboarding across every product, and a pattern new products can adopt without a redesign.

DECISION 2

Control check is universal. The final stage is not.

Why

This was the line I held: every product moves money or assets, so automated controls are non-negotiable everywhere. Settlement is where products truly differ, so I let only that stage vary. Flexibility earned everywhere else, none at the control gate.

The design

One control check table for all workflows: check name, status, and when something fails or pends, the reason, the user action, and who got assigned, all in one row. Visibility across every user touching the ticket.

Outcome

Missing tickets dropped to zero, tracked before and after the stage shipped. Issues get resolved together instead of lost in inboxes.

DECISION 3

Ownership is part of the interface.

Why

Multiple users work one ticket. When ownership lives in people's heads, coordination is manual and every handoff adds delay and risk.

The design

Each step names who initiates, who validates, and who completes. Securities move through assign, validate, and completed tables with approve and reject at each step, so the interface itself is the coordination.

Outcome

Progress is visible as structure: stage counts and tables say exactly where every security stands and whose move it is.

DECISION 4

Bulk upload: fail ambiguous rows, or resolve them in the app?

The conflict

Asset transfer tickets carry 20 to 50 securities, sometimes 100+. Bulk upload reads the client’s Excel instruction sheet, but instructions describe each security in about 12 columns and the system could read only 5, so one row could match several securities. The requirement said: on a multiple match, fail the row and let the user search and pick by hand. Product called anything more a luxury feature. No time, no resources.

My case

I saw a risk, not a luxury. Every failed row sent the user out of the app to cross-check the instruction sheet, then back in to re-search and pick, one round trip per security. Twenty securities, twenty round trips. Confusion meant mistakes, mistakes got caught mid-review, tickets bounced back to the first user, and completion time grew. That time reaches the client.

The test

Instead of arguing, I offered evidence. I designed both flows, built the A/B test myself, put users on both, and brought the results to the product executive director to make the call.

Outcome

The in-app resolution won: users caught problems early, big or small, and the design shipped. No other bulk upload had this feature. It was recognized across the Private Bank org and delivered Private Bank-wide, adopted by other bulk-upload products.

The flow

Finalise security details with Bulk upload entry

Step 1. Bulk upload lives inside Finalise security details, next to the approved template.

Step 2. Upload the Excel template. Up to 500 securities per file.

Step 3. Right after submit, every multiple match is resolved in-app: candidates per security, select, apply. Real screens, dummy data.

UNDERNEATH

A design system built alongside, not after.

Why

The old system met neither product needs nor accessibility standards, and a shared pattern needs shared components to stay shared.

The design

A new design system meeting accessibility standards, supported in Storybook, plus a content glossary that levels product, engineering, and new designers on one brand voice.

Outcome

The pattern survives new products and new hands because the pieces it is built from are governed.

05 · Scale

One pattern, four workflows, and room for the next ones.

The shared spine — identical on all four

Initiation → Approval → Control check runs every product. Only the product-specific tail (and Payment's pre-approval callback) changes.

Initiation

Approval

Control check

Product-specific

Asset transfer

Initiation

Approval

Control check

Ops processing

Lending

Initiation

Approval

Control check

Validation

Deposit

Initiation

Approval

Control check

Validation

Payment

Initiation

Approval

Control check

+ Callback (pre-approval) · Post booking

Users600+ advisors, client service, and operations today. The pattern is designed to extend to the next audiences: chief officers, managing officers, and oversight roles who need the same visibility without the workflow.

Products25% of IPB products migrated. The rest migrate onto the same pattern through 2027, and new workflows adopt it instead of inventing one.

TeamTwo designers run four products because the pattern carries the weight: I lead Asset transfer, Lending, and the design system, my partner leads Payment and Deposit, and the master design files keep us aligned.

InfluenceThe hand-off files exist because I learned the hard way that stakeholders decide before designers arrive. Master designs and pattern documentation now reach product partners before requirement decisions, so the pattern shapes the requirements instead of chasing them.

06 · Reflection

What leading four products proved.

1Governance was the real design work. Owning the pattern across four products meant that every time one product solved a problem, I judged the solution twice: did it work for that product, and could it scale to the other three and to products that had not arrived yet. Solutions that passed both tests became the pattern.

2Communication carried the pattern. Four products made decisions every week, and a decision in one quietly changed the ground under the other three. Half my job was making each design decision visible to the other teams — through the master files and pattern docs — so alignment happened before build, not after.

3Evidence settled conflicts, opinions did not. One product agreed, another disagreed, and the turnaround was always short. What worked was showing that the pattern already ran successfully in a sister product and why that mattered — and when the conflict was real, user testing and A/B results backed the call instead of my opinion.

Still in flight, honestly: the migration is at 25%, the 2027 target is real work, and the next launches will test whether the pattern holds for products we have not met yet. Geneva, Singapore, and Hong Kong are next, shipping more features in January 2028.

Can four banking products share one workflow, without breaking any of them?

Every metric below includes how it was measured.

Legacy platforms, manual workflows, and tickets that simply disappeared.

From four workflows to one shared pattern, step by step.

Try the Asset transfer workflow. Every stage is clickable.

Four calls that shaped the platform.

One workflow pattern for four products.

Control check is universal. The final stage is not.

Ownership is part of the interface.

Bulk upload: fail ambiguous rows, or resolve them in the app?

A design system built alongside, not after.

One pattern, four workflows, and room for the next ones.

What leading four products proved.

Three systems, one obsession.