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. The platform's value case is built on a single, coherent tech stack that surfaces errors, recommendations, and real-time progress during SDLC failures — an efficiency gain estimated at 25 hours per developer per year.
But that coherence depends on consistency. For years, the contributing 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 — resulting in inconsistent priority classifications, variable content templates which impacted readability, and no reliable mechanism to manage what reached them.
Notifications are the primary channel through which the portal communicates errors, status changes, and recommended actions. Left inconsistent, they risked undermining the very efficiency gains the platform was built to deliver. The platform needed a unifying taxonomy — a shared classification system for how notifications were categorized, delivered, and experienced.
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.
Each team decomposed their notifications through a structured mapping exercise, answering questions about triggers, audience, feedback, and delivery form.
Outcomes
The taxonomy became the standard classification system across all 12 product teams. Its classification logic drove consistent content templates that improved readability and pattern recognition — reducing average time to act on key SDLC notifications to under 10 minutes.
From taxonomy to design system
With the taxonomy validated, I worked with the design system team to define a notification pattern for the portal. The pattern incorporated the decision tree as its entry point — guiding teams through classification before pointing them to the right component. Each delivery mechanism in the taxonomy mapped to a specific component: alerts, snackbars, modals, and notification center integrations, each with usage guidelines derived directly from the taxonomy's dimensions. This meant teams didn't need to interpret the taxonomy in the abstract — they could follow the decision tree, land on a component, and build with confidence that their implementation was consistent with every other team's.
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.
12
Product teams adopted the framework
<10 min
Average time to act on key SDLC notifications
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.