Notification System

Designing Bynder's notification system from the ground up: email, in-app, throttling, smart subscriptions, internal tooling, and an automation integration that turned notifications into a revenue stream.

Overview

Bynder's notification system was so broken that some customers were facing lawsuits over unannounced asset archiving. Over 12 months I built the system from scratch: auditing and rebuilding what existed, launching v1 as email-only, shipping throttling and preferences, building internal tooling that let other teams migrate and build their own notifications, launching in-app with a smart auto-subscription model, and eventually integrating with automations to unlock a new revenue stream.

The Problem

Bynder had a notification system in name only. There was no proper UI, no grouping logic, no user control, and no distinction between who should receive what. Notifications for critical events, like assets being archived, were either missing entirely or buried in noise that no one was reading.

Support tickets and ProductBoard complaints pointed to the same four problems: notification overload with no way to filter, no targeting by role or context, no frequency control, and no route for teams with specific workflows to get the alerts they actually needed. The consequence was not just poor UX. Customers were going to court over assets disappearing without warning.

Existing notification event system audit

Audit and reduce

Before designing anything new, I mapped every existing notification in the system, what it triggered, who it went to, and whether it was still relevant. A significant number were outdated: product features had changed, workflows had evolved, and the notifications that remained were either firing for things nobody cared about or completely absent for things that mattered.

Removing the redundant ones first was as important as designing new ones. A notification system that starts clean has fewer edge cases, less engineering complexity, and a clearer mental model for users from day one. The audit also surfaced which categories mattered most, which shaped the v1 scope.

Email-first

Bynder's in-app notification experience was so poor that most users had stopped relying on it entirely. Email was the channel they actually used. Starting with email notifications meant delivering real value to the majority immediately, without waiting for the more complex in-app infrastructure to be ready.

V1 covered three categories: system notifications for critical platform events, asset notifications for uploads, comments, and status changes, and collection notifications for activity within shared collections. Each notification was written against a defined sentence structure: actor, action, object, context. Every existing notification was audited and rewritten to the same standard before anything went live.

Email notification system and guidelines

In-app and email notifications on mobile

Throttling and settings

After launching email notifications, a pattern emerged quickly in feedback: users in active portals were receiving too many notifications. A collection with dozens of contributors could generate hundreds of alerts in a single day. Without throttling, a well-intentioned notification system becomes the noise it was supposed to fix.

I designed a preferences centre that gave users control over notification type, delivery channel, and frequency. Admin-level controls let portal managers set defaults and restrict overrides for their teams. Throttling logic was built into the system itself: notifications were batched and grouped by resource so a busy collection produced a single daily digest rather than fifty individual emails.

Internal tooling and migration

Post-launch feedback came with a clear next request: other product teams wanted to add notifications for their own features. The problem was that every new notification required the core notification team to be involved, which did not scale.

I built an internal email builder and a comprehensive set of design and usage guidelines covering sentence structure, icon rules, grouping behaviour, throttling thresholds, and email templates. With this tooling, a designer on any team could build a visually correct, structurally consistent notification for their feature in hours without writing code and without involving the core team.

This made migration straightforward too. Teams with legacy notification logic could move into the new system independently, following the same guidelines that governed every other notification in Bynder. The result was full cross-team adoption without ongoing core team involvement.

In-app notifications

With email stable and other teams onboarded, I built the corresponding in-app notification system. The notification centre surfaces real-time alerts grouped by resource and ordered by recency. Each notification carries inline controls so users can manage subscriptions, mark items as read, or navigate to the relevant asset or collection without leaving their current context.

Both surfaces share the same underlying event model. A change to how an event is described updates both channels at once, preventing the drift that typically causes email and in-app systems to diverge in tone and content over time.

In-app notification system and guidelines

Notification system in light and dark mode

Smart subscriptions

Alongside in-app, I designed an auto-subscription model built around natural interaction patterns in the DAM. The core idea: interaction implies interest. When a user downloads an asset, they are automatically subscribed to activity on it. When someone creates a collection, they follow it from creation. When a user uploads assets, they are subscribed to comments and status changes on those files.

Subscriptions are created silently at the moment the relationship between a user and a resource is established, with no manual configuration required. Every automatic subscription respects the frequency rules set in the user's preferences, so following an active collection does not flood an inbox.

For users who want explicit control, manual follow is available from four points across the DAM.

Asset detail view

Follow directly from the asset detail page, subscribing to all activity on that asset.

Asset bank card

Follow from the asset card in the asset bank, or bulk-follow multiple assets at once from a selection.

Collections overview

Follow an entire collection from the overview, subscribing to all activity across every asset inside it.

Inside a collection

Follow individual assets from within a collection, giving fine-grained control without leaving the browsing context.

Integrations and AI

The final phase connected the notification system to Bynder's automation module. Customers with workflows too specific for a standard notification could now build fully custom alerts as the final step in any automation: triggered by the conditions they defined, sent to the recipients they specified, without engineering involvement.

AI was layered in to make notifications smarter rather than more frequent. Instead of separate alerts for every event on a busy asset, the system could produce a single contextual summary: what happened, who did it, and what it means for the recipient. Notifications became more informative and less interruptive at the same time.

Tying notifications to automations also turned the system into a revenue lever. Advanced notification and automation capabilities became part of the paid tier, creating a clear upsell path for customers who needed custom workflows at scale.

Notification system integration with automations

Outcomes

34New notifications shipped

ZeroMaintenance cost after replacing Courier

↑ NPSScore increased post-launch

6 → 12 moScope expanded due to customer response

Full adoptionCross-team, no core team involvement

RevenueUnlocked via automation integration

What I Learned

"A notification system is an infrastructure problem, not a UI problem"The visual design of a notification is the last 10% of the work. The first 90% is logic, who gets what, when, at what frequency, grouped how, triggered by what. Getting the logic right before designing the interface is what made the system coherent.

"Enabling other teams is part of the deliverable"Building the system was not enough. If other designers could not use it independently and consistently, the system would fragment within months. The guidelines and internal tooling were not documentation, they were the product.

"Replacing a third-party tool is a design decision as much as a technical one"The switch from Courier to an internal system required designing the tooling that non-engineers would use to build email notifications. That internal tool, which let designers build and ship email notifications without writing code, was one of the most impactful outcomes of the project, and it was not in the original brief.