1. The Product & The Domain

Stress testing is how banks prove they can survive. Under regulations like Dodd-Frank, Basel III, and DFAST, financial institutions are required to model how their portfolios, capital reserves, and internal controls would hold up under simulated economic shocks — market crashes, credit crises, sudden liquidity events. The outputs don’t stay internal. They go to regulators. They determine capital allocation. They shape whether a bank is considered sound.

The process is also enormous. A single stress test cycle can involve hundreds of data sources, dozens of models, multiple teams across risk, economics, and compliance — all working in parallel, all dependent on each other’s outputs, often across different time zones and different vendor systems. Before this product existed, most of that coordination happened over email and spreadsheets. A complete stress test setup took an average of 33 days.

Oracle Financial Services Stress Testing & Scenario Analysis — OFSSTSA — was built to change that. The product’s goal was to give financial institutions a centralized platform where analysts and managers could build, orchestrate, and analyze stress test scenarios through a unified, intelligent experience. Something that could automate what was manual, connect what was siloed, and cut that 33-day cycle down to something that didn’t consume an analyst’s entire quarter.

When I joined this project in late 2022, none of that existed yet. The product was a concept, a set of requirements, and a global team of stakeholders waiting for someone to make sense of it. I was brought in to build the UX foundation — the information architecture, the interaction models, the workflow patterns that would make everything else possible to design.

2. Entering the Ambiguity

I had no background in financial risk analytics when I joined this project. That’s not unusual for the Oracle UX consulting model — we were deployed to where the need was greatest, often into domains we’d never touched. What I didn’t expect was how quickly the domain complexity would be dwarfed by the scope complexity.

The team I was joining spanned Bangalore, London, New York, Cape Town, and Melbourne. On the product and development side alone, there were fifteen people. Another fifteen subject matter experts. Twelve external customers. Scheduling a single meeting required accounting for time zones that barely overlapped. Collaboration happened asynchronously more often than not, which meant every artifact I produced had to communicate clearly without me in the room to explain it.

Yugesh Madhivanan, the product manager based in Bangalore, was my closest working partner throughout the project. He had deep domain knowledge and strong opinions about where the product needed to go. What the project didn’t yet have was a clear picture of the UX scope — how much needed to be designed, in what order, and what could realistically ship first.

That’s when I brought in Marcus, our research director based in Melbourne, for the initial discovery phase. As we started mapping the problem space together — user goals, workflows, system dependencies, regulatory requirements across CCAR, DFAST, Basel III and more — it became clear that what we were looking at wasn’t one design project. It was six. The full scope of OFSSTSA covered variable management, scenario configuration, model governance, process orchestration, results compilation, and user management — each a substantial design effort in its own right, each dependent on what came before it.

No one on the team had scoped it that way yet. Mapping that landscape and breaking it into six sequential streams was my first significant contribution to this project — before a single wireframe, before any discovery artifacts were shared with the broader team. My consulting team owned Streams 1 and 2. The work we did there was substantial enough that the product team hired their own dedicated UX designers to carry Streams 3 through 6 forward. The foundation held.

3. Understanding the Users

Stress testing isn’t done by one person. It’s a coordinated process that spans an institution from the boardroom to the analyst’s desk — and understanding that full chain of accountability was essential before we could design for any part of it.

At the highest level, the pressure comes from two directions: the bank’s own board of directors, who need stress test results to understand risk exposure and inform strategic decisions, and the supervising authorities — regulators like the Federal Reserve, the EBA, the RBI — who require those results as proof that the institution can withstand economic shocks. Neither of these groups would touch the product directly. But their requirements shaped every workflow inside it.

The people who would actually use the product every day were two levels down. We called them Ann and Mani — an Analyst and a Manager, the core stress testing team at any financial institution.

Ann is the maker. Her goal is to test the bank’s resilience under various stressed scenarios and deliver an accurate report to Mani — one that helps him evaluate whether the bank can survive extreme financial events and meet regulatory requirements. Mani is the reviewer. His job is to ensure accuracy throughout the entire lifecycle: defining scope, assigning responsibilities, verifying every layer of Ann’s work, and getting leadership sign-off before anything is submitted.

The accountability chain between them defined the core design tension: Ann’s job is to build; Mani’s job is to verify everything Ann builds. The product had to serve both modes without making either feel like they were working inside the other’s system.

4. Discovery

Before I could design anything, I needed to reach functional fluency in a domain I’d never touched. Desk research came first — not to become a stress testing expert, but to understand enough about regulatory frameworks like CCAR, DFAST, and Basel III to ask useful questions when I got in front of the people who actually did this work.

Those conversations happened across time zones and continents. I interviewed 15 users — risk analysts, managers, and subject matter experts based in Cape Town, Melbourne, New York, Bangalore, and London. I started every session with background, goals, and workflow before moving into structured Shape of Data questions: a set of quantitative prompts designed to understand what the interface would actually need to hold — how many users, how many teams, how much data, how many decisions happening simultaneously inside a single stress test cycle. Understanding the person always came before understanding the numbers.

The numbers, when they came, were striking.

This work was recognized internally as among the strongest Shape of Data research on the team. What mattered to me wasn’t the recognition — it was what the numbers made possible. The SOD gave the entire cross-functional team a shared, grounded picture of the system we were designing for. It reframed what had felt like a software problem as a coordination problem at massive scale. And it made the case, clearly and with evidence, for why the design had to be phased.

5. Phase Planning

The Shape of Data didn’t just quantify the problem — it revealed one. This product couldn’t be designed as a single effort. The scope was too large, the dependencies too tangled, and the regulatory stakes too high to treat it as one continuous sprint. We needed a plan before we could design anything.

No one on the UX team had done this kind of work before. Entering a project mid-ambiguity and breaking it into something buildable wasn’t in the brief. It was a judgment call — one I made with Marcus before any wireframes existed, before any design had been socialized with the broader team.

Together we mapped the full product scope into six sequential streams, each representing a distinct functional area with its own design requirements and dependencies. The sequencing mattered. Stream 1 — project planning and analysis configuration — had to come first because everything downstream depended on it. Variables before scenarios. Scenarios before orchestration. The order was itself a design decision.

Our team owned Streams 1 and 2. The remaining four were scoped and sequenced clearly enough that the product team could hire their own UX designers to continue from there. That handoff only worked because the foundation was legible — not just to designers, but to product managers, engineers, and leadership across three continents.

6. Establishing the Foundation

With the scope mapped and the phases defined, the next question was: what does the current experience actually look like, and what are we trying to replace?

The As-Is Script was how we answered that. Rather than a dry list of pain points, we built a narrative — a day-in-the-life storyboard following Ann and Mani through a real stress test cycle, moment by moment, frustration by frustration. Ann hunting through old emails to find last year’s plan. Mani waiting a week for scenario PDFs. Ann manually reconciling 250+ data sources. Ann dreaming about models the same night she realizes she has no centralized place to track them.

The As-Is wasn’t just a research artifact. It was an alignment tool. Across a global team of 30 people, it gave everyone — designers, engineers, product managers, SMEs — a shared understanding of exactly what we were designing against. When you can see Ann’s face at step 13, making revisions for the third time, the urgency of the design problem stops being abstract.

The Future Script flipped it. Same characters, same bank, same regulatory deadline — but a completely different experience. Mani starts with last year’s plan already loaded. Ann gets 250+ data sources recommended automatically. The system catches gaps before the test runs. By lunch, Mani has approved the scenario. What took 33 days now takes one.

The Future Script became the inventory for everything that followed. Every screen, every interaction model, every design decision in Streams 1 and 2 traced back to a moment in this narrative. It kept the team oriented when the complexity of the domain threatened to pull focus away from the people we were designing for.

7. Wireframes

With the As-Is and Future Scripts as our north star, wireframing began in earnest. The goal wasn’t to design every screen — it was to design the right screens well enough that the team could build from them confidently.

The entry point was the stress test dashboard — where Ann and Mani could see all active tests, filter by type and reference period, and jump back into work in progress. Straightforward to describe, less simple to get right when the list spans regulatory, ad-hoc, and sensitivity analysis types, each with different statuses and urgency levels.

The harder design problem was variable selection. A typical test uses 25–50 variables — GDP, inflation, interest rates, unemployment — drawn from a pool that can reach hundreds. The challenge wasn’t just display. It was decision support: how do you help Ann find the right variables quickly, without making her feel like she’s searching a database?

The answer was a recommended-first list view — variables surfaced based on her scenario type, verified and approved status visible at a glance, with grouping and filtering built in. The three screens below show the progression: an empty state before selection, mid-selection with variables grouped by category on the right panel, and the near-complete state with search filtered down to 12 targeted results.

These screens went through multiple rounds of review with Yugesh and the broader team before going in front of customers. In a regulated domain, a screen that confuses an analyst doesn’t just slow them down. It creates risk.

8. Usability

Just as developers don’t QA their own code, designers don’t test their own work — once you’ve built something, you’re too close to it to see it clearly. So when it was time to test, I handed the prototypes to Marcus’s research team. A researcher based in Singapore ran 15 moderated sessions with approximately 20 users across our customer base. I wasn’t in the room. That was intentional.

Getting those participants in the door was itself a design problem. Stress testing customers aren’t a pool of willing research volunteers — they’re risk analysts and managers at banks, with regulatory deadlines and competing priorities. The research teaser we built explained what UX research was, why their input would shape the product before it shipped, and what participation actually involved.

“A section is better than multiple screens.” Users felt that some flows had too many screens for what they were trying to accomplish. Fewer screens with sharper focus on the task at hand reduced cognitive load and felt more aligned with how analysts actually work. This directly shaped how we restructured the configuration flow.

Users expect to override or move past an error without being blocked. The system’s validation intelligence — filtering model lists based on scope, flagging data gaps — was welcomed. Being forced to resolve every alert before continuing was not. The recommendation: map the full range of unhappy paths so error handling could be designed with the same intentionality as the happy path.

Selected items need to stay visible before moving to the next step. When users were selecting metrics, variables, or models, they needed to see what they’d already chosen without scrolling back through a long list. The fix was structural: move selected items to the top, or create a dedicated selected panel on screen.

Each finding had a clear recommendation attached. None required starting over — they required sharper judgment about where the complexity was landing on the user versus where the system could absorb it. That’s the work that followed.

9. The Handoff

The hi-fi designs that went to the development team represented the full scope of Stream 1: two complete guided processes, a project dashboard connecting them, and a set of interaction patterns that could scale to the streams that followed.

Ann’s journey begins at the project list — a clean entry point where she can pick up an existing stress test or start a new one. From there, the first guided process walks her through seven steps of analysis configuration: project details, portfolio scope, metrics, models, variables, process flow, and a final review and validate screen. The progress tracker on the right panel keeps her oriented throughout — she always knows where she is, what’s completed, and what’s ahead.

The model selection screen is where the system’s intelligence becomes most visible. With 302 results in the pool, the recommended-first list surfaces the right models based on Ann’s scope and metrics — and when a selection creates a conflict, the system flags it immediately with a specific, actionable alert rather than letting the error carry silently into the test run.

Variable selection takes a different approach to managing scale. Rather than presenting a filtered list, the search field offers intelligent autocomplete — surfacing variables, models, and scenarios simultaneously as Ann types. The system meets her where she is, whether she’s searching by name, category, or related concept.

After completing all seven steps, Ann reaches the review and validate screen — a summary of every selection she’s made, organized by scope, metrics, models, variables, and process flow. From here she can complete the configuration setup or continue directly into scenario setup.

Completing the first guided process lands Ann on the project dashboard — her command center. She can see the project’s overall progress, any alerts that need attention, and recommended next steps on the right panel. This is also where the two guided processes connect: Analysis Configuration is complete; Scenario Setup is next.

The second guided process — Scenario Setup — has six steps of its own. Ann selects scenarios from a centralized repository of 159 results, filtered automatically by the time horizon she set in step one. The system already knows what’s relevant; Ann’s job is to review and confirm.

Near the end of the second process, the Generate Narrative screen does something no spreadsheet-based workflow could: it drafts a written narrative of the scenario based on everything Ann has configured — the variables, the shock types, the time horizon, the regulatory framework. Ann can review it, edit it, and submit it as part of the scenario record. It’s one of the moments in the product where the complexity of the setup earns its payoff in a tangible, human-readable output.

The final screen of the second guided process closes the loop: a review and validate summary of the full scenario setup, with a “Great work! You are almost done” message and a clear path to continue into Data Sets & Business Rules — the next phase of the product, carried forward by the designers who came after.

10. Reflection

OFSSTSA shipped in May 2024. Yugesh’s release note to the team called it the result of “hard work, dedication, and unwavering commitment.” Jason, the VP who had watched the product evolve from the beginning, put it more plainly: the team had tackled “some very complex business and technical problems, which one can argue have not been solved by any product company.” He asked everyone to savor the moment — and then buckle up, because the ride was just getting started.

I wasn’t on the team when it shipped. I had been resourced off more than a year earlier to support a high-priority engagement in the Communications industry — the standard operating model for our consulting org. But I read those emails when they came through, and I felt the weight of them. The foundation I had built was in that product. The phase planning, the discovery, the scripts, the wireframes, the hi-fi handoff. All of it had held long enough for other designers, other engineers, other product managers to carry it across the finish line.

That’s the honest story of this project. And it’s also the part I’m most proud of.

No one on the UX team had done what I did on Stress Testing — walked into a completely undefined, six-stream enterprise product in a domain I’d never touched, and turned it into something buildable before a single wireframe was drawn. That wasn’t in the brief. It was a judgment call I made with Marcus early in the project, when it became clear that the ambiguity itself was the design problem. The phase planning, the scope mapping, the UX product roadmap — these were the artifacts that made everything else possible.

This project was also where I learned something I’ve carried into every engagement since: rapid domain onboarding in regulated industries isn’t just a skill, it’s a form of respect. These domains are complex. The people working in them are carrying real stakes — regulatory deadlines, capital decisions, institutional risk. Getting to fluency fast enough to ask useful questions is how you earn the right to design for them.

The promotion to Principal happened while I was still working in this space. I don’t think that was a coincidence. What Stress Testing gave me — beyond the domain knowledge, beyond the artifacts — was a clearer sense of what it means to lead at the level where the problem itself is the design challenge. Not just solving it. Defining it.

The Financial Crimes team requested me specifically for Transaction Filtering about a year later. That’s the kind of signal that doesn’t come from a title. It comes from work that held.