This project is part of my summer internship experience working at Financial Industry Regulatory Authority, Inc (FINRA) at the Maryland branch as a UX Designer. BRACE is a financial data review system that allows auditors to review and approve billing data before sending them out to firms monthly.
In five weeks, I worked with product managers, software engineers and design mentors to accelerate the financial data reviewing process and created a smooth user experience for users.
* To comply with the non-disclosure agreement (NDA), I use dummy data to present my design.
Design for Heavy Data
Before BRACE was brought up, FINRA used PeopleSoft for billing review. The system was developed a long time ago and there were several problems with it:
Labor-heavy: The system requires manual deletion and addition to change status of transaction records. It is time-consuming and labor-heavy when the number of transactions gets big.
Unable to accommodate growing needs: The company is going to integrate more clients into the system, yet the system lacks the ability to adapt to different uses cases of various clients.
Unfriendly Interface: The user interface of the system is outdated and is unfriendly for speed reading.
This is when BRACE came in to accelerate the billing data review process. In the meantime, by optimizing and standardizing the data review workflow, the system is expected to accommodate needs from the scaling clients.
Overall, BRACE supports three primary tasks: data entry, data correction, and data review. Following are highlights on how BRACE help with each task.
1. Data input from CSV file
The system supports data import from CSV files to automate the data entry process.
2. Convert suspended transactions
Streamline the process of transaction status conversion through an editing feature.
3. Prioritize information
Put information with less priority to secondary rows or using tooltips for details to save space in the data table.
The primary stakeholders of the product were system users (auditors) and the product owner. Through two interviews with them, I gathered requirements from both sides: For users, they needed to review and approve billing data using the system. Additionally, they expected the transition from the old system to the new to be smooth. Meanwhile, the product owner wanted a unified workflow that can meet various needs from 20+ revenue streams (aka. business lines) that would be integrated into the system in the future. He also wanted to make use of the historical datasets and see if we can extract useful insights out from them.
I conducted two interviews with three experienced auditors to learn how they work. I then made a flowchart to visualize the process and later identified one part that can be greatly improved - the process of transforming a suspended transaction into an online transaction record.
Previously, users need to find out the reason of a transaction suspension, “fix” it, take notes of the suspended data and manually enter them as a piece of new transaction record and eventually delete it from the suspended transaction table. An optimized workflow will be allowing direct editing on suspended transaction data and then change status from “suspended“ to “reviewed“.
To summarize from user research and interviews, the new system is expected to incorporate following features.
Translate Pain Points to Design Insights
After discussion with teams and prioritization, we defined the primary goal to be accelerating data review process. To this point, there are three design questions we want to think about carefully:
Edit to Convert Status
After taking a closer look at the suspended data (status: suspended) and compare it with typical online data (status: reviewed), I found that a suspended transaction only requires small editions before becoming a “reviewed“ transaction. Therefore I introduced the idea of editing data to achieve the status conversion instead of addition plus deletion.
I experimented two ways of presenting the status change. One way is to use two tables that list transaction records in two statuses, a transaction will be moved to a new table if its status change. In this way, it’s easy to observe the status change yet the readability compromises - having two tables in one row reduces the table space for the heavy data presentation. Another way would be putting all the transaction records in one table, and use indicators to notify status changes. This design better supports speed scanning for data review.
I also explored different ways of editing suspended transaction data. As I mentioned before, the suspended transaction has many common fields with an online transaction: in fact, in most cases auditors only need to enter two fields of information to complete a status conversion.
I came up with inline data editing first, since it is fast and easy. However, later from interviews I learned that users need to get the complete information (includes collapsed data) to act on the suspension, I then came up with two versions of editing dialogs.
Minimize Manual Data Entries
To facilitate the data entry process, a major help would be supporting data import from uploaded CSV files. In the meantime, there are cases where users still need to enter data manually, and auditors used to adding multiple of them at once. To help with it, the system supports multiple entries - the dialog will remain open when “add multiple“ is selected so that users don’t have to open it every time for adding a new transaction.
Save Space in Data Table
To provide a clean and elegant look of the table and speed up the data review process, I explored different ways for data display. Features such as filter, sort and pagination are incorporated to support customized needs. Additionally, secondary hierarchies and tooltips are used to save space and present details.
Following are selected screens showing how I went from the early wire framing stage to the final design.
Home Page Iteration
Data Table Iteration
Pixel Perfect Mockups
Finally, I refined icon styles, unified margins and paddings following FINRA’s design guideline.
An interaction map was made to communicate the relationship between screens. Micro interactions, system notifications and error messages are annotated below screens.
I also developed an interactive prototype on InVision which covers major features of the system. The inspect feature of InVision is introduced to engineers as a reference for a spec of design.
Context is Key
Often a solution to a problem seems simple, yet the challenging, also the vital part is to understand the problem itself. There could be guidelines telling you that pattern A is good for B scenario, but it may not work in practice under condition C or with constraint D. It is important to think critically and prevent biases before getting into a conclusion. Engaging users as early and as often as possible through the design process would greatly help to come up with a thoughtful and useful design.
Experiment on Solutions
Design can never be perfect but can be better. For enterprise applications, there are not many online examples to learn and study, however, we can experiment on different solutions and work out a version that works best for us. Studying use cases of different UI patterns, designing alternatives and testing with users contribute to better design decisions.
Cross Team Communications
Communicating across the team can be challenging given different backgrounds that people have but lack of communication will definitely cause problems. The best way to save effort on communication is to engage the team as early as possible and make sure that everyone is on the same page throughout the entire process. You learn from engineers about technical boundaries and make sure your design is feasible. You get feedback from product managers whether your design aligns with the company’s business plan and ensure the project get enough budget.