Hello
Self-Initiated · 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 — without turning the screen into a dashboard that nobody reads. Three risk factors, 200 clients, one sorted table.
Self-initiated01 · Context
A significant portion of my design experience at Northern Trust falls under NDA. Rather than leave that domain invisible on my portfolio, I built Meridian: a self-initiated concept that solves a real problem I observed in private-wealth risk tooling, using generated data so nothing proprietary is shown.
Meridian is not a Northern Trust product. It's a design exercise that demonstrates I can think through the UX of complex financial data — the tradeoffs around information density, advisor mental models, and progressive disclosure in a high-stakes B2B context.
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 single 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 · 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.
04 · 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 map to the three most common advisor anxiety points in private wealth: duration risk in a rate cycle, credit blow-ups, and hidden concentration that looks diversified until it isn't. Adding more dimensions creates scan overhead without adding decision value.
I'd want to talk to advisors who have a fourth factor that regularly surprises them — liquidity, currency, ESG mandates. 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.
I'd want to add edge cases to the dataset — clients at exactly threshold, clients with missing data, clients with zero risk in one dimension. Right now the data is uniformly well-formed and the real world is messier than that.
05 · Live Prototype
Sort by composite risk or any single dimension. Filter by threshold. Click any client row to open the drill-down panel with the full position breakdown. The data is generated but the interactions are real — this is what the experience would feel like in production.
Built in React · 200 generated clients · sort, filter, and drill-down all work
06 · 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 would be natural next sections.
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 — so the case study would have something clear to say instead of something comprehensive to show.