An internal trading platform built on legacy architecture, used daily by expert front-office users with zero tolerance for errors. The challenge wasn't just design — it was navigating technical limits, business politics, and compliance requirements simultaneously.
TD Prime Services
The Prime Services internal trading platform was built for expert users — front-office and operations teams who lived inside it all day. But years of patched-together functionality had left it difficult to scan, impossible to learn without institutional knowledge, and impossible to scale without breaking existing behaviour.
My brief was to redesign the platform across multiple modules — Prime Service, Thick Client, Swift Messaging, TDFX, TD Securities CMS, TD Precious Metals, and One Portal — while working within tight constraints from three directions at once: technical architecture, business workflow requirements, and stakeholder politics.
A concrete example of the starting point: the Money Wire screen showed one transaction row in a full-screen view, used a neon green row highlight as the only status indicator, and embedded raw audit logs directly into a table cell. Users who were new to the platform couldn't read status at all without someone explaining the colour codes first.
Due to NDA, most visuals are intentionally blurred. One legacy screenshot is shown unredacted — shared with permission to anchor the before/after story. The work itself — the decisions, the trade-offs, the reasoning — is what this case study is about.
Most design problems have one dominant constraint. This one had three operating simultaneously — and any decision that solved one often created friction with another. Mapping them clearly was the first design act.
After reviewing workflows, auditing every high-traffic screen, and sitting with users, four patterns emerged that shaped every design decision that followed.
Don't redesign the platform. Redesign it in a way that makes the workarounds unnecessary — without punishing users for the habits they built to survive the old one.
Years of patched-together functionality had produced a platform that only worked if you already knew how to use it. The redesign brought it into the TD design system — without disrupting the workflows expert users had built around it.
No label, no icon, no text. "CAPPR1" was meaningless unless you already knew the code. New users made approval errors because the screen had no accessible language for status.
CcyOut, WireInst, WireRefNum, SenderBic, UniqItspId, IndDirection — all the same size as Client and Funds Out. Users had to scan every column every time to find what actually mattered for the decision at hand.
"2023-12-01 16:53:08 · sugasm3 · CAPPR1 · comment4" — raw log strings concatenated directly into the Comments column. Reviewing history meant parsing text, not reading a timeline.
Acknowledge, Reject, Approve, Excel, Refresh — all equal-weight toolbar buttons. Destructive actions sat next to informational ones with nothing separating them visually.
One transaction row in a full viewport. Users processing queues of wires reset cognitively to a nearly blank screen between every record — a hidden time cost across an entire trading day.
Status is now text-first: readable labels in the first column, colour as reinforcement not replacement. A new user can understand the queue on day one without needing institutional knowledge handed to them.
Status, Effective, Client, Funds Out, CcyOut — the decision-critical columns — are prominent. Reference columns are accessible but deprioritised. The eye goes to what matters without scanning everything.
Entity, Account, Status, date range — a structured left panel puts filtering in its own space. The table toolbar is reserved for row-level actions: Approve, Reject, Export, Refresh — contextual and consequential only.
Instead of one row in a sea of grey, 10 records are visible with clear pagination. Users can scan their queue, select multiple rows, and act in batches — a workflow that previously required exporting to Excel first.
The same component library, token system, and interaction patterns now run across Money Wire, Thick Client, Swift Messaging, TDFX, CMS, Precious Metals, and One Portal. Onboarding to a new module no longer means learning a new interface.
The Trade Breaks screen is the most honest part of this case study. It's a story about a design problem I couldn't solve the right way — and how I found a third option nobody had asked for.
Trade Breaks — initial design (visuals blurred)
UX intervention — row-level pop-up (visuals blurred)
Business users required Client Trades and Street Trades to appear on a single page, side by side. Two dense data grids, hundreds of rows, on one screen. The cognitive load was severe. The right UX answer was to separate them — but that was off the table.
Users had a genuine need: they needed to cross-reference Client and Street trades simultaneously to identify breaks. Separating them would have eliminated the visual comparison that made the page useful. The layout was right for the task — it was just implemented poorly.
Instead of restructuring the page, I introduced a row-level pop-up view. Clicking any row surfaces a detailed comparison panel for that single trade — Client vs Street side by side — without leaving the master grid. Users could inspect one trade at a time without losing the full-page context they depended on.
This wasn't the cleanest solution — a dedicated detail page would have been better UX and I proposed it twice. Both times it was rejected because users said they needed to see both grids simultaneously to spot breaks by eye. The pop-up was the third proposal, and it passed because it didn't change the page structure stakeholders had already signed off on. That's a real constraint. Sometimes good design means finding a third option, not winning the argument about the first one.
One of the most durable outputs of this project wasn't any single screen — it was the design system that ensured every module looked and behaved consistently, and that future designers wouldn't have to solve the same problems from scratch.
Emerald design system — component library (visuals blurred)
Design specifications & annotations (visuals blurred)
Every component — buttons, accordions, avatars, badges, cards, carousels — was built once and documented for reuse across all 7 modules. This eliminated inconsistency that had accumulated over years of independent feature development.
Expert users rely on muscle memory. Standardising hover states, click behaviours, modal triggers, and data loading patterns meant users could move between modules without relearning interactions.
The system established a clear visual language for data-dense screens: typography scale, colour usage for status and alerts, grid density rules, and column priority for financial data tables — so hierarchy was built in, not bolted on.
Every component was reviewed against compliance and accessibility requirements before being added to the library. This meant design decisions didn't get reversed in engineering — they'd already been validated upstream.
"The hardest skill in enterprise UX isn't designing the ideal solution. It's finding the best possible solution within constraints that are real, immovable, and sometimes in conflict with each other — and making peace with that."
