Fund Data Search

The admins of a fund management business were struggling to keep up with the constant inquiries from their fund dealers. Because the dealers did not have access to the fund accounting services the admins used, the only way for them to stay informed was by directly asking the admins.

The Fund Data Search is a portal that allows the dealers to access this information, via a granular search function and a results table that can be curated to their specific task at hand.

To remain compliant with my NDA and client confidentiality, this case study only showcases wireframes and sketches

The Product and the People

Toogood Financial Systems (TFS)

TFS provides investment related services such as fund accounting and portfolio management. Through the client-facing portal Piersight, TFS takes the data from these services and packages it in a modern, user-friendly browser experience.

For brevity, the investment services TFS offers will be considered the backend engine, and Piersight portal to be the frontend.

The clients and the users

Clients: the admins of a fund management business. TFS provides fund accounting services to them. They are looking for a way to better support their own clients, the fund dealers.

Users: Dealers of a fund dealer company. They are looking for easier access to their fund and investor information to assist them with their day to day tasks.

My role

I am a product designer for Piersight. For this project, my responsibilities include

Requirements gathering
Design
Technical solutioning with dev and QA
Sprint planning and release scheduling

Problem

The admins were working with 25 fund dealer companies, each with multiple individual dealers. Supporting all these dealers have stagnated the growth of their business, as they don’t have capacity to onboard new clients.

The request was to create a new service in Piersight dedicated to searching and surfacing information, so the dealers can find their own answers without help from admins.

Insights and Discovery

We met with both the clients and their dealers regularly over the first months to conduct extensive user interviews and some contextual inquiry. Our goal was to understand

What pieces of data points were the dealers inquiring about, and its relative frequency
Why do they need these information, and what will they do with this information once received
Other user experience insights that may benefit their workflow

We also took a look at a competitor system the clients tried to use, but ultimately turned down. We performed a detailed audit to analyse the pros and cons, and a summary of our finding is as follows:

The search parameters were rigid and too general
The results tables didn’t handle large quantities of data gracefully (lacked good filtering/sorting)
Support and compatibility concerns with TFS’s fund accounting services

From this research, we have gathered a few key insights:

Visual Density

Users tend to value data density over breathing space in the UI. They would like to see more data points even at the expense of some visual busyness.

Requirements Gathering

We used a traceability matrix model to record requirements, features, search parameters, and data points with the clients.

Below are excerpts and highlights of requirements.

Four categories

The service will be split into 4 separate searches:

Fund Orders,
Investor Information,
Holdings, and
Fund Setup

Column control

Result columns should be customization (move, show or hide), and there should be preset column templates so dealers have easy access, a QoL feature for repetitive tasks.

Parameters and Data

Search parameters and data points for each category have also been agreed upon.

Exports

There will be options for exporting results, as XLSX or CSV files.

Connected searches

There will be ways to chain searches from different categories together.

For example, clicking on an account in Fund Orders results will automatically execute a search of that account's owners in Investor Information.

Design & Challenges

Thanks to a robust design system, the wireframing and prototyping stages went by quickly. Our system had existing interactive elements that translated well to both a search and results UI. Below are some of the design notes and thought processes.

The search parameters
Even though there were dozens of search parameters required, we tried to reduce the number of patterns as much as possible in order to reduce the system’s learning curve and complexity. We concluded that every search parameter required can be covered by 4 general design patterns:

Through studying existing workflows of the dealers during the contextual inquiry exercises, we determined the way we should order the search parameters (when applicable) on the page. These reflect the thought process of a dealer when they’re trying to identify something.

When: date related parameters always at the top
Who: Parameters that identify who or what the search is about will come next.
Misc: all other parameters and modifiers last.

Cross-category connected searches
It’s common for an inquiry to require multiple searches to be answered. For example, if a dealer looks up an order in Fund Orders, oftentimes they’d also like to look up the owner of the account in Investor Information.
We’ve identified the most common connected searches, and designed a way for dealers to execute that follow up search by clicking on a results data point. Through this, we can connect otherwise separate parts of their business operations together and drive efficiency.

Early alpha testing

Since the project was all about finding and surfacing data, it was difficult to evaluate the design with just wireframes and prototypes but no actual data to test with. For this reason, we decided to jump to early alpha testing sooner than normal. We built one out of four categories first, populated it with test data and allowed the clients to test this early build.

The key questions we had were

Are the the search parameters detailed enough to find what you need?
Is the results screen clean and easy to use?

The feedback was generally positive, and the bulk of the suggestions were simply additional fields the users would like to find and see. This feedback eventually lead to the implementation of an additional section that houses additional data points.

One example of a feature implemented after alpha testing: We implemented an order details modal that can be opened from the results screen to show additional fields deemed too niche for the main results screen.

The data flow problem

Through early alpha testing, the main technical problem we encountered came from data flow and its effect on load times. The quick summary of this problem is as following:

Big searches that yield a lot of results are taking longer than expected to load.
Sorting/filtering features don’t work until all data has been loaded in.

Internally, we have identified a way to optimize the load times, but we will need an immediate workaround due to our timeline.

We did some investigation to get a better understanding of the situation (see below). We concluded that even though not every dealer has the number of records to exceed 10k records per search, ones that do will exceed that threshold quite often.

10,000 records

The number of records we can load into the front-end before the loading times become longer than 10 seconds, which is Piersight’s maximum acceptable load time.

2 out of 25

Number of all prospective dealers have enough records to net over 10k results with 1 search (~11,000 as of time of investigation).

Extract Creation

Most common use case for running a big search. Commonly done so the dealer can create an extract of the entire category, export it as an XLS to fuel downstream processes.

The (temporary) solution to the data flow problem: The back-end export

We proposed a workaround for the clients. They have found it acceptable as it still addresses the main use case for the fund dealers:

Implement the 10k results threshold in order to maintain fast load times and access to all sorting/filtering features.
Provide a second export option that extracts from the back-end. This ensures all results will be captured.

This will be in place until our backend optimization is complete, and we’ll reevaluate whether or not this feature will be kept.

With this main challenge out of the way (for the time being), our MVP was ready.

Introducing the Fund Data Search (MVP)

The Fund Data Search is a tool that allows dealers to oversee their investor activities and fund prices in a streamlined and centralized manner. This is done through a detailed search function, and a results page that can be customized based on preference or task at hand

Results customization

The results page offers high degrees of customization. Sort your columns, rearrange them and even show and hide them to suit whatever task you have at hand.

We used AG Grid, a third party datagrid, to provide column sorting and filtering features.

Column Customization

Interconnected Searches

Certain data points, when clicked, will execute a predetermined search, allowing users to jump between categories quickly without having to enter a new search every time to find related information of their current search.

Results

1 / Getting a breather

Our clients, the fund admins, have reported that the Fund Data Search has achieved their goal of reducing support efforts after they’ve onboarded 2 of their busiest dealers.

2 / All on board

Since then we’ve onboarded the other 23 of their dealers, bringing the total to 25.

3 / Keep them coming

By removing the support bottleneck the clients were experiencing, they’re also able to expand and bring on new dealers to their business. We are expected to on board 1 additional client per quarter.

TFS has also provided the Fund Data Search to other clients that experience similar issues.

Next steps

With a much larger sample size of users, we were able to gather feedback and insights for how to iterate on the existing design. A few items we would like to address for phase 2 and beyond:

Complete optimizing back-end to front-end data flow; remove 10k threshold restriction

Implement ability to save custom column configs on a per-user basis.

Create permissions model to grant or limit access to search and results.

Takeaways

1 / Backend to frontend data flow

Gained better understanding of data flow between back-end and front-end systems. A product designer needs to see the product holistically and take into consideration technical challenges a design may introduce. We cannot settle for “we’ll cross that bridge when we get to it”, or “we’ll let the devs figure it out”.

2 / UX for large data sets

Grasped the nuance of designing UX for large data sets, and how to make rows and rows of data usable.

3 / Catering to now vs future

Our plan was to also offer fund data search to other clients, as this tool is extremely useful for all investment related businesses. Due to this we have to strike a balance between catering to the current client’s immediate needs versus keeping the product malleable for future clients.