Case Study · Toddle · 2023–2025
Context
Toddle's notification system spanned three channels, three platforms, 285 notification types, and four user types. This wasn't a single feature — it was a multi-phase, multi-year initiative that started as a bug-fix exercise and became a fundamental redesign of how the platform communicates.
I was the sole design lead across all six phases — problem framing, competitive research, copy framework, IA, component design, settings UX, and coordination with 14 module-owning engineers.
45-day observed window
of 9.93M notifications — unread
The Problem
01
The notification bell was only accessible from the homepage. Working deep inside a module — reviewing submissions, planning a unit — teachers had no way to know a notification had arrived. A structural flaw, not a UI flaw.
02
Clicking a notification could take 8+ seconds. The system loaded all class data, then all unit data, then the specific item — before redirecting. This created learned behaviour: don't click notifications because it breaks your flow.
03
100+ notification types, 24 modules, no prioritisation, no grouping. Every notification in the same flat list. A teacher managing 8 classes could receive 50+ a day, most low-signal. Desensitisation was inevitable.
04
Written by whoever built each feature. Some used ALL CAPS module names. Others had grammatical errors in production — "sent you a audio" — that had never been fixed.
05
In-app, email, and push existed with incomplete configurations and no logical relationship between channels. No way to say "push for urgent, email for updates." Effectively all or nothing.
06
Schools had no ability to control what notifications their students and families received. Admins had no notification access at all.
"The 83% wasn't a panel problem. It was a discoverability and trust problem. Users weren't reaching the panel — and when they did, the redirect failure had taught them not to engage."
Key Decisions
An earlier option was a floating "Magic Tray." I built its full interaction model and QA list before concluding it created growing z-index debt across every module. The global header was always the right answer. Moving the bell to a persistent header visible on every page resolved the discoverability failure permanently.
Most systems use two states. Seen ≠ Read. Scrolling past a notification doesn't process it. The Unread tab is a work queue that only empties through explicit action. Without this distinction, users scroll the panel, everything marks as read passively, and triage value disappears within weeks.
I explored seven tab structures. The final four was the only approach that simultaneously solved the announcement IA problem, gave a triage mechanism (Unread as work queue), a priority filter (Important), and surfaced direct-address events (Mentions). All = history. Important = can't miss. Unread = still need to process. Mentions = being pulled in.
Hierarchy: System mandatory → Admin default → User preference. Admin OFF cannot be overridden. Schools like Strathcona-Tweedsmuir and Durham Academy specifically requested the ability to enforce notification-off states — not just set defaults. An advisory model doesn't work when the obligation is institutional.
The redirect latency was an architecture problem, not a caching one. The system loaded entire entity trees before navigating. The fix: direct hyperlinks to specific entities, bypassing the load chain. Target: sub-1-second. This single change did more for click-through than any UX or copy improvement could have.
What I Learned