esg-cover.png

Reinvention Not Required

Using Data Insights to Drive a More Efficient Design Process

 

Table of Contents

  1. Problem

  2. User Research

  3. Prototypes and Testing

  4. Lessons Learned

 
 

  1. Problem

The business created an Excel-based tactical solution to distribute new ESG data sets to analysts. But the application was clunky and had many usability issues - so very few people at Moody’s were accessing the data.

 
 

Background

Like many financial institutions, Moody’s was in the process of integrating Environmental, Social, and Governance (ESG) factors into its analytical frameworks.

Moody’s had begun collecting ESG data in 2018 and created an Excel-based tactical solution to distribute that data to the analytical community. But very few people at Moody’s were using the application - and accessing the data they needed to include ESG in their analyses.

Goals

The business wanted to make it easier for the analyst community to access ESG data. The main goal of this product redesign was to increase usage of ESG application in the analyst community by 50%.

Team

My team was approached by the business and asked to design a more user-friendly solution. I was the UX lead for the project, responsible for the end-to-end design solution - including user research, wireframes, interaction design and UI design. As this was a design project, I was responsible for the majority of the work - but I did have the help of a VP-level Business Analyst and the Product Owner.

 
 

2. User Research

I started with user observations so I could learn more about challenges (and strengths) of the current tactical solution.

My main goal was to find out why users encountered so many difficulties with search - and I also wanted to understand how analysts used the data in their day-to-day work.

 
 

Observations

Even though the application was available, it was not being adopted by the analytical community - our business partners told me that users would try to use the application once and give up because the experience was so frustrating.

Even though I used the application myself - and agreed that it was not an optimal experience - I wanted to learn more about the application’s pain points (and strengths). So I recruited five users and observed them via Zoom as they performed tasks in the Excel application.

During the observation sessions, I asked open-ended questions, including:

  1. Show me what you did the last time you used the application

  2. Show me how you search for organizations

  3. Demonstrate how you add multiple organizations to your report, and,

  4. Show me how you use the data to conduct analysis

In addition to these observations, I also reached out to the customer support team so they could help me to identify common issues for users.

In these conversations I learned that while there were some technical problems with the application, users also reached out to the support team when they faced usability challenges. The support team echoed many of the issues I saw during observations - helping to clarify exactly what the pain points were with the current application.

Insights

I gained several key insights over the course of the observations and conversations:

  1. Search functionality was extremely difficult to use for several reasons - there were performance issues, users didn't understand how to multi-select, and system status was unclear.

The Excel-based search functionality was extremely difficult to use and the main reason why the application did not see a wide adoption rate at [Company]

The Excel-based search functionality was extremely difficult to use and the main reason why the application did not see a wide adoption

2. It was very useful for users to have access to large amounts of data in Excel, but there were a few small usability issues that needed to be resolved in order for them to be able to make full use of the data.

peer-comp-report.png
This layout, which allowed users to see source data, was incredibly useful for users

This layout, which allowed users to see source data, was incredibly useful for users

These insights informed my design decisions as I began to build prototypes in the next phase of the project.

 
 

3. Prototypes and Testing

I built several prototypes and conducted tests with analytical staff members across Moody’s. My goal was to see if my proposed solution would allow them to more easily access ESG data.

 
 

Redesigning Search

Based on user observations, the most pressing priority was redesigning the search experience.

I talked to my engineering liaisons to see if we were able to move search functionality to a web application and they confirmed that we could. The native Excel search experience was responsible for many of the usability issues - so, I knew wanted to explore the option of moving search to the web, but I was unsure if that was the right short-term solution for the reports.

Based on my observations and conversations with the PO, I knew that the design needed to provide four or five possible parameters by which users would search. Users would need either a dropdown or tabs or navigate through those options.

I experimented with a dropdown, but ultimately decided that a tab was a better design decision. With a tab, users could see all of the options up front - nothing was hidden inside of a dropdown field.

Tabs

There were no tabs in our internal design system (yet), so I built three options to test with users.

  1. Tabs with underline (from Material Design)

  2. Tabs with pills

  3. “Traditional” tabs

The underline and pills designs did not perform well with users - even though these patterns are common in more modern (or mobile) designs, they didn’t match Moody’s users mental models for internal applications. The more “traditional” tab design did well with users - and that is the design we used for this product.

 
The underline and pills designs did not perform well with users - so I recommended that we use the “traditional” tab design for this product

The underline and pills designs did not perform well with users - so I recommended that we use the “traditional” tab design for this product

 

Search Results

One of the most troublesome pieces of functionality in the legacy application was the search results page. I wanted to make sure that search on the new application was as seamless an experience as possible.

  1. Making multi-select actions clear. It is common for users to select multiple items in the search process and I wanted to make the process as easy as possible. This simple select action on the list performed well in testing and was used in the final design.

  2. Organizing search results. I tried two designs for the search results: (1) pills, and, (2) a table. The pills were simple and clean, but this design confused users: some even clicked on the pills in an attempt to access a report. Some users also wanted to see key metadata associated with each search result. So for the initial design of this product, we used a table list to organize search results.

 

It was clear to users that they could select multiple items from the dropdown list.

The table design performed better in testing - it was less confusing to users and provided important metadata.

 

Data and Reports

In addition to search, I wanted to see how users would react to a redesign of the report. I built an interactive prototype on the web with limited functionality and conducted testing sessions with users.

In observation sessions, the Excel-based reports had performed well. There were some issues with the legacy application’s functionality, but overall the data was organized in a clear and useable way.

I had users work with the prototype below and I got valuable feedback - I also learned that much more design work would be needed in order to give users the flexibility they need with the data.

 
Much more design work is needed to give users the flexibility they want with the data.

Much more design work is needed to give users the flexibility they want with the data.

 

Design Recommendations

Because there were limited resources and a tight deadline, I came to the business team with three main recommendations that would allow analysts quicker and easier access to ESG data:

  1. Build search on the web

  2. Keep reports in Excel (with a few modifications)

  3. Allow me to continue designing report/data functionality on the web - but only if it is deemed essential for the business

The business was surprised - they were expecting me to come back with a recommendation for a full-fledged web application. But during observations and testing, I came to realize two points that drove my decision:

  • The biggest problem with the current application wasn’t the data - it was search. Users liked the flexibility that they had with Excel and the development team could easily make a few changes that would enhance the usability of the legacy Excel application.

  • Designing an enterprise-level data application for ESG would be a very large design and development lift and I was unsure if the business was ready to make that investment.

The business accepted my recommendation (even though they were initially surprised by it!) and now it was time to design the UI.

UI Design

When the UI design was about to begin, I had something else going on in my life - I was about to give birth to my daughter. So instead of doing the UI design myself, I did knowledge transfer sessions with my maternity leave replacement, and she ultimately completed the UI design for this product. When I returned from leave, my team took my replacement on as a full-time hire. I was given the choice of taking back this product or moving to another one - I ultimately decided to move to another product (data ingestion).

 
 

4. Lessons Learned

My experience with this project led me to key insights that I have incorporated into my UX design philosophy going forward.

 
 

Listen to the Data

The business had come to us and pushed for a complete redesign - moving the entire application to the web. But when I interviewed users, they were happy with many aspects of the Excel-based application, in particular the ways in which they were able to view the data.

I knew that giving users the freedom of Excel on the web would be a costly endeavor for both design and development.

You Don’t Have to Reinvent the Wheel

The business was initially eager to implement a ground-up redesign, but I used research and data to demonstrate that a more iterative approach was preferable in this case - and that we didn’t need to make a huge investment to make a usable product. Sometimes you need to meet folks where they are - and in this case, it was the right decision for the business.