BRACE

Financial data review system

User Interview
Data Table Design
Dashboard

Overview

This project is part of my summer internship experience working at Financial Industry Regulatory Authority, Inc (FINRA) as a UX Designer. In five weeks, I worked with product managers, design mentors and software engineers to design BRACE, a web application that streamlines the financial data reviewing process and brings a smoother user experience to users.

 

* To comply with the non-disclosure agreement (NDA), dummy data are used to present the design.

Duration

5 Weeks

Keywords

Data Heavy
Agile Design/Devlopment

Tools

Balsamiq
Sketch
Invision
Principle

 

Design Process

 

Design Challenges

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:

1. Labor-heavy

Requires manual removal and entry to change the status of transaction records. 

2. Poor Scalability

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.

3. Unfriendly UI

The user interface of the original system is outdated and is unfriendly for speed reading.

PeopleSoft interface. (NOTE: It is not the exact system used by FINRA but it shares the same appearance).

This is when BRACE was proposed to accelerate the billing data review process. In the meantime, by optimizing and streamlining the workflow, the system is expected to accommodate needs from the scaling clients.

Solution Overview

 

Overall, BRACE supports three primary tasks: data entry, data correction, and data review. Following are highlights on how BRACE help with each task.

1. CSV Import

The system supports data import from CSV files to automate the data entry process.

2. Row Editing

Streamline the process of transaction status conversion through an editing feature.

3. Prioritizing

Put low-priority data under expandable rows and using tooltips for details presentation to highlight critical data in the table.

Requirement Gathering

 

1. Stakeholder Interview

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.

Personas: product owner (left) and users (right)

2. Understand Workflow

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“.

Workflow for auditors

3. Key Features

To summarize from user research and interviews, the new system is expected to incorporate the following features.

Main Features in the BRACE system

Design Iterations

 

Home Page Designs

Data Table Designs

Pixel-perfect Mockups

Deliverables

 

Interaction Maps

Interactive Prototype in InVision

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.

Takeaways

 

Context is KEY for design

Often a solution to a problem seems simple, yet the challenging and the vital part is to understand the problem itself. There are often guidelines telling you that pattern A is good for scenario B, but these rules may not work well under condition C or with constraint D. It is important to avoid jumping into conclusions without thinking critically. Engaging users as early and as often as possible through the design process would greatly help to come up with thoughtful and practical designs.

Experiment on Solutions

Design can never be perfect but can always 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. The best way to save effort on communication is to engage the rest of 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 goal and ensure the project gets enough budget.