Making Complex Data Simple
Designing for Automated Data Intake
Table of Contents
Problem statement
Data analysis
User Research
Prototypes and Testing
UI Design
Lessons Learned
Problem
Data entry at Moody’s is a cumbersome process conducted by offshore contractors in legacy enterprise applications. There are complex workflows, clunky technologies, and loads of complicated documentation that make it difficult for staff members to do their jobs.
Goals
The business believed that automating data entry would eliminate many of the problems they faced. Their goals were to:
Decrease the amount of time spent entering and reviewing data from an external financial statement.
Reduce manual errors in the data entry process.
Team
Technology and business leadership teams spun up a squad of five Engineers, a Business Analyst, a Product Owner and a UX Designer (me!) to design and build an internal product to simplify the process. Our job was to:
Automate the ingestion of data from the SEC into our internal system
Map some the data to Moody’s internal systems for data entry, and
Build a product for users to both (i) create new mappings and, (ii) view/edit automated mappings.
2. Data
Meeting users where they are means understanding their language - and Moody’s users speak financial data.
Introduction to XBRL
Before I began working with users, I dove into the data. I had to make sure that I had a clear understanding of how the data was structured and the various types of data that users encounter at their jobs. The two types of data we focused on for this version of the product were: (1) an internal Chart of Accounts, and, (2) XBRL.
I was already familiar with the internal Chart of Accounts, so I focused my efforts on understanding XBRL for this stage of the project. XBRL, or eXtensible Business Reporting Language, is an XML-based tagging system that structures lengthy financial documents so it’s easier for institutions to ingest those documents into their internal systems.
Anyone can view XBRL in tagged statements through a document viewer at SEC.gov
I began with online research at the SEC, learning about XBRL and viewing XBRL in financial statements. I was also able to access raw XBRL data in CSV format - so I spent a lot of time in Excel, parsing through up to three-thousand line spreadsheets.
XBRL is XML-based tagging systems that makes it easy to parse data in lengthy financial documents
Knowledge Transfer with SMEs
It was essential that I did independent research on the data. I knew that I needed to understand the underlying mechanics driving the process. But what helped me most when I began the design research process was knowledge transfer sessions with the Product Owner and Business Analyst - both of whom have extensive backgrounds in financial data.
Having access to colleagues with this degree of knowledge was invaluable; it highlights how critical it is that designers build and maintain strong relationships with SME teammates and stakeholders. I continued to work with our PO and BA throughout the project - having regular sessions to clarify requirements, test out new design ideas, and just talk through some of the challenges with the data.
3. User Research
I had direct access to users for the discovery phase, so I conducted ten observation sessions.
My goal was to gain an understanding of the current process so I could identify both pain points and strengths that should be taken into account when designing a new system.
Observations
While I was learning about XBRL, the tech team was extracting XBRL from the SEC into our internal systems and making that data available to users. That meant I could watch users map raw XBRL to the internal Chart of Accounts in Excel.
But I didn’t want to only observe users mapping XBRL to the Chart of Accounts - I also wanted to see their current process, where they copy/paste data from PDFs into Moody’s legacy data entry application.
For observation sessions (conducted on Zoom), I asked opened-ended questions so I didn’t lead the users down any type of predetermined path. These questions included:
Can you show me what happened the last time you completed mapping a statement in the legacy system? Just show me the end-to-end process - starting at the very beginning.
Can you show me the last time you mapped parsed XBRL in Excel to Moody’s Chart of Accounts?
What steps do you usually take when you’re doing a mapping in the legacy system?
Before we built the product, users created XBRL mappings using parsed data
Insights
The main insights I gained from these observations were:
Even though all users were working from home, everyone used a large monitor to do their work. This meant that I could optimize my design for larger screens, even during Covid.
The mapping process was complex and users performed several different types of mappings, sometimes using multiple data points for a single line item. I knew that building the interactions for these tasks was going to be my first - and most challenging - design task. This is what I highlight below in Section Four.
There were four key attributes (out of over fifteen) that are critical for filtering these large datasets. This helped me to better design search and filter functionality in the application.
These insights helped me to prioritize key elements for the UI, shaping the first iterations of the design.
4. Prototypes and Testing
After we understood the high-level ways in which users were working with data, I began to design the interactions (and micro-interactions) in the data mapping process.
Interactive Wireframes
As I refined the design, I worked closely with users and stakeholders in rapid prototyping sessions so I could iterate quickly. For the first step in the process, I created interactive wireframes in Axure and conducted individual review sessions with users. In these sessions, I wanted to understand the user flow through interactions and micro-interactions in the mapping process.
In these early prototypes, I worked with users to understand all of the different interactions they needed to take in the mapping process
Interaction Design
Once I had a better understanding of process, I spent several weeks designing and testing the mapping interactions. The key challenge was letting users know that cards were selectable objects on the UI, and that they need to select those cards to begin the mapping process.
Drag and Drop
I initially wanted to explore drag and drop as a design option, but the engineering team was hesitant because of the amount of development work involved - especially for cross-browser compatibility. There are also several other data-related reasons that drag and drop may not be the best solution for this particular part of the product. So the team and I decided that it was best to explore other design options.
Icons
For the first iteration, I used what our internal UX style guide recommended for actions on the UI - icons. I wasn’t sure which icon to use to represent mapping, so I took this question to design review. There weren’t many options in our icon library - so the team recommended that I try using the “refresh” icon. This design did not test well with users at all.
Buttons
I wanted to try something more obviously clickable in the next iteration, so I replaced the icon with primary buttons.
This design performed a bit better - but users still seemed confused. The buttons also did not work well from a visual perspective, making the UI feel heavy and crowded.
Select Box
In the next iteration, I used a select box for mapping initiation. Users responded well to this design - they understood that the select box initiated the mapping process.
The select box made it easy for users to understand the card element on the UI were clickable - and will be included in the MVP
6. UI Design
As I refined the design, I worked closely with my team’s visual design lead to ensure the UI aligned to standards. I also continued to review and test the design with users.
Process
I used our internal design system to refine the UI’s look and feel. But because I needed so many new components for this UI - which was quite different from the workflow applications my team usually builds - I had to work closely with our visual design manager to align these components and interactions to our brand and product guidelines.
Usability Testing
The UI design is a work-in-progress and I am continuing to build out designs for the product’s features. I have, though, done usability testing on mapping interactions which have yielded a core insight:
The concept of mapping - connecting one set of data to another - worked well, for the most part. We are continuing to experiment with flipping the data (from Chart of Accounts on left and XBRL on right to XBRL on left and Chart of Accounts on right). My recommendation is to build both versions and A/B test the designs when we launch the MVP.
7. Lessons Learned
Even though the design and development of this project is still in flight, I’ve learned valuable lessons through the design process.
Business Context
It is important to understand micro- and macro-level business contexts for design projects. For a project like this, it was critically important that I take the time to understand the data. This helped me to design a solution that took into account the intricacies of the data. It also allowed me to speak with authority to the business and to communicate with users.
Communication is Key
Effective communication is an important part of my job, and for this project it was absolutely essential to the design process. I worked with stakeholders in the business, technology and design teams - and often found myself having to explain the data, tech or design process to other people on the project. Learning to articulate my design decisions well was absolutely essential to a project like this one.