The Challenge
Rover's internal notification management system was extremely basic. For product designers and PMs who regularly needed to validate, update, or test notifications, this meant testing in production to understand what customers would actually see.
Why it matters
Nearly every Rover project requires understanding or updating transactional notifications. Our current method of testing in prod lead to accidental requests sent to real customers (😱) and created a heavy burden on design and to document these cases manually. By addressing this tool we could streamline the product teams workflow and avoid causing unnecessary confusion with customers.
“before”
Key Pain Points
Using a quick survey to our entire product group, I uncovered the full set of pain points we needed to address:
Understand notification triggers
Identify related notifications
Access existing data parameters
View notifications by channel (SMS, email, push)
During Rover’s first hackathon, myself, 2 devs and a PM were able to accomplish the following 👇
Our improved interface featured:
Searchable notification and campaign names
Context-rich tags for filtering
Channel icons showing delivery methods
Clickable tags for quick filtering
Updated List item
Tagging System
I personally analyzed all 141 notifications to create a comprehensive taxonomy including:
Product areas (reviews, sitter signup)
Features (background checks, grooming)
Events (bookings, messaging)
Event types (modifications, cancellations)
Receivers (owner, provider, both)
This system ensured every notification had at least one tag, with complex notifications having up to 11 tags.
Details page
The notification details page provided:
Complete descriptions of triggers, timing and exceptions
Channel-specific configuration fields
Visual previews across all channels
Related notifications based on shared tags
Where previously most notification descriptions were blank, the new description field makes it easier for notification editors to know what content to write.
The channel configurations and templates were most helpful for designers who needed to see how notification copy varied across service types.
Editing Notifications
To streamline the edit process we created an in-page edit experience with a few key configurable elements. While we’ll still require a code change for timing or trigger events, this edit view would allow us to change the content of a notification, edit the tags, and create a description—the things PM and Design were most interested in.
Results
Once shipped, we surveyed the employees who had used the Notification Browser the most. Feedback was resoundingly positive. Based on all my past projects combined, I calculated this tool would have saved me ~20 hours of manual verification and documentation. Spread across an entire product team that’s nearly 2 weeks of time back.