Broker Feed Status Report
One status — "Not Feeding" — was standing in for six different realities, ranging from compliance emergencies to cosmetic mismatches to failures the system genuinely couldn't diagnose. Compliance officers responsible for catching trading violations across thousands of monitored accounts had no way to tell which was which — and a third of COMPLY's support volume traced back to that single word. I replaced it with six specific statuses, and support tickets tied to the report dropped by more than half.
COMPLY's core compliance product monitors employee trading — firms restrict access to material non-public information, and employees request pre-clearance before they trade. The broker feed status report was supposed to tell compliance officers one thing: was an employee's brokerage account actually being watched. Instead it gave them a single binary — Feeding or Not Feeding — that was quietly doing the work of six different situations, each demanding a different response — none of it visible from the label.
A report built years earlier by a contractor had accumulated more of these edge cases every year, with nowhere for any of them to live except one alarming word. I was the primary product designer on the redesign, partnering with our VP of Product, the support team, and the broker feed engineering team, after mounting complaints made it a Q1/Q2 priority.
Six Statuses Organized By Required Action
I organized the new statuses around one question: what can this user actually do about it? Not how the system classified the failure internally, but what a compliance officer's next move should be. That distinction is what let six real situations surface as six different signals instead of one flattened alarm: Accounts Not on Feed meant a real gap — call the broker and get it connected. Broker Feed Unavailable meant this broker didn't support an electronic feed at all — paper statements, reconciled by hand, nothing to automate. Undetermined Status meant the data itself couldn't confirm what was happening — flag it for review, not panic. It also meant compliance officers could finally triage and resolve issues in batches instead of escalating everything to support, because the status itself told them what kind of problem they were looking at.
Batch Actions As A Wedge For Table Functionality
Six accurate statuses wouldn't matter at enterprise scale unless compliance officers could also act on them fast, across thousands of accounts at once — and COMPLY's largest clients were monitoring up to ten thousand employees. So when batch actions came up as a requirement, I treated it as an opening rather than a checkbox: quick status filters at the top of the page, deeper global filtering, drag-and-drop controls, more data columns exposed directly in the table. None of it was strictly in the ask. All of it was what made the new taxonomy actually usable at the size some of our firms operated at.
Designing Around The Legacy Pipeline Instead Of A Rebuild
The truth is, I didn't get to fix the thing I actually wanted to fix. The broker feed ingestion pipeline was years old, and rebuilding it was out of scope for a project that needed to ship inside a quarter. So I designed around its limitations instead — statuses like Undetermined Status and Manually Confirmed on Feed exist specifically to absorb ambiguity the underlying data couldn't resolve, like an account with zero trading activity that looks identical to a broken feed. It was the right call for shipping on time. It wasn't the call I would have made with a longer runway.
Outcome
Support requests tied to the report fell by an estimated 60–80% post-launch — the exact percentage moved month to month, but the direction and magnitude held. Time-to-resolution improved too: compliance officers could now resolve more issues themselves — batching actions across dozens of accounts at once, filtering down to exactly the ones that needed attention — rather than opening a support ticket for each one.
We backed the launch with an in-product walkthrough, updated FAQ documentation, and training for sales and support, validated across two rounds of user acceptance testing — one before launch, which reshaped the final status wording and filter priorities, and one after, which confirmed it held up in practice.
Reflection
The honest compromise in this project: the ingestion pipeline had more signal than we were using. Cash holdings data, for instance, could have confirmed an account was actively feeding — we had it, and weren't using it, which is part of why two of those six statuses had to exist at all. I pushed to fix that at the source and was outvoted. The org's appetite was for shipping fast, not touching a legacy system nobody wanted to own.
Two years later, under new engineering leadership, that rebuild finally got funded — and when it did, some of the framing from this project fed directly into it: what compliance officers actually needed the data to say, not just what the pipeline happened to produce. The read on the problem outlived the project that first surfaced it.
One misunderstanding costing you more than you think?
Naming the problem correctly is what let people solve it themselves instead of opening a ticket. Always glad to talk shop.
Get in touch