Background
At Amount, we build customer-facing financial products, like personal loan, credit card, and point-of-sale applications. On the flip side, we have built out a suite of business-facing software that is used by our bank partners to manage all things related to their programs with Amount.
I’ve had the opportunity to design several of these B2B applications (we call them “Modules”) from the ground up, as well as improve and re-design existing Modules.
The Metro Reports Module was one of our legacy apps, built by developers with no design input. Over the years it had been outgrown by its users and I was tasked with envisioning a total redesign.
Role: Product Design Lead
Deliverables: Recommended feature requirements, high-fidelity prototype
Time Frame: Three 2-week sprints
What is a Metro Report?
Each month, financial institutions are legally required to send a data file to all the major credit bureaus. The file contains reports on all active lines of credit for their customers with data including payment status, outstanding debt, etc.
This is how the bureaus are able to measure consumer credit scores and, as such, it is extremely important that our bank partners are able to send accurate and timely Metro reports.
This is the landing page of the legacy Metro Reports application.
Business Goals
The existing process required a high level of manual labor and backend dev work. Bank partners were reliant on Amount’s development team to launch changes. We needed to build a self-service tool for partners to edit, compile, and send metro reports on their own.
The existing tool lived on our legacy app and needed to be moved over to our updated platform, which houses all of our other business-facing Modules that are used by bank partners. This meant that the front-end UI would be entirely rebuilt.
Research
Going into this project, I didn’t even know what a Metro Report was and there was very little documentation around the existing Metro tools and processes. So, to start, I conducted weekly user interview sessions with the Amount SMEs and members of the Metro team at one of our bank partners. During these sessions, users would walk us through their current processes, explain which tools they were using, and answered our many, many questions.
My primary goal at this point was to understand the existing user flow and attempt to identify the things that were working well, and the things that were not. After the initial interviews, I put together a user journey to validate my understanding of the current process.
Pain Points
Users relied on manual tracking via complex google sheets and checklists.
In order to make any updates to the file, the bank partner employee had to submit a help desk ticket to our development teams so they could go in and add, remove, or edit customer accounts within the file. This was cumbersome on both the partner side and our dev resources.
Another huge issue was a gap in the navigation. Users had no way to access the individual loan accounts in a Metro file within the tool.
Ideation
Once I had a solid understanding of the existing process and had identified some opportunities for improvement, I mapped out what the ideal user journey could look like.
The main goal here was to automate processes when possible, and allow the user to complete all required tasks from within the application. Additionally, during this phase I worked with the product owner to define the MVP requirements for the new build.
I was able to share this journey map with the bank partner users, the product owner, and developers to assess whether this direction made sense from their perspectives.
The metro process is very backend driven so it was important for me to understand whether my proposal was technically feasible.
UX Architecture
I identified the major touch points and workflows that would be necessary and worked in 2 weeks sprints to flesh out the details. Considerations included which data needed to be displayed at each point in the journey and the hierarchy of the data.
High level pages include a landing page with a list of all Metro Files, an account index page, and individual an account details page.
Account Index Page
One of the most crucial improvements is the account index page, which includes a table view of all the individual customer accounts that live within the report. This page was designed to bridge the navigational gap between the Reports list and the individual customer account pages, eliminating the need to leave the tool to locate accounts.
This page also included a summary of the accounts based on their payment status, filters to narrow down results by status and whether the account was manually updated, as well as the ability to search for an account by customer name, ID, or loan ID.
Customer Account Page
The third main page displays data for an individual customer account. This table includes a customer’s personal information, as well as current and historical loan and credit information.
The main purpose of this page is to allow users to spot check the report’s accuracy via manual QA, and to manually update individual data points when necessary. Because this page is very data heavy I conducted an information architecture exercise to determine some order for the data.
I like to have open, cross-team communication throughout the design process. This helps me avoid going too far down one path only to learn that it doesn’t serve user and business needs, or it is technically not feasible.
During one of my design usability sessions, I learned that the metro reporting team actually preferred the account data points to be displayed in the order they appear within the data file. While this order seemed nonsensical to me, it enabled users to cross check data quickly.
Below is the final version of the Customer Account Page.
The Metro Reports Module MVP is currently in development.
Post-MVP
There were some improvements that were de-scoped from the MVP, but will hopefully be fast-followers.
One of these features is the ability to conduct batch updates for the report. Users can add, remove, or update 1,000s of accounts at once by uploading a CSV file containing the account numbers generated in Looker (data reporting tool). This will eliminate the need for our developers to manually update the accounts.
Additionally, I proposed an assignment feature that would allow users to manage their workflow without the insanely large and complex google sheet that they are currently using to track necessary updates.
