JPMorganChase's internal developer portal serves thousands of engineers, with core capabilities — CI/CD pipelines, application health, observability, risk and compliance — contributed by 12 separate product teams as micro-frontends. For years, these teams had operated as standalone products, each developing their own notification strategies in isolation: different delivery mechanisms, different priority logic, different audience rules.
Bringing them together under one portal made this divergence visible. Engineers were now receiving notifications from 12 teams through a single surface, but with no shared framework behind them — duplicate alerts through different channels, no way to distinguish critical issues from routine updates, and no reliable mechanism to manage what reached them.
The platform needed a unifying taxonomy — a shared classification system for how notifications were categorized, delivered, and experienced.
This project moved through three phases: audit, definition, and adoption. I began by auditing the existing notification landscape across all 12 product teams — cataloguing every notification type, delivery mechanism, and audience pattern in use. From there, I synthesized patterns and gaps into a draft taxonomy, which I iterated through cross-functional workshops with designers, engineers, and product managers. The final phase focused on creating the decision frameworks and reusable patterns that would make the taxonomy practical for teams to adopt independently.
Discovery
The audit phase revealed the scale of the problem. Across 12 product teams, I found over 40 distinct notification implementations with no shared conventions. Teams were making reasonable but isolated decisions — one team used banners for all alerts, another relied on email, and a third had built a custom notification center. The same event could trigger different notification types depending on which product surface it originated from.
To bring structure to the audit, I gave each team two mapping exercises. The first was a delivery mechanism spectrum — ranging from discreet (notification center, inline alerts) to urgent (global alerts, modals) — where teams plotted the notifications they generate. The second asked teams to map their notifications against delivery personas: developers, application owners, architects, data usage SMEs, and executives. Together, these exercises surfaced not just how notifications were being delivered, but who was receiving them — revealing mismatches between audience and delivery mechanism that no single team had visibility into on their own.
From the persona mapping exercise, I extracted notification-specific needs for each delivery persona. For example, Amy the Application Owner — a role that sits across teams without concrete ownership boundaries — revealed a pattern common to many of the personas: notifications needed to reduce administrative burden, not add to it.
Amy's notification needs
From goals
Knows when features ship or blockers arise on her applications — without checking Jira manually
Gets confirmation when automated tasks complete or fail
From behaviours
Fitness score updates delivered proactively — not requiring her to go find them
Improvement recommendations pushed alongside score changes
From needs
Digest-style alerts that rank which programs need attention, not everything as equal priority
Consolidated notifications across programs — one update, not redundant alerts from each owner
Notification when blockers have been logged or escalated to tech group leads
From pain points
Low-noise, pre-triaged notifications — owns multiple apps, can't afford to sort through noise
Proactive push of commonly requested info (lifecycle schedules, fitness metrics) before it's asked for
Cross-team status in one place, not scattered across Jira boards
The taxonomy classifies every notification across six dimensions: Category (what triggered it — process, system, or organization), Delivery mechanism (how it reaches the user — snackbar, banner, email, or notification center), Persistence (how long it lives — temporary, persistent, or archived), Audience (who sees it — initiator, approver, team, or organization), Priority (how urgent it is — critical, high, medium, or low), and Purpose (what it expects from the user — actionable, informational, or acknowledgement). Each dimension answers a distinct question, and together they give any product team a complete, unambiguous way to describe how a notification should behave. The framework eliminated the guesswork that had led to inconsistency — instead of each team inventing their own logic, they could classify notifications using a shared vocabulary and arrive at consistent implementation decisions.
Outcomes
The taxonomy was adopted as the standard classification system across all 12 product teams. It became the shared language designers and engineers used when specifying notification behavior in requirements, design specs, and code reviews — replacing ad hoc decisions with a consistent, repeatable framework.
The central tension was between comprehensiveness and adoptability. A taxonomy that captured every edge case would be academically thorough but too complex for teams to use in daily work. Conversely, oversimplifying it would leave gaps that teams would fill with their own conventions — recreating the original problem. I landed on six dimensions as the sweet spot: enough to classify any notification unambiguously, but few enough that a designer or engineer could internalize the framework without constant reference. Some dimensions, like Status (error, warning, success, info), were deliberately excluded from the taxonomy and placed in the design system instead — they drove visual treatment rather than notification behavior, and conflating the two would have muddied the framework's purpose.
The taxonomy and its supporting decision frameworks became the standard for notification design across the developer portal. Key outcomes included:
12
Product teams adopted the framework
6
1
The hardest part of this project wasn't identifying the dimensions — it was naming them precisely enough that teams would interpret them consistently. Early labels like "Action type" implied all notifications required action, which two of the three sub-types contradicted. Renaming it to "Purpose" changed how people understood the entire category. Every label in a taxonomy is a micro-design decision, and getting it wrong creates exactly the ambiguity a taxonomy is supposed to eliminate.
It would have been tempting to design the taxonomy from first principles — starting with what dimensions "should" exist based on notification design theory. Instead, auditing what actually existed across 12 teams first revealed patterns and edge cases that a theoretical approach would have missed entirely. The audit grounded every taxonomy decision in real usage, which made it much easier to get buy-in from teams who could see their own notifications reflected in the framework.
A taxonomy tells teams what the dimensions are. A decision tree tells them what to do. Pairing the taxonomy with a flowchart that walked teams through classification decisions — "Is this triggered by a user action? → Yes → Is it confirming their action completed? → Yes → Purpose: Acknowledgement" — made the difference between a reference document that sat in Confluence and a tool teams actually used in sprint planning and design reviews.
Writing notification guidelines for 12 teams would have meant either being so generic they weren't useful, or so specific they couldn't cover every team's context. The taxonomy as a classification framework gave teams a shared structure while leaving room for contextual judgment. Teams didn't need to be told "use a snackbar here" — they needed a systematic way to arrive at that decision themselves. The framework approach respected their expertise while ensuring consistency in the output.