🔒
Protected case study

This project is covered by an NDA. Enter the password to view, or request access and I'll get back to you.

Don't have the password? Request it here →
⚠ NDA — Some details are intentionally generalized

Alert Framework

AbbVie Operations' first centralized notification system. A unified platform for real-time KPI alerts for operations teams to monitor critical metrics across the enterprise.

Year
2023–2024
My Role
UX Lead & Product Owner
Team
1 UX Designer · 5 Developers
Platform
Web + Mobile (Internal Enterprise)
Key Outcomes
12
KPIs live in production
1st
Centralized alert system
2
Phase delivery model
Overview

The problem we were solving

AbbVie's Operations Launchpad is the central hub for reporting applications across the enterprise, but it lacked something critical: a unified way to monitor and act on changes in business-critical KPIs. Notifications were scattered across individual applications, inconsistent in timing and format, and impossible to manage from a single interface. Data analysts and operations leaders had no reliable way to stay informed of threshold violations or other critical events that demanded immediate attention.

This was the first time any centralized alert system was being built for Operations at AbbVie. The challenge was clear: create a notification framework that could integrate with dozens of existing reporting applications (built on different platforms — Qlik, Spotfire, PowerBI, custom web applications), standardize how alerts are triggered and delivered, and make it easy for users to stay on top of what matters most to their role.

Scope and execution: We delivered the alert system in two phases. Phase 1 established the core platform with custom application notifications on desktop and mobile. Phase 2 refined the user experience and scaled to onboard diverse application types(Qlik, PowerBI etc.) . By the end, multiple KPIs were live in production from different business verticals, each actively used by 5–6 business stakeholders.

Research & Discovery

Understanding the notification landscape

We started by studying how alert systems work across industries, examining frameworks used in fintech, healthcare, and infrastructure monitoring. The research revealed a clear pattern: the most effective systems balance real-time urgency with user control, allowing people to customize what they're notified about without creating notification fatigue.

Next, we conducted a systematic audit of the Ops Launchpad ecosystem. We mapped every application currently on the platform, identified how each one handled notifications (or didn't), and documented the pain points users experienced when trying to stay informed. We also interviewed functional leads and data analysts to understand which KPIs they cared most about and how they currently monitored them often through manual checks or email spreadsheets.

The findings shaped our initial design strategy: build a system flexible enough to integrate with diverse application architectures, provide clear visual and mobile alerts, and give users granular control over what notifications they receive and how.

Initial Design Concepts

Three core principles

Based on research and stakeholder feedback, we defined three design principles that would guide all decisions:

01
Importance-Based Communication
Different KPIs matter differently. We proposed tiering alerts by urgency: critical alerts via email and mobile, medium-priority via portal pop-up, low-priority via icon notification. Users could customize these rules to their workflow.
02
Direct KPI Integration
Rather than asking users to re-enter KPI data, we would bring in the KPIs already defined in reporting applications and associate alerts with threshold values they specified. This minimized duplicate data entry and kept alerts in sync with source metrics.
03
Custom Alert Functions
Power users wanted flexibility — the ability to combine multiple KPIs using basic math functions (add, subtract, multiply) to create derived alerts. This would unlock advanced monitoring scenarios for operations managers.
Alert Framework v0.1 — early Ops Launchpad concept
Early concept — Alert Framework v0.1 integrated into the Ops Launchpad
Design Feedback & Iterations

What changed, and why

Early feedback from the development team and functional leads revealed that our initial concepts were ambitious but not practical. Several assumptions needed revisiting, and the feedback pushed us toward a simpler, more deployable solution.

01
High/Medium/Low urgency was too abstract
The three-tier importance model sounded logical, but when we discussed it with users, they couldn't easily explain the difference or decide where each KPI belonged. We replaced it with a concrete communication model: Email, Pop-up, or Mobile notification. This was more intuitive — users could immediately understand what receiving an alert via each channel meant.
02
Alert intake needed standardization across platforms
Our initial approach assumed each reporting application would have a consistent way to export KPI data. In reality, Qlik, Spotfire, PowerBI, and custom web applications all worked differently. We created a standardized alert intake process that could accommodate these differences — essentially a template that any application type could plug into, whether it was pulling from a database, API, or manual entry.
03
Custom alert functions were too complex
The idea of letting users combine KPIs with math operations excited the technical team but terrified the business users. We simplified by moving this to Phase 2, focusing Phase 1 on single-KPI alerts. This reduced complexity, shortened the pilot timeline, and let us learn from real production usage before adding advanced features.
04
Mobile integration became critical from day one
Initially, we treated mobile as an extension — design the web experience first, then adapt it. Stakeholder feedback made clear that operations managers needed to receive and act on alerts wherever they were. We redesigned to integrate mobile notifications from the ground up, and it became a key differentiator of the system.
Alert Framework v2 — subscribed alert tile
v2 iteration — subscribed alert tile with simplified channel model
Alert Framework — component library
Component design — standardized alert tiles and UI elements
Two-Phase Delivery

Piloting and scaling the platform

We structured the rollout into two distinct phases to manage scope and gather signal from real production usage.

Phase 1 (Pilot): We launched with core functionality: users could subscribe and unsubscribe from KPI alerts, add new alerts through an Excel spreadsheet upload (low friction, high compatibility), and receive notifications on mobile. The UI was straightforward, though we knew from research it could be refined. Phase 1 was about establishing the technical foundation and validating that users would actually adopt centralized alerts.

Phase 2 (Full Release): With pilot insights in hand, we redesigned the UI around a clearer mental model: Subscribed Alerts (what you're currently monitoring), Available Alerts (what you could subscribe to), and a Latest Alerts section with a red indicator for new activity. We also built a comprehensive user guide for onboarding KPIs from all supported application types, and we enabled advanced features like custom threshold values and user management per alert.

Why two phases worked: The pilot let us launch faster, gather real usage data, and refine decisions based on actual user behavior rather than stakeholder opinions. By Phase 2, we had concrete evidence of what users needed and why. This made conversations about trade-offs much clearer.

Alert Framework — desktop experience
Phase 2 UI — desktop alert management dashboard
Alert Framework — mobile notifications
Phase 1 — mobile notifications integrated from day one
Alerts integrated into Ops Launchpad
Final design — alerts surfaced within the Ops Launchpad portal
Alert Framework — user acceptance testing
UAT session — validating alert behaviour with operations users
Results

What the system delivered

The alert framework became an integral part of how AbbVie's Operations teams monitored the business. By the end of Phase 2, the system was supporting multiple live KPIs, each actively used by roughly 5–6 users — the adoption demonstrated demand.

Production Metrics

  • 12 KPIs live and monitored
  • ~60–72 total active users across all KPIs
  • 100% uptime through both phases
  • Mobile platform integral to engagement

User Experience Impact

  • Replaced scattered, inconsistent notifications
  • Reduced time to detect critical KPI violations
  • Enabled users to customize their notification flow
  • Simplified onboarding across diverse platforms

Organizational Value

  • First centralized alert platform for Operations
  • Foundation for future KPI monitoring expansion
  • Standardized the KPI intake process across platforms
  • Established a template for alert systems elsewhere

Lessons Embedded in Design

  • Simple communication types over abstract hierarchies
  • Mobile parity from the start, not as afterthought
  • Pilot-and-refine approach to reduce risk
  • Standardization solves real integration problems
Reflections

What this project taught me

Building an alert system for the first time at an enterprise scale taught me several lessons that have shaped how I approach product design since.

Simplicity beats hierarchy

The High/Medium/Low importance model felt logical in theory. But when real users had to make decisions based on it, they couldn't. Replacing it with concrete communication types (email, pop-up, mobile) made the system immediately more usable and adoptable.

Standardization is a design problem

I initially thought of alert intake as a technical integration challenge. It was, but it was also a design challenge. Creating a consistent process that could accommodate Qlik, Spotfire, PowerBI, and custom applications required as much design thinking as the UI itself.

Pilots give you real signal

Launching a pilot before building the full feature set forced us to prioritize ruthlessly and learn from actual production usage. The insights from Phase 1 made Phase 2 decisions far more grounded than stakeholder opinions alone would have provided.

Mobile isn't an afterthought

I learned this the hard way. Initially treating mobile as a secondary concern, then redesigning when stakeholders made clear its importance. The better lesson: design for mobile parity from the start. Operations managers needed alerts anywhere, not just at their desk.

Next project

Enterprise Supply Chain Solution →