Moody's Ratings

Since September 2024, my role at Moody's has had two halves: designing structured finance tools from the ground up, and building the AI ecosystem that lets agents do design work across the organisation.

The product work is under NDA, so this page is about how I worked and what I learnt rather than what I shipped. I'm happy to walk through the work itself in person.

Role
Sr. UX Designer
Team
Structured Finance Group, XD
Timeline
Sep 2024 - present

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. I work within Structured Finance, where Moody's rates securities backed by pooled assets.

Who I design for

Analysts who rate and monitor those securities. Their work is dense, high-stakes and shaped by regulation, and before the tools I worked on, much of it lived in spreadsheets.

Designing the product

On the Structured Finance Group (SFG), the work moved through four modes, often at the same time.

Starting from nothing

0 → 1

I was one of the foundational designers on a new structured finance platform, with no existing product to reference. Most of the work meant turning workflows that lived in spreadsheets into interactions only the web could offer, which first meant understanding what analysts were actually trying to do. One example: replacing a list where analysts typed in priority numbers with a flow where they build each step in the order it runs. Early decisions like that became the default answer for every feature that followed.

From one to many

1 → n

Once single-item workflows worked, the next problem was scale: letting analysts work across many items at once. That meant defining what a bulk action should even mean, how defaults differ between one item and many, and where the line sat between what engineering could build and what would feel natural to an analyst. It took several rounds of negotiation, and a toolbar that grew to 20 actions before I categorised it and cut its footprint by over 60%.

Shared primitives

Design system

Patterns that worked in SFG fed back into the shared design system: dense data tables, feedback for bulk edits, and progressive disclosure that prevents invalid inputs instead of flagging them afterwards. Contributing meant generalising a solution beyond the problem it was born in, and documenting it clearly enough that other designers and developers could use it without me.

From design to shipped

LLM-assisted front-end

I took ownership of front-end implementation for parts of the product, using LLM-assisted coding to turn designs into production UI that developers reviewed and merged. On one redesign this cut dev effort by 70%, and across the work it sped up UI implementation by about 3x. Owning the code also closed the gap between what was designed and what shipped.

Designing for the agents

As Moody's moved to an agent-first way of working, agents started producing UI without the context a designer carries: the design system, the domain and the judgement calls. My role grew to include building that context for them.

Design skills

Design process and judgement written down as skills agents can follow, from using the design system correctly to reviewing a screen.

Tools and MCPs

Connections that give agents direct access to sources of truth, like design system tokens and components, so their output starts on-system instead of being corrected later.

Adoption

Bringing these workflows to product and development teams, so agentic design became part of how they work rather than a side experiment.

  1. Early decisions compound.

    In a 0 → 1 product, every decision becomes a default. I learnt to make them as if they were permanent, because most of them were.

  2. Prevent errors, don't just catch them.

    Designing out invalid states builds more confidence than any error message can.

  3. Systemise when patterns appear.

    Adding actions as they were needed kept us moving, until the toolbar sprawled. Now I watch for the moment a pattern repeats and give it a system then.

  4. Domain depth makes better questions.

    The more I understood the analysis, the sharper discovery got, and the more confidently the team could scope the work.

  5. Owning the code changes the design.

    When I build what I design, the handoff gap disappears, and I weigh ideas by what they cost to make real.

  6. Agents are users too.

    They need the right context at the right moment, just like people. Writing skills for them forced me to put my own design judgement into words.