J.P. Morgan · Client Journey / UX Strategy · historical work

Creating one Payments experience across six Product domains

Customers experienced one Payments journey while approximately six Product domains were managed independently. The work used journey and service design to make cross-Product friction and its backstage causes visible.

2018–2019 experience-strategy chapter

90-second case

Problem
Customers moved through one Payments journey while the organization managed approximately six Product domains independently.
Mandate
Lead UX and client-journey strategy, translate business goals into Experience and service priorities, and partner with Product and Engineering.
Decision
Treat the journey as a system of customer and operational signals—not as a screen inventory.
What happened
The work aligned an end-to-end journey mandate, Product and Engineering partnership, stakeholder priorities, and solution direction across Product domains.
Why it matters now
It shaped the view that the relevant design unit is the full system that produces the customer outcome.

My role

How I contributed.

I led UX and client-journey strategy, translating business goals into end-to-end Experience and service priorities.

I partnered with Product, Engineering, customer-facing teams, and business stakeholders to connect visible customer friction to the Product and operating decisions beneath it.

Current reconstruction

The core mechanism.

A present-day visual of the system described in the case.

Journey evidence → system cause → Product consequenceVisible customer friction was traced through process, policy, data, ownership, and platform causes before it became a Product priority.

Judgment under constraint

Decisions that shaped the work.

Decision

Use the journey as a decision system, not a presentation artifact.

Why it was hard
A polished journey can describe friction beautifully while leaving the priorities, ownership, and system conditions that create it untouched.
My judgment
Connect material friction to its customer goal, likely system cause, responsible partners, and Product or service decision path.
Consequence
The work gave Product, Engineering, and business stakeholders a shared cross-domain frame for prioritizing the customer experience.

Historical work

Experience strategy expanded the frame beyond the interface.

The assignment combined UX design strategy with end-to-end customer journey definition, stakeholder alignment, design-thinking practices, solution direction, internal enablement, and the translation of business goals into Experience and service priorities.

That mandate required working across the frontstage experience and the backstage conditions that made it possible, in partnership with Product and Engineering.

  1. 01Customer journey

    Orient · begin · provide · coordinate · wait · resolve · confirm

  2. 02Visible friction

    Repeated information · lost context · opaque status · difficult recovery

  3. 03System causes

    Product boundaries · tools · policy · handoffs · decision rights

  4. 04Decision path

    Experience priority · Product opportunity · service or organizational response

Enterprise design strategy

The journey exposed dependencies that no surface treatment could resolve alone.

Customers did not experience a Product-domain org chart. They experienced one outcome crossing independently managed capabilities. A consistent interface could reduce some friction, but it could not by itself reconcile conflicting roadmaps, fragmented information, ownership gaps, or service recovery.

The strategic value was not visual polish. It was making a cross-Product system legible enough for different leaders to see the same customer problem and its dependencies.

From journey evidence to Product delivery

Turning client journeys into Product decisions.

I created an Innovation Playbook that connected client pain points and strategic opportunities to discovery, Product definition, prototyping, delivery, and release validation.

The journey work did not end as a service blueprint. It translated current, next, later, and target states into Product capabilities, feature-level customer outcomes, personas and scenarios, workflow definitions, prototypes, and user feedback.

The framework covered three broad client journeys across eleven experience areas: getting started through discovery, contracting, onboarding, and integration; accepting payments through coverage, fraud, funding, and disputes; and growing or operating the business through service, reporting, data, and insights.

Experience became a mechanism for connecting customer reality to Product and organizational decisions.

  1. 01Client & field reality

    Pain points · workflows · strategic priorities

  2. 02Opportunity

    Customer outcome · business relevance

  3. 03Discovery

    Personas · scenarios · experience areas

  4. 04Product definition

    Capabilities · feature-level customer outcomes

  5. 05Prototype + test

    Design theses · prototypes · user feedback

  6. 06Delivery

    Product · Engineering · dependencies · validation

  7. 07Release + learning

    Outcome validation · next Product decision

Present-day interpretation · retrospective

Customer-experience fragmentation can be organizational fragmentation made visible.

I now see this work as an early encounter with a transformation problem: the customer outcome crossed the boundaries through which the company managed Product, resources, and decisions. Experience work could expose the topology; it could not manufacture the authority to redesign all of it.

That is a present interpretation, not the historical label for the assignment. The historical work was UX and client-journey strategy. Its current relevance is the systems lesson it revealed.

Then

UX / client-journey strategy

Make the end-to-end customer experience and its Product/service causes visible.

Now

Transformation interpretation

Design the outcome system and align authority with the changes required across its boundaries.