Seamm · 2023

Push Notifications Manager

How to kill the send button nobody wanted to press.

Overview

Designed a push notification system that eliminated blind sending, gave marketing full autonomy, and increased campaign velocity 3.75×.

My role

Product Designer — UX, UI, design system

Team

Seamm product team

PM
Design Lead
2 Engineers
Product designer (Me 👋)

Impact

~30 min → 2 min creation time
3.75× campaign velocity

Campaign creation time

~30 min → 2 min

Campaign velocity

3.75×

Engineering time freed

15+ h/month

Before

Marketers

Slack message

Dev team codes

Wait

Send

After

Marketers

Visual composer

Send

01 · Context

Why we started

Every push notification required marketers to message the engineering team via Slack, wait for availability, then have a developer manually query the database and send. Engineers — whose time costs significantly more — were pulled from product work to handle routine marketing tasks. Marketers had no visibility into how notifications would appear on users’ devices, and with no preview or review step, a single typo could reach thousands of users instantly.

But unlike content that can be unpublished, push notifications are irreversible. Once sent, there’s no undo. A typo reaches 10,000 users instantly.

Three things made this a high-anxiety task:

01No visual preview — marketing couldn't see how the notification would look on a device before sending.
02Error-prone targeting — reaching specific users required external lists or manual IDs.
03No safety net — without a review step, the fear of a mistake going to thousands of users was paralyzing.

The goal

My goal: design an end-to-end flow that empowers non-technical admins to create, target, and send push notifications with confidence — and zero code.

Key insight

Push notifications sat at an expensive intersection: marketing couldn’t send without engineering, engineering had higher-priority work, and neither side had tools to prevent costly mistakes.

03 · Targeting

Who receives this?

Audience targeting was the trickiest interaction design problem. The default shows total addressable audience with an ‘Everyone’ button. Custom selection opens a modal for searching by username, email, or ID. The table displays metadata — registration date, last activity — so admins can verify they’re selecting the right users.

Screenshot: Audience targeting modal with user search and metadata table — The metadata table lets admins verify they're selecting the right users before sending.

I considered displaying filters directly on the main screen. But I chose a modal because 80% of campaigns target fewer than 50 users, simple search handles the majority of cases, and it keeps the main composer clean.

Design decision

80% of campaigns targeted fewer than 50 specific users — not complex segments needing multi-filter dashboards. A modal with search-by-name covers this in two clicks: open, search, select, done. The main composer stays uncluttered for the message itself, and the modal only appears when the admin actively chooses custom targeting.

Zero-state

If zero users are selected, the system shows a large visual indicator: ‘0 Users will receive your message.’ The send button stays disabled. This sounds obvious. But without it, it’s trivially easy to fire a campaign to nobody — or worse, to everyone by accident.

04 · Safety

The anxiety-free confirmation

This is the feature I’m most proud of. Before the final send, a dedicated review modal shows: a summary recapping the exact audience count (‘Send to 238 users’), one last look at the notification creative, and a clear CTA stating the action and scope — removing all ambiguity.

Screenshot: Confirmation modal — 'Send to 238 users' with preview — 'Send to 238 users' — no room for interpretation.

Key insight

The confirmation modal initially felt like it was slowing users down. It became the most-praised feature in the entire project. Users wanted confidence over speed.

05 · Results

Results & system design

100% layout accuracy

The preview removed guesswork completely. Zero 'broken' notifications reaching users post-launch.

3.75× campaign velocity

Creation time dropped from ~30 minutes to under 2 minutes. 15 campaigns in the first month, up from 4 average. The team started testing 3 messaging variants per feature launch.

Engineering freed

15+ hours/month redirected to core product features. No more 'Can you send this campaign?' Slack messages.

Key insight

The real win wasn’t faster notifications. It was redirecting engineering hours — which cost 3–5× more than marketing hours — back to product work.

Under the hood

The notification manager uses the Seamm Admin Design System I maintained — form inputs with validation states, button states, status indicators. A shared component library reduced development time and ensured UI consistency, so the team could focus on the harder, scarier parts of the workflow.

Screenshot: Shared component library and design tokens — Same components, same patterns, lower cognitive load.

06 · Lessons

What I learned

Self-service tools are anxiety products.

The primary user emotion isn't 'I want speed.' It's 'I'm terrified of a mistake reaching thousands.' The confirmation modal, live preview, and zero-state guard all address fear, not efficiency — and became the most praised features.

Design for the 80%, don't hide the 20%.

Most campaigns targeted a handful of users. A full filter system would have added complexity for everyone to serve rare cases. Modal targeting kept the default path fast without limiting power users.

Redirect expensive time, don't just save time.

The real win wasn't '30 min → 2 min.' It was freeing engineering hours that cost 3–5× more than marketing hours, and letting each team focus on what they do best.