Please view my figma presentation for an overview of this project.

 Objective:

• LoanStreet processes hundreds of payments a month on behalf of our clients. LS internal users were beholden to a convoluted, brittle legacy tool in order to view any and all payments. Clients and LS users required a better solution to view payment history respective to a loan and pool.

• In order to understand the problem space, I interviewed our internal team about how they navigated the payment space. I also observed the internal team investigate and fix discrepancies during reporting week. Since there are 100,000+ payments stored in the LoanStreet database, I understood that the correct placement for the payment record was on a loan level. In terms of the hierarchy, there are pools -> loans -> payments. This is the mental model of how a user would want to discover a particular payment.

Outcome:

As the sole designer on this project, I created a payment tool to allow LoanStreet users to audit and resolve discrepancies within their 100,000+ history of discrete loan payments.

Design

• I designed, tested, and created an expandable card component that was added to the LS design system. This allows high level information to be immediately understood (e.g., principal, interest), as well as opportunity for the user to dive into the historical details respective to a payment event (e.g., adjustments, decomposition, notes).

• Since users would often compare and contrast multiple payments often, the table would allow for multiple cards to be expanded at the same time.

I kept the table controls to a minimum - date filter, with the ability to offer two global actions - add payment, add adjustment, and download table.