Campaign Notifications

_YEAR
2026
_{PROJECT TEAM}1 designer
1 product manager
1 engineer

_{RESPONSIBILITY}
User Interviews
Competitive Research
End-to-End User Flows
Information Architecture
Wireframing & Prototyping
Engineering Handoff
QA

IDP Campaigns is designed to drive organizational improvements through time-bound initiatives, such as migrations and dependency fixes, by identifying gaps and prompting teams to take action.

However, driving completion requires more than surfacing issues. Teams need clear prioritization, actionable guidance, and effective nudges to act.

Discovery

I looked at the campaign owner’s workflow from launch through completion. Their role didn’t end after notifying teams. They needed to monitor progress, provide guidance, and follow up on unfinished work throughout the campaign.

Mapping this journey revealed three distinct communication needs: getting teams started, guiding them along the way, and following up on unfinished work.

At launch, teams need to understand the campaign’s purpose and their responsibilities. As work progresses, they need guidance and reminders. As the deadline approaches, owners need to follow up with teams that still have work remaining.

This made it clear that improving a one-time notification modal wouldn’t be enough. We needed to support communication throughout the campaign, with different types of outreach for each stage.

Existing limitations

The existing notification experience was mainly designed to get a campaign started. What was missing was support for keeping the work moving and helping teams reach completion.

Three key limitations stood out:

1. Manual communication
Notifications were limited to a one-time, fixed message, leaving campaign owners to handle follow-ups manually.

2. Lack of visibility
There was no central place to review notification history or past conversations, making it difficult to know which teams had been contacted and what had already been discussed.

3. Limited actionability
Notifications shared campaign information, but didn’t make it clear what teams needed to do next.

“Everything is automated except communication. The only manual work remaining is sending messages,  nudging teams, and following up.”

SE2, Frontend Framework at Datadog

Opportunities

Based on these findings, I saw an opportunity to move from one-off, manual notifications to automated communication throughout the campaign, while giving owners more visibility and control over their outreach.

I focused the experience on two areas:

1. Notification configuration
Owners could decide when and where to send notifications, customize the message, and automate follow-ups based on triggers.

2. Tracking and management
Owners could monitor communication activity, review team-level history, and adjust their outreach as the campaign progressed.

Workflow mapping

Before designing the screens, I mapped the end-to-end notification experience, from initial setup to ongoing management.

The setup flow moves from choosing the notification type and trigger to selecting destinations, creating the message, and reviewing the configuration before launch. I explored different options at each step, including one-time and recurring notifications, scheduled and condition-based triggers, team-specific destinations, and customizable messages.

The flow then continues into ongoing management. Owners can review all notifications, drill into configuration and send history, see communication activity for individual teams, and take follow-up actions such as sending another message, editing the notification, or pausing it.

This helped me think beyond notification creation and design for the full communication lifecycle of a campaign.

Using the flows as a starting point, I used AI to quickly explore and compare different approaches to notification setup and management.

Setup exploration

_{TEMPLATE-LED CONFIGURATION}

I first explored a template-based approach to notification setup. Users would choose between a one-time or recurring notification, then select a template based on their needs. Depending on the template, notifications could be sent immediately, on a schedule, or when a specific condition was met.

^{︎︎︎ Template-led notification configuration prototype}

This approach could simplify complex notification setups by providing common patterns to start from. However, it also introduced unnecessary complexity for simpler tasks. Users had to understand the differences between templates before getting started, and even sending a single message required an additional selection step.

_{STEP-BY-STEP CONFIGURATION}

The second approach guided users through the setup one step at a time. Instead of choosing a template, users could turn different notification types on or off, then configure each one through a guided flow.

^{︎︎︎ Step-by-step notification configuration prototype}

Breaking the setup into smaller steps reduced the number of decisions users had to make at once, making complex configurations easier to work through. The tradeoff was reduced visibility, as users couldn’t see the full setup at a glance and had to move back and forth between steps to review or change their choices.

Tracking & management exploration

_{MODAL-BASED MANAGEMENT}

The first approach I explored for notification tracking and management was a separate modal. The existing “Create notification” button would become “Manage notifications,” giving owners one place to view notifications, review send history and team responses, and create new notifications.

^{︎︎︎ Modal-based notification management prototype}

This kept creation and management together without adding clutter to the campaign page as the number of notifications increased. The tradeoff was reduced visibility and context. Owners had to open the modal to check notification activity, making it harder to see communication alongside campaign progress.

_{EMBEDDED MANAGEMENT}

The second approach brought notification management directly into the campaign page, making the notification list visible without requiring owners to open a separate view.

Selecting a notification opened a side panel with its details and history. From there, owners could drill into team-level communication in a second panel to review messages and responses.

^{︎︎︎ Embedded notification management prototype}

This made it easier to view notification activity alongside campaign progress and keep communication in context. The tradeoff was scalability, as a growing number of notifications could make the campaign page longer and more crowded.

Execution

After reviewing the different approaches and their tradeoffs with the team, we aligned on a direction that balanced flexibility, visibility, and implementation scope.

_{CONFIGURATION}

We kept the full notification setup in a single view, allowing owners to turn each notification type on or off. They could send a one-time launch message or combine it with automated progress updates and a due-date reminder. This gave owners flexibility without requiring them to learn a template system, while making the overall configuration easier to review and edit.

For the MVP, we focused on schedule-based notifications and left condition-based triggers for future iterations. This reduced implementation scope while still supporting the core communication needs we had identified.

_{TRACKING & MANAGEMENT}

We embedded notification management directly into the campaign detail page so owners could review communication alongside campaign progress. Based on the expected number of notifications per campaign, we determined that the added content was unlikely to overwhelm the page.

Side panels provided deeper access to each notification’s configuration, send history, and team-level communication. Owners could also edit or stop upcoming notifications independently as the campaign progressed.

I initially grouped notification types into one setup flow because they formed a single communication plan. The engineer favored separate configuration because each type had a different lifecycle and editing behavior. We kept setup together, but listed and edited each notification type independently, preserving a simple setup while making the scope of each edit clear.

What I learned

Through this project, I learned a few lessons that changed how I think about automation, communication, and collaboration.

Automation should feel  predictable

Users need to understand what will  be sent, when it will be sent, and who  will receive it.

Design for both senders  and recipients

Campaign owners configure notifications,  but developers experience their frequency, clarity, timing, and relevance. We designed reminders to stop once a team completed the work.

Design and engineering can be right at different layers

Different design and engineering perspectives led to a solution that better served both users and the system.

← Previous project

All work

Next project →

Related work

Eunmo Kang