Hello
Private Wealth · B2B Fintech
Wealth advisors had no way to see over-exposed clients at a glance. I designed a risk console that surfaces the right clients in 30 seconds, not 40 minutes.
The challenge: Build a risk explorer that makes the right clients obvious, not a dashboard nobody reads. Three risk factors, 200 clients, one sorted table.
Self-initiated01 · Context
Most of my design work at Northern Trust is under NDA. Rather than leave that domain off my portfolio, I built Meridian: a self-initiated concept that addresses a real problem I saw in private-wealth risk tooling, using generated data so nothing proprietary surfaces.
Meridian is not a Northern Trust product. It's a design exercise. The point is to show I can work through complex financial data: information density, what advisors actually need to see, and how to keep a high-stakes interface from becoming noise.
02 · The Problem
Legacy risk tooling in private wealth is built around reports, not decisions. An advisor who wanted to know which clients had too much rate exposure had to open a PDF, cross-reference a spreadsheet, and mentally rank dozens of accounts. Every review cycle.
Nothing surfaced risk proactively. If a client was dangerously concentrated in rate-sensitive bonds, the tool wouldn't tell you. You had to go looking. And going looking took 40 minutes of the kind of work that should take 30 seconds.
Before: what an advisor was working with
Three disconnected systems. No ranked view. No way to know who needed attention without checking each client manually.
03 · Current State
The existing tool showed one client at a time across six separate tabs. To check rate exposure across all 200 clients: open Tab 3 (Risk Metrics), review, close, open the next client. Repeat 199 times. That's the 40-minute baseline. Most advisors had given up and exported to Excel instead.
04 · Approach
The insight was simple: advisors don't need a dashboard, they need a ranked list. If the most at-risk client is always at the top, you know in seconds who to call. The design work was in figuring out what "at-risk" means across three dimensions, and how to show that without overwhelming anyone.
I computed a composite risk score per client using three factors: rate exposure (duration risk relative to the benchmark), credit quality (weighted average credit rating across the portfolio), and concentration (single-name or sector exposure above threshold). Each factor normalizes independently so the overall score is a fair composite, not a sum dominated by one dimension.
05 · Design Decisions
The primary view is a sortable table, not a collection of cards, not a grid of charts, not a dashboard with tiles.
Advisors already work in tabular contexts. Spreadsheets, CRMs, report exports. A familiar scan pattern reduces training time and cognitive load. A dashboard requires learning a new spatial grammar; a table requires recognizing a pattern you already know.
I'd want to test with advisors who work primarily on tablets or smaller displays. The table starts to get compressed below certain viewport widths and I haven't solved the mobile view.
Rate exposure, credit quality, and concentration. Those three. Nothing else in the primary view.
These cover the three things that keep advisors up at night in private wealth: duration risk when rates move, credit blowups, and concentration that looks fine until it doesn't. Adding more dimensions creates scan overhead without adding decision value.
I'd want to talk to advisors about what regularly surprises them. Liquidity exposure, currency risk, ESG constraints. Any of those might deserve a slot. I don't know without asking.
200 clients with realistic variance across all three risk factors. The prototype runs on real computed data.
Static mockups let you cheat the UX. If the sort and filter work on a list where someone chose which 8 clients to show, you learn nothing. 200 clients with realistic spread means the table actually needs to sort correctly, the scores have to make sense, and the drill-down has to render sensibly even for the boring cases in the middle of the distribution.
The data right now is uniformly well-formed. Real advisor books aren't. That gap is where the next version of this prototype needs to go.
06 · Live Prototype
Pick a risk factor: Rate, Credit, or Concentration. Sort by any column. Filter to over-exposed clients only. Click any row to open the drill-down panel with the full position breakdown. The data is generated; the interactions are real.
Built in React · 200 generated clients · sort, filter, and drill-down all work
07 · Edge Cases
The prototype uses clean generated data, but real advisor books don't look like that. These are the four scenarios I thought through explicitly — each one breaks the default UI assumptions.
A client sits at exactly 15% concentration — right on the limit, not over it.
The default sort puts this client mid-table. But an advisor who just raised the limit last quarter needs to know this client is one trade away from a flag.
Show a "near limit" indicator distinct from "over limit." The row color stays neutral; a thin amber border signals proximity without triggering alarm.
A client has no credit rating data — bond positions exist but ratings are unresolved.
The composite score can't be computed. Treating a null as zero makes this client look safe. Hiding them from the table makes them invisible.
Surface the client with a "Data incomplete" badge and a dash in the credit column. They stay in the sort, ranked conservatively, until the data resolves.
A client holds only short-duration treasuries — rate exposure is effectively zero.
If rate exposure is 0.00, a bar chart or score card looks broken. "0" reads as missing. "Very low" is ambiguous.
Show a filled bar at minimum width with a "None" label. Zero is a valid, meaningful state and the UI needs to say so explicitly.
An advisor sets the risk threshold filter high enough that no clients meet it.
A blank table with no explanation is alarming. Did something break? Is the data still loading?
Show an explicit empty state: "No clients above this threshold" with the current filter value visible. The message is the outcome — a clean book is good news, not an error.
08 · Reflection
The first version had a lot more on screen: a risk breakdown chart per client in the table row, a heatmap view, a timeline showing how each client's composite score had changed over the quarter. It looked thorough. It made the right decisions invisible.
The table got stripped back until the most at-risk client was unmistakably at the top and everything else was secondary. Information density in risk tooling is a design trap: more data feels safer, but it delays the moment the advisor knows who to call. The entire point is to reduce that delay.
What this is and isn't
Meridian is a design exercise, not a shipped product. The 40 min → 30 sec figure is a design target based on task analysis, not measured data from a deployed system. If this were going to production, I'd want to validate that claim against actual advisor behavior.
What I'd do next
The prototype is missing two things: a notification layer (tell the advisor when a client crosses a threshold without them having to come looking) and a comparison view (how does this client's risk profile compare to similar clients in the book). Both are obvious next steps.
The advantage of a concept project is that there's no product manager to negotiate with about scope. The disadvantage is the same thing. Without a real user and a real deadline, the edges stay soft. I kept the scope narrow on purpose. One problem, one view, one decision per risk factor. The goal was to have something clear to say rather than something comprehensive to show.