Large Objects
At Intapp, I led the design of Large Objects for DealCloud, a CRM used by thousands of professionals across the legal and financial industries. It helps people who work with very large lists of records see what changed and where, without waiting for every record to load. My PM, the engineering team and I explored the solution together over one to two months.
Some DealCloud lists can hold millions of records, and they cannot be trimmed. DealCloud's customers are in the financial and legal industries, where regulations require firms to keep this information. When an issue comes up, they must be able to retrieve it. The data only grows.
People were frustrated by how long these lists took to load and by how hard it was to find their way around the data set.
How might we help people understand a very large list they are required to keep, without loading every record to do it?
- The records have to stay. Financial and legal regulations mean firms keep everything, so making the list smaller was never an option.
- The overall picture is the everyday job. There was little usage of finding a specific record in these objects. Day to day, people need the overall picture. Looking up one exact record is the rare case, for when an issue comes up, but it still has to work.
- Loading is the pain. Bringing every row to the screen is what made the page slow, and it served a task few people had.
- People lose their place. After a few clicks into a drill-down, it is hard to say which filters produced the view in front of you.
These came from working through the problem with my PM and the engineering team, and from what we already knew about how people use DealCloud lists. The design had not been tested with customers yet.
One thing shaped every option, and it was not about users.
The design system had limited chart guidance. It did have some data visualization, just not enough to cover a page like this. Every new chart type would be a pattern someone had to define, build and maintain. So the question became: how little chart vocabulary can this get away with?
Over one to two months, working side by side with my PM and the engineering team, I explored three directions. Each one puts a different thing in charge:
- Chart leads: open on a trend over time. Select a range of bars and the table below filters to it. The bet was that on a list this large, the first question is "what is changing?", and a chart can answer that from counts alone.
- Table leads: keep the table people know, group it, and add a small trend inside each grouped row. The bet was that the smallest change is the safest one: people already trust the table, so bring the analysis to it.
- AI leads (Ask Celeste): skip the dashboard. Ask in plain language; the answer shows the filters it used and the records behind it. The bet was that a question is faster than any chart, if the AI can be relied on. On top of the Celeste team's direction, I also proposed including Natural Language Filter as an option here, since it already turns a plain-language question into filters people can check. My PM and the engineering team evaluated it.
I considered all three. Here's how they compared:
The fastest read on what is changing: a jump in the last three weeks is obvious at a glance. It needs counts, not rows, so it appears straight away at any list size. And it matches the real need, which is the overall picture.
A trend says when something changed but not where, so people would still load records to find the cause. Selecting a range and comparing periods also needed chart patterns the design system did not have. Both were things I could solve inside the direction.
Nothing new to learn: the same table, filters and columns. It needs only one new chart pattern, a small trend in a cell, so it was the cheapest to build and to add to the design system.
It still starts from rows, so it keeps the slow load that frustrated people. It is built for finding one record, which few people did here. You must pick how to group before you see anything, and small trends stacked in rows are hard to compare, so a change that cuts across groups is easy to miss.
It avoids the chart problem entirely, and no rows load until asked.
My PM and the engineering team evaluated this option and kept both Celeste and Natural Language Filter outside the scope of this project. The Celeste team's direction was also still too far from what I could design against. So I dropped it. Answers are also hard to scan or repeat, and people must know what to ask.
I went with Chart leads. Table leads kept the slow load, and AI leads was outside the project's scope. That left two things to work out inside the chart direction: what information to show, and what colour to show it in.
Once the chart led, the question became which information would actually help. I sat down with my PM and the engineering team and we listed two things: what we knew we could produce from the data, and what our users needed to see. The summary shows only what was on both lists: how much, when, where, and what stands out.
The two charts filter each other. Click a week and the stage list shows that week's breakdown. Click a stage and the trend shows that stage's history. Two clicks take a very large list down to a small, focused set, before a single record has loaded.
The summary has two views: a trend over time and a breakdown by stage. I compared keeping them as two cards against merging them into one.
Heights match by design, with no filler. One metric switch and one date range clearly apply to both views, and the two answer one question together: what changed, and in which stage.
No separate menu for each chart, and on a narrow screen the stage list drops below the trend.
The smallest change. Each card keeps its own title and menu, like other DealCloud dashboards.
The heights only match by stretching one card and padding it with filler, and it is less clear that the controls apply to both.
With limited chart guidance in the design system, I kept colour to the minimum the page needed:
- One colour for data. Every bar is the same teal, so nothing implies a difference that is not there.
- Navy for "selected". The bar or stage you clicked turns navy and the rest fade, so the selection is clear without a second chart type.
- Orange only for a big change. It marks what deserves a look, and nothing else.
- No green or red. More deals created is good and more deals going stale is bad, so "up" cannot have a fixed colour.
The summary comes first and appears straight away. Records load only when someone asks for them.
Click a bar to pick a period. Click a stage to pick a segment. Each click appears as a chip at the top of the page, in the same form as any other DealCloud filter. A chip can be paused or removed, so people always know why the page shows what it shows.
Because few people came here for one record, the table no longer loads by default. A button shows how many records match the current filters and loads them when needed. Every record is still retained. When an issue comes up, people can filter down and retrieve exactly the records they need; nothing is fetched until then.
Loading and error states say what is happening when counts are slow or fail, and keep the filters in place.
Over one to two months, my PM, the engineering team and I took an open problem to one recommended direction, with three explored options and the reasons each was kept or dropped. The design had not reached customers yet, so there is no usage number to report.
Backed by my PM and leadership, and added to the roadmap.
When people are required to keep everything, the job is not to help them find one thing. It is to help them understand the whole without paying to load it. And when something is still undefined, the most useful design is the one that works without it and leaves a clear place for it to arrive.