JPMorganChase has a proprietary platform it has used since 2018 to connect developers to AWS, manage accounts and run applications.
With the second iteration of this platform, self-service cloud infrastructure provisioning and greater architectural ownership addressed many technical pain points, but user experience challenges remained. Frequent context switching, slow approvals and limited visibility into deployment progress continued to frustrate engineers.
UX was brought in to help cloud architects, application owners and development teams onboard to the cloud platform, streamlining their journey and providing contextual support to drive applications to production.
This project ran from November 2024 to February 2026 across several distinct phases — from domain orientation and journey inheritance through to service blueprinting and experience improvement. My scope and seniority grew over the course of the project, culminating in an experience lead role from mid-2025.
Methodology
Service design on this project followed a discover, align, define pattern. In the discovery phase, I worked directly with cloud architects, engineers and product to map existing journeys end-to-end — capturing not just the user-facing steps but the backstage actions, approval dependencies and support touchpoints that made the experience as complex as it was. These maps formed the basis of cross-functional workshops where we brought together architects, product, engineering and real users to surface gaps and build a shared understanding of the problem. From there, we moved into defining the to-be state — redesigned journeys that reduced friction, clarified ownership and gave engineers the context they needed to move forward confidently.
The service blueprints mapped six core journeys: OU and VPC creation, account creation, infrastructure provisioning, cloud chaos onboarding, approval flows, and support touchpoints. Mapping these end-to-end — including the backstage actions engineers couldn't see — made the sources of friction immediately visible. Long approval chains, unclear ownership handoffs, and missing in-context guidance emerged as consistent themes across journeys, giving us a clear, evidence-based foundation for how these journeys should look.
Outcomes
For cloud chaos onboarding specifically, blueprinting revealed that engineers were touching multiple separate products and raising several separate requests — each requiring its own approval from the same approver — to complete a single onboarding journey. Redesigned flows consolidated this into a single, unified experience, and reduced the approval workload for application owners too.
A key tension throughout the project was designing for a wide spectrum of users — from experienced cloud architects comfortable creating OUs and VPCs, to developers with less architectural domain knowledge who needed more guidance to complete the same tasks. This meant building in more mechanisms for in-context help and concept explanation than we would typically include. Rather than cluttering the UI with persistent instructional content, we defined a reusable interaction pattern for surfacing additional context on demand — keeping the interface clean for experienced users while ensuring less experienced developers were never left without the information they needed.
Journeys that reduced cognitive load, dramatically cutting the number of tools engineers needed to create cloud infrastructure and onboard to mandatory resiliency tooling. To use an example from Cloud Chaos Resiliency onboarding, optimized journeys highlighted the following improvements:
87%
Fewer products to navigate
67%
67%
Entering a complex domain like cloud infrastructure, it's tempting to jump straight into solutions. Mapping assumptions first — about what engineers knew, what the platform did, and where ownership sat — gave us a clearer picture of where to focus our research. Investigating those assumptions with real users and architects consistently surfaced opportunities we wouldn't have found otherwise, and organising our work around those opportunities kept the team aligned on what actually mattered.
Cloud infrastructure is genuinely complex, and pretending otherwise doesn't serve engineers. The challenge was exposing that complexity in a way that felt manageable — breaking long journeys into clear stages, surfacing only the information relevant to each step, and providing in-context support for unfamiliar concepts. Engineers didn't need the complexity removed; they needed it structured.
Shadowing early 2.0 adopters and documenting their experience across documentation, UX and support channels gave us a ground-level view of where the product was falling short that no amount of usability testing could replicate. Support teams absorb the friction users don't report directly — watching what questions they fielded, and how often, pointed us towards the highest-impact improvements and gave us a way to communicate those opportunities credibly to leadership.
One of the most compelling things we could show stakeholders was a before-and-after in concrete terms: dramatic reductions in the number of products touched, requests raised, and approvals needed. Capturing these metrics as part of the service blueprinting process gave us a clear, quantifiable story about what UX-led journey redesign actually delivers — one that resonated with both engineering and leadership in a way that qualitative findings alone rarely do.