Scaling a finance application for enterprise

A B2B application worked for SMBs, but as larger companies signed up it faltered.

The client portal for FastPay, a provider of working capital solutions to customers in the adtech sector, had already greatly benefitted from my redesign of version 1, a table-based interface designed by the developer team.

The client portal v.1 designed by developers had numerous UX issues when I came on board.

We had been conducting user testing and interviewing key users and internal SMEs, iterating on adding and refining features to constantly improve the user experience. Significant progress had been made over the course of several months.

A pipeline view replaced the initial default spreadsheet, and segmented funding requests by status to facilitate workflows.
Extensive research through session replay technology indicated a need for a dashboard, contradicting the initial assumption that users would primarily use the pipeline view.
Additional research indicated that segmentation by status did not match the user mental model and was not scalable. Additional information was more important to them to be surfaced in the dashboard.

Our efforts came up against a blocker as the company signed up more and larger companies. The funding process at FastPay required users to upload supporting documentation as part of their funding request. Each funding request had to have a client invoice attached to indicate the amount of the funding request, but many customers also had to submit additional documents such as media buys, contracts, SOWs and so forth.

The existing solution was manageable for SMBs who would have say 25 or so funding requests in the pipeline at any given time, but we now had some users who were uploading hundreds of invoices along with supporting documentation. This process often took hours.

To accommodate these users, a bulk import process was introduced for invoices; they could upload a spreadsheet of invoice information. However they would still need to manually upload the supporting documentation for each invoice. In some instances this meant attaching the same contract to multiple funding requests; maybe the same contract but different SOWs to different funding requests dealing with the same client.

As we began to sign contracts with customers who intended to submit thousands of invoices at any given time, it became clear the original SMB-oriented B2B portal could no longer scale.

I began to explore different ways to provide simpler submission of multiple invoices for funding with one-to-many and many-to-one supporting documentation functionality, versus the current system limitations of 1:1 documentation. An entirely new approach was outlined, called the Action Center, that would proactively offer smart suggestions for attachments and allow batch processes that would also be surfaced on the dashboard. The attached wireframes served as the basis for socializing and refining this concept internally.

The new Action Center would provide smart suggestions to allow bulk 1-to-many and many-to-one attachments for hundreds of funding requests.
The user goal for the Action Center was to clear out all supporting requirements for all funding requests.
The acquisition of a company required reworking the design standards to integrate aspects of both company’s branding as well as new research insights.