Wealth Management Platform

The problem

The advisors were working in legacy software where every asset lived on its own page. To answer one question about a client — how much of this property do they own, what loans sit against it, what it costs to keep — you opened a tab, read it, went back, opened the next one. There was no place where the whole balance sheet and the data behind it existed at once.

Bucket View

The screen an account manager works in, rebuilt so you can use it. Switch to Modify to edit cells in place, or to Only missing fields to see what is still open. Click a document icon to open the file behind a value — and turn Fields on inside it to check the document against what was typed. The clock on a cell opens that field’s history.

Rebuilt from scratch for this page. Names, addresses, documents and figures are invented — the original product is under NDA.

What I did

I designed how the data nests: assets by type, and under each asset the things that actually get asked about — ownership percentages, loans, expenses, value — reachable without leaving the record.

The harder half was the platform. The product runs on Salesforce, which hands you a record page and a set of conventions, and none of them produce this screen. Working with a PM, a business analyst and the engineering team, we worked out where Salesforce could be pushed and where we had to build on top of it.

The trade-off

I deliberately went against Salesforce’s own guidelines for this flow. Following them would have been quicker to build and cheaper to maintain — and it would have preserved the exact pattern that made the old software slow: one asset, one page, one tab at a time. The price is a screen that does not behave like standard Salesforce, and a team that has to keep it that way on purpose.

Result

Processing a client’s asset information got 40–60% faster. The work that used to be spread across tabs happens in one place, and what is missing is visible instead of hunted for.

Four decisions in this screen

Metadata sits on the value, not in a tab. A cell carries its own history and its own document, so the question “where did this number come from” is answered without leaving the row.

Missing is a state, not an absence. An empty cell tells you whether nothing was ever provided or whether a document has been requested and is still on its way. Those two need different work from the manager, so they cannot look the same.

The document opens next to the fields it feeds. Turning on Fields puts the scan and the typed values side by side, which is how the checking is actually done — read a line on the deed, confirm the field, move on.

Editing happens where reading happens. No separate edit screen: the same table becomes writable, so the manager never loses the row they were looking at.