Notification System Redesign
Context
The product is a SaaS platform used by independent music teachers, tutors, and studio owners to manage their entire business; scheduling, billing, student records, and communications. For most of these users, missing a system update isn't just an inconvenience. A missed payment alert or a cancelled lesson notification can have a real impact on how they run their day
Everything looked the same, so nothing stood out
The notification experience was a small dropdown off the nav bell. Every notification landed in a flat list — scheduling updates, billing alerts, form submissions, policy flags — all with the same visual weight, no categories, no way to filter. The only action available was marking something as read.
For a solo teacher with a handful of students, it was manageable. For a studio owner handling 50 or more students, multiple teachers, and daily billing activity, it was overwhelming. Important things got buried and teachers were missing updates they genuinely needed to act on.
Support tickets kept surfacing the same complaint: "I didn't see that notification". That pattern told me this wasn't a one-off usability issue, it was structural.
The obvious fix would have been to clean up the UI and call it done. But I looked at where the product was heading. New features were in the pipeline, each generating their own notification types, and the system had no way to categorize, filter, or let users control what they received. If I only improved the visual design, we'd be back here in six months with twice the noise. The real problem was that we had a notification list, not a notification system.
Phase 1 — Make it usable
The first phase focused on what I could improve without any backend changes.
The dropdown became a side drawer, which gave the list more room and made it easier to scan without feeling cluttered. I added Unread and All tabs so teachers could focus on what needed attention without wading through their full notification history. Search came in for when someone needed to track down something specific. Relative timestamps replaced the raw date and time format, so recency was readable at a glance instead of requiring mental math.
All of this shipped as a self-contained improvement that immediately reduced the friction of day to day use.
Phase 2 — Building the system
Phase 2 is the structural layer. It's fully designed and ready to build, waiting on the backend tagging work that will make filtering possible.
Once notifications are tagged by type, the drawer gets a category filter bar that groups notifications by what they're about, scheduling, billing and payments, form submissions, and so on. Teachers can select multiple categories at once to narrow down to what matters in the moment. The filter state is visible and easy to clear, so there's no confusion about why something isn't showing up.
This is also where the system becomes future proof. Any new notification type the product introduces just needs a category tag — it slots into the existing structure without creating noise for users who don't need it.
Giving users control
The notification preferences panel is the other half of Phase 2. It lets users control which notification categories they receive and through which channel — in-app, email, or push notification.
This matters more than it might seem at first. The platform serves different types of users: solo teachers, studio admins, and staff teachers all have different roles and different information needs. A staff teacher doesn't need billing alerts. A studio owner might want payment notifications by email but attendance updates only in-app. The preferences panel makes that level of control possible without requiring any workaround.
Extending the filter pattern across the product
One thing that came out of this project was a better filtering pattern for the product overall. The old approach mixed filters in with search and action buttons, used single select dropdowns, and varied from page to page. It worked well enough in isolation but didn't scale as pages got more complex.
The notification drawer was the first place we tested a dedicated filter bar with multi select chips and a clear all option. The interaction tested well and the pattern is now the intended standard across the product, replacing the older approach wherever filtering exists. The calendar view was one of the first places it was applied after notifications.
Where things stand
Phase 1 is live. Teachers can find unread notifications faster and the drawer gives the system room to grow as notification volume increases.
Phase 2 is fully designed and scoped. When the backend tagging work ships, the filtering and preferences layer is ready to build with no design work left to do.
The bigger outcome is structural. The product now has a foundation that can absorb new notification types without creating noise, and users will have real control over what they see and how they're reached. That was the problem worth solving.
What I took away from this
The most useful thing I did on this project was resist the pressure to ship a complete solution immediately. The temptation was to wait until the backend could support filtering before releasing anything. Instead, breaking it into phases meant users got a real improvement right away, and the harder work got designed properly without being rushed.
I also learned to pay attention when support tickets cluster around the same complaint. One ticket about a missed notification is a user issue. A pattern of them is a design issue. That signal was what pushed me past the surface fix and toward rethinking the system.
What's coming
Phase 2 is the immediate next step (categories, filtering, and notification preferences) pending the backend tagging work. Once that ships, users will have full control over their notification experience for the first time.
Longer term, the preferences model opens the door to role based defaults, where new users get a sensible starting configuration based on their role rather than receiving everything at once. That's not scoped yet but it's a natural next step once the foundation is in place.
