Moody's Ratings
I joined Moody's Ratings in September 2024 and work on a variety of projects, ranging from deep product work in the structured finance domain - solving interface problems and bridging the gap between business and user goals - to redefining what responsibilities a designer should own in a product. As the organization transitions to an agent-first workflow, my role has morphed to also include equipping agents to do product design and help introduce agentic design processes to various product and development teams.
This is a high-level overview of the work I have done and continue to execute at Moody's. Detailed case studies to come soon.
What does Moody's do?
Moody's is one of the world's leading credit rating agencies, assessing the creditworthiness of companies, governments, and financial instruments that investors and institutions rely on to make decisions. I work within Structured Finance, where Moody's rates securities backed by pooled assets sitting at the intersection of complex financial instruments and the analysts who need to act on them quickly and confidently.
My Role
As a Senior UX Designer on the Structured Finance team, I own the end-to-end design of tools used by analysts to rate and monitor structured securities. This involves translating dense financial workflows, often shaped by regulatory and legacy constraints, into interfaces that reduce time-to-decision and cut down on analyst error under pressure.
As Moody's transitions to an agent-first workflow, I've also taken on the onus of equipping agents to do product design themselves, helping introduce agentic design processes across product and development teams.
Fitting two years of work into a cohesive narrative is quite hard. Here are three themes that best capture where the work was concentrated and what impact it had.
Building Swan from 0 → 1
Swan is Moody's structured finance platform. For much of the past two years, I've been one of its foundational designers, defining the interaction patterns, analytical process flows, and information representation that later features would inherit. With no existing product to reference, early decisions here often became the default answer for everything that came after.
Majority of the work involved translating workflows that existed on spreadsheets into patterns that could leverage web-based interactions unavailable on spreadsheets. This involved redefining the intent of the analysts, and how they could execute their goal in more intuitive ways.
The first project I worked on was to redesign the process of creating a Waterfall, the last and most complex step in defining the Cashflow. Waterfalls determine the order in which tranches would be repaid. Analysts were used to keying in the priority order and payment sources for all necessary targets. Finding targets in a massive exhaustive list and mentioning a priority number was cognitively taxing, often leading to mistakes. I asked the question what if the steps could be defined in the order in which they were going to be executed, which changed the interaction paradigm and made defining complex, multi-step waterfalls with numerous conditional triggers simple. This adhered to my principle of never letting tools hinder thought process. We also leveraged web based interaction patterns such as drag-and-drop to make the task intuitive and fun.
Dashboards were a new addition, made possible once the shift to web let summaries from multiple tools live in one place for the first time. I defined what information was visible at each of the three zoom levels analysts could view the application from. The sensitivity dashboard, in particular, became the primary source of analysis-level status, improving visibility across all individual tools.
Reference Rate was already designed and built by the dev team before I joined the SFG team, but analysts could still select combinations that produced incalculable outputs. I redesigned the tool around error prevention rather than error recovery, using progressive disclosure to eliminate invalid selections. This improved analysts' confidence in the assumptions they were inputting, and reduced reliance on custom components, making the codebase easier to maintain. I also took on the front-end implementation myself, cutting dev effort by 70% and speeding up delivery.
Autorun was a capability introduced in Swan to dramatically speed up how quickly stressed analyses could be executed. I worked closely with the dev team to define when analysts could trigger these runs, and what visibility they'd have into system status while a run was in progress. That collaboration led to a parallel run architecture: a single workstream's execution time dropped from 25 minutes to 3 minutes, an 88% reduction, and because runs executed in parallel, analysing multiple workstreams took no longer than analysing one.
Translating single deal interactions into Portfolios
Portfolio in Swan is where individual analyses come together. Analysts here manage many securities at once instead of one at a time. Most of Swan's early patterns were built for single-item workflows, so when we started work on portfolios, a lot of the conversations hinged around how information would be consumed and defining what a group or bulk action should even mean inside the product, and where the line sat between what was technically achievable and what would feel natural to an analyst doing the work.
Work on Portfolios started with multiple discovery sessions with analysts across the globe to understand their processes, and specific regulatory and analytical nuances that were necessary in their workflow. Having a deeper understanding of the analytical process helped me to dive further into specifics in these conversations. With this, I defined a process flow for how multiple deals could be tracked at once, and presented the proposal to Business and developer teams. This discovery work helped clarify ambiguity and improve confidence in estimating scope of work by up to 60%.
I defined how default values and behaviour should differ between single-item and bulk contexts. Engineering initially pushed back on allowing any individual-level actions at the portfolio level, arguing those should stay confined to the single-deal view. After several rounds of conversation and negotiation, we reached a compromise: key values became editable directly at the portfolio level, without forcing analysts to drop into each deal individually.
As Portfolios matured, analysts had access to close to 20 operations on a single page. Working in an ambiguous, still-being-defined space, I added new actions to the toolbar as functionality was needed rather than pausing to design a system upfront, and the actions space became bloated as a result. I categorised and redesigned it, introducing defaults and patterns that reduced the space the toolbar took up by over 60%, letting three additional deals appear on page load.
Bulk Edit let analysts update the same parameter across multiple deals in a single action, instead of performing each action individually. The core design challenge was that the right component, interaction, and feedback pattern changed depending on which variable was being edited - a numeric field, a date, a categorical selector, and a toggle each needed a different way of confirming what was about to change and what the analyst should expect once it applied across the selection, along with the complexities that arise from solving for CRUD and partial success.
