Turning notifications into a decision-critical attention system
Figma
Miro
ExcelTL;DR
The Problem
Critical revenue approvals were being missed because they were drowning in a noisy, system-driven notification feed.
The Solution
Replaced the "broadcast" model with a logic-based priority engine, giving power users control over what interrupts them.
The Impact
Reduced approval latency by 35% and eliminated missed SLAs for critical events.
About the Project
This work was part of a larger Command Center redesign for a B2B Ad-Tech platform used by enterprise sales, operations, and leadership teams.
Voiro operates as a centralized decision environment where teams manage campaign approvals, make revenue-impacting decisions, handle SLA-bound workflows, and collaborate across sales, ops, and management functions.
In this environment, notifications were not secondary UI elements. They were decision triggers.
The Problem
The legacy system treated every event equally. A server maintenance ping looked exactly like a $50k budget rejection.
Nearly every event triggered a notification
No prioritization or relevance filtering
No user-level control
Identical behavior for casual and power users
Observations
As part of recurring working sessions with business stakeholders, product managers, and operations leads, we reviewed how notifications were being used in day-to-day decision workflows.
Across these conversations and walkthroughs, a consistent pattern emerged:
Notification volume was high, but interaction rates were low
Alerts were frequently marked as read without any follow-up action
Users often bypassed notifications entirely, navigating straight to dashboards to understand what had changed
Business teams flagged delayed approvals and missed responses, despite alerts being technically delivered
In isolation, each signal looked minor. Taken together, they pointed to a deeper issue: the notification system was functioning at a technical level, but failing behaviorally, it was no longer trusted as a reliable trigger for action.
How the Problem Surfaced
I initiated a series of discovery sessions with Business Heads and Ops Leads to investigate why critical SLAs were slipping.
While Engineering confirmed the system was "technically working" (logs showed emails were sent), our collaborative review of user behavior revealed a different reality. The system was behaviorally failing.
The "Read-Ignore" Pattern
Stakeholders flagged that users were marking alerts as "read" without acting. High volume was driving low interaction.
The Dashboard Detour
We observed users bypassing the notification center entirely to hunt for tasks in dashboards manually—a clear signal of broken trust.
Operational Latency
Business teams reported delayed approvals despite alerts being sent. The "Alert" channel had lost its authority to drive action.
Reframing the Problem
Initial focus and framing
The initial framing treated notifications as a UI problem. The focus was on visual polish, consistency, and adding more system rules to better surface events.
The reframed approach
The problem was reframed from improving notifications to defining who controls attention. This shift repositioned notifications from system-generated alerts to a governed, user-controlled decision layer.
Core Design Principle
Every notification should tell a complete story at a glance. We moved away from generic alerts to structured data units. And also notification must answer three questions immediately.
1. Context
What happened?
2. Location
Where did it happen?
3. Source
Who triggered it?
4. Relevance
Does it require action?
5. Action
What should I do next?
User Control as a First-Class Feature
Instead of expanding system-driven rules, we made a deliberate shift: User control became a first-class feature.
Power users were given ownership over:
- Which notification categories matter
- Conditional triggers (when X happens and Y is true)
- Object-specific subscriptions
- Time-based controls (working hours, DND windows)
This aligned responsibility with control. Users were no longer passive recipients of alerts, they became curators of their attention.
Notification Taxonomy & States
To ensure scalability and predictability, we defined a structured notification taxonomy
Principle based breakdown
Single vs grouped notifications
Notifications logic framework
Developer Handoff & System Reliability
Given the fragility of notification systems at scale, design intent needed to survive implementation.
I authored a detailed logic framework covering:
Event → trigger → notification mapping
Avatar and indicator construction
Grouping behavior
Trigger Logic Configuration
I owned the notification system architecture from interaction design through logic definition and developer handoff. This reduced ambiguity and ensured consistency across future extensions.
Final Visuals
Metrics & Operational Signals
Because this was an enterprise system, success was measured through behavioral change and execution reliability, not surface-level delight. Post-rollout, the system showed clear signs of regained trust and operational impact.
Faster Approvals
Reduction in time-to-decision for budget requests.
Missed SLAs
For high-priority/critical flagged notifications.
Adoption Rate
Users began relying on the bell as their primary to-do list.
What We Chose Not to Do (Decision Trade-offs)
We did not expand the existing system-driven model
Adding more hard-coded rules would have reduced short-term complexity but failed at scale. Priority is contextual, and centralized logic would always misrepresent someone's needs.
We did not reduce notifications to minimal alerts
We avoided context-less alerts that required navigation to understand intent. In a high-stake environment, clarity outweighed surface simplicity.
We did not make notification control admin-only
Power users own outcomes. Removing their control would have shifted responsibility back to the system and recreated the original trust issue.
We did not optimize for zero-configuration onboarding
We accepted higher upfront setup effort in exchange for long-term relevance and reduced cognitive load over time.
Reflection
In high-stake systems, notifications are not alerts, they are contracts between the system and the user.