Case Study · Fintech · B2B
Multi-Criteria Alert System
Designed and shipped a multi criteria alert capability for investment analysts, a feature no competitor in the segment offered at the time. I owned it end to end, from research to front end handoff.
Problem: Investment analysts had no alerts inside the platform. They checked dashboards by hand all day or relied on outside tools that could only watch one metric.
My role: Sole designer, end to end, from research to front end handoff, working with the Product Owner, Business Analyst, PM and engineering.
Decision: An audit of 8 platforms showed no competitor supported multi criteria alerts. Mapping where alerts start, and an early single modal that didn't work, led to two tiers: a quick alert in a modal and an advanced page.
Outcome: Shipped from zero to production in three months, the only product in the segment offering multi criteria, multi company alerts at launch.
Overview: A capability that didn't exist yet.
Investment analysts had no way to be notified when market conditions they cared about were met. They checked dashboards by hand through the day or used outside tools that could only watch one metric at a time, in a domain where a missed move costs money.
With the Product Owner and Business Analyst I collected the alerts analysts actually wanted to set, mostly around DAI, the platform's Dystematic Activity Indicator. Some of them combined more than one condition: DAI above 7; DAI changes more than 2 points; Gross flow above 5bn; China PMI above 100 and imports below 100. That last kind, several conditions on one alert, is what no competitor supported.
My role: Sole designer on a 0→1 feature.
I was the only designer on this initiative and owned it end to end: competitive research, mapping the scenarios with the Product Owner and Business Analyst, UX specs, flows, UI, a clickable prototype, and front end handoff with engineering. Every decision, from where an alert starts to how the daily email reads, set a pattern the product would keep.
Approach and key decisions: From competitor audit to a two tier system.
I started with the market. I audited 8 platforms, including financial data tools like TradingView and the alert emails of consumer investing apps, looking at three things: how alerts were created, how much flexibility users got, and how results were delivered. Every competitor capped alerts at a single criterion. That gap became our differentiation.
Then I mapped every place an analyst could start an alert: from a general view or a specific instrument, with or without a company selected, from a filter or from a watchlist. Each entry point needed different defaults, and the map made the two tier structure obvious: quick alerts where the context is already known, and a full page where analysts build the rule from scratch.
Early exploration · One modal for everything. My first Create Alert did everything in one popup: dashboard, universe, target, rule and delivery. It worked for a quick DAI alert, but a multi condition rule didn't fit, and the simple case felt heavier than it needed to be. The team also asked a question I couldn't answer well with one modal: how would analysts know whether they were creating a simple or an advanced alert? Splitting it into a quick modal and a full page answered both.
Early version: one modal for every kind of alert.
Two tiers, one system, two entry points. The basic alert opens from the menu on a table row, so it already knows the dashboard and the asset and only asks for the rule. The advanced alert opens from the bell in the top navigation, where there is no context yet, so its page lets analysts choose the asset type, dashboard and universe first. Both use the same components, so moving from basic to advanced feels familiar.
Designing the alert: The final screens, and what reviews changed.
Both tiers changed a lot through reviews with the Business Analyst, Product Owner and PM. These are the final screens and what changed along the way.
Analysts pick a metric and a rule without leaving the dashboard. Ranges read as Between or Outside, and amounts and changes use their own units (K, M, Bn or %, bps), so a rule reads the way analysts say it.
Early versions said Target and Data Type. Reviews showed analysts think in Criteria and Asset Type, so the labels changed to match.
Each criterion expands in place, with an AND / OR choice to combine conditions and chips to select several assets at once. The flow ends with a clear success message, and Manage Alerts got a Duplicate action so analysts could build similar rules faster.
Before sign off I built a clickable prototype of every flow, quick alert, advanced, watchlist and manage alerts, and walked the Business Analyst, PM and Product Owner through it. The UX specs covered error states, tooltips, input variations and empty states like having no watchlist. Designs were signed off and handed to engineering in March 2022.
Constraints and tradeoffs: What shaped version 1, and what we cut.
Some of the most important decisions came from technical limits, agreed with the team early so the design didn't promise what the platform couldn't deliver.
Alerts per dashboard. In version 1, alerts are set per dashboard, not across the whole platform. The same metric, like DAI, means different things on different dashboards, so an alert had to know its context.
Single assets only inside a dashboard. Letting analysts search any asset from anywhere would have let them set alerts that could never trigger. We limited single asset alerts to dashboards for version 1 and planned the open version to ship with the platform's global search.
Daily by default. For version 1 we agreed every alert would be evaluated daily. It kept the rules simple and easy to explain.
In app notifications moved to version 2. The original scope included in app notifications with a notification centre. Engineering capacity made shipping both unrealistic, so we shipped a reliable daily email first, protected the correctness of the trigger engine, and kept the notification centre for version 2.
Delivering alerts: The daily email: a message, not a menu.
Analysts already had several inboxes full of market data, so instead of one email per triggered alert we sent one daily summary at 9am.
My first version grouped alerts by dashboard and linked out to the platform. In a review, the Business Analyst and Product Owner pointed out that analysts want to see what triggered at a glance, not click through to find it. We removed most links, regrouped the content and moved to a table that shows each asset, the metric, its value and the rule it crossed.
The signed off daily alerts summary.
Outcomes: A new capability, shipped with intent.
0→1 capability shipped. Alerts went from non existent to live in production in three months, with one designer owning research through handoff.
Competitive differentiator. The only product in the segment offering multi criteria, multi company alerts at launch, a gap found by a structured audit of 8 platforms.
Built on the design system. Built entirely on the design system I led, so engineers got familiar patterns at handoff.
Scoped for iteration. Version 1 focused on creating alerts and the daily email, leaving the notification centre and open asset search as a clear version 2.
Honest caveat: I don't have usage data to share for this release.
What I learned
The audit changed the brief. Without it we would have shipped a single criterion alert like everyone else. The differentiation came from research, not from the design tool.
Constraints are design decisions. Limiting alerts to dashboards and to a daily rhythm looked like compromises, but they kept every alert meaningful and buildable.
I'd test with analysts, not only with the team. The Business Analyst and Product Owner represented analysts well, but next time I'd put the prototype in front of three analysts before sign off.