moody’s

The RDL AI Agent is a conversational assistant inside Risk Data Lake that lets non-SQL users, including underwriters, portfolio managers, and analysts, ask questions about risk data in plain English and get back an answer with the data, the chart, and proof of where it came from.

Problem: anyone who couldn’t write SQL depended on an analyst for even a quick number, so everyday questions waited in a queue behind full ad hoc analysis work.

My answer was to shift from making the pixels to auditing them: using the prototype as a starting point, not a finished design, and checking it against its own requirements and against usability best practices.

What the audit found

• No one-click hand-off from a generated SQL query into the actual SQL editor, only a copy button, so “show your work” was only half-built.
• Source citations and result counts stayed visible, sometimes duplicated, even on failed responses, undermining the one rule that mattered most: don’t show what you can’t back up.
• No way to cancel a request while the agent was “thinking,” leaving people stuck waiting out a frozen-feeling state.
• Entry points and example prompts were written in raw SQL/schema language, defaulting the whole experience toward the one persona who didn’t actually need it.
• The agent’s own entry point was an unlabeled icon, undiscoverable despite being the platform’s headline new capability.

Extending the system, not working around it

Roughly a quarter of what the chat interface needed, things like message bubbles and sender/receiver treatment, didn’t exist in the core design system yet. Rather than hardcoding one-off components for this feature, I used atomic design principles: building new patterns as atoms of the existing library, so the system grows instead of collecting exceptions to it.

Outcomes

• Turned the audit findings into finalized screens, built through the design team’s prototyping practice, that close each gap: a one-click SQL editor hand-off, a cancel control, corrected citation behavior on failed responses, and persona-appropriate entry points and prompts.
• The finalized experience is on track for its opt-in preview launch, built from validated interaction patterns and closed audit findings rather than new concept exploration.

Why it mattered

AI tools are changing who can produce a first draft of an interface, but that draft still needs someone accountable for whether it’s usable, trustworthy, and consistent with the system it has to live inside. Auditing the prototype instead of dismissing it kept the team moving at AI speed without inheriting a shortcut’s worth of design-system debt.

The existing design system wasn’t structured around tokens, which limited scalability and made theming difficult to implement and maintain. This work ran in parallel with feature delivery, prioritizing critical components first to avoid blocking product roadmap commitments.

Objective: enable scalable theming (Dark Mode and High-Contrast) by restructuring the existing design system into a token-based architecture, ensuring accessibility, consistency, and engineering feasibility across data-dense products.

Key contributions

• Led the restructuring of the design system into a token-based model, defining semantic tokens (intent-based, theme-agnostic) and component tokens (contextual, reusable, and scalable).
• Mapped legacy styles and components to the new token structure, identifying gaps and inconsistencies.
• Defined token usage guidelines to support multiple themes without breaking hierarchy or meaning.
• Worked hands-on with engineering, aligning design decisions with implementation constraints and validating feasibility early.

Outcomes

• Established a scalable foundation for theming across the platform.
• Unblocked Dark Mode and High-Contrast implementation without design debt.
• Improved accessibility, contrast consistency, and long-session usability.
• Strengthened design and engineering collaboration through shared system ownership.

While analysts and modelers work directly with risk data, Data Admin sits in between all IRP products, ensuring the platform functions safely, reliably, and at scale. This layer governs who can access what, how data flows between environments, and how systems are maintained over time.

Scope of work: platform operations, governance, and cross-product enablement.

Key contributions

• Designed and refined experiences for user and role management, including permissions and access control across all products.
• Contributed to flows for secure connectivity and VPN setup, reducing friction in complex infrastructure onboarding.
• Worked on database management and archiving workflows, supporting data lifecycle, compliance, and long-term maintainability.
• Helped define clear UX patterns for administrative actions such as configuration, validation, and system feedback.

The VPN work shipped publicly as Moody’s VPN for Data Bridge, see the official announcement for the shipped result.

In complex analytical systems, errors are inevitable. What matters is not whether something fails, but whether users can understand why it failed and what to do next. The system communicated failures in a highly technical manner, leaving users without a clear path to resolution.

Users had limited visibility into why model runs failed or partially completed. Skipped locations and technical errors were difficult to trace back to specific input data issues, which increased troubleshooting time, led to repeated trial-and-error reruns, and created unnecessary dependency on support teams.

Personas

• Risk Analysts: need to quickly understand why a model run produced incomplete or unexpected results.
• Catastrophe Modelers: require precise feedback to correct input data and rerun models efficiently.
• Data Engineers: depend on structured logs to trace issues and validate data.

Approach

• Led UX requirements gathering in close collaboration with Product, Engineering, and Subject Matter Experts.
• Framed the problem using Jobs to Be Done, aligning system constraints with real user goals.
• Established a clear conceptual distinction between warnings (informational, non-blocking) and errors (action required).
• Designed the experience as a layered communication model: immediate, human-readable messages paired with deeper, structured analysis logs.

Outcome

• Designed a structured analysis log, readable by humans and consumable by machines (CSV / JSON), including location identifiers, exclusion reasons, and severity classification.
• Introduced interaction patterns that support sense-making: expanding and collapsing detailed entries, filtering by severity or error type, and copying and exporting logs for collaboration or auditing.
• Error handling shifted from a reactive, support-driven process to self-service problem solving.