filtered-cover.png

Notification browser

Internal-facing notifications view

Transactional notifications are a critical part of how sitters and owners interact with Rover. Our internal tool to keep track of these notifications is about as good as a spreadsheet. You can only see the names of notifications and their corresponding campaign names.

 

“before”

 

In almost every project that Product Designers and PMs work on, understanding and updating transactional notifications is required. In order to understand them and update them I would have to test notifications in production to find out what a customer would see based on a given trigger.

There were many more updates to the Notification Browser that could be made to make the lives of designers and PMs easier and remove the reliance on testing in prod. These were the most common pain points we uncovered.

  1. I want to know what triggers a given notification

  2. I want to know if there are notification that fire at the same time or are related (e.g sent to both sitter and owner)

  3. I need to update a notification and I need to know what existing data is passed through so I can either use that data or add missing data

  4. I need to see all the kinds of notifications sent on a given channel (e.g. sms)

During Rover’s first hackathon, myself, 2 devs and a PM were able to accomplish the following 👇

 
 
all-list@2x.png
 
 

Users (PMs & designers) are either searching by notification name or campaign name (if there is a corresponding email) so showing both was necessary. The tags show needed context for a given notification, and icons are shows when the notification is delivered on that channel.

Tags themselves are clickable and when clicked will filter the list view to show only notifications with that tag.

card-callout@2x.png
 
filtered.png
 
 
tag ixd.png
It didn’t take too long at all really…

It didn’t take too long at all really…

Tagging system

The tag taxonomy was created wholly by me. I opened each of the 141 notifications to understand when they were triggered and what they were related to. I created a bucketing system that consisted of:

  • Product areas (e.g. reviews & tipping, sitter sign up aka ssu)

  • Features (e.g. background checks, grooming service, recurring bookings)

  • Events (e.g. booking events, messaging events)

  • Event types (e.g. booking modifications, cancellations)

  • Receiver (e.g. owner, provider, both)

With this taxonomy, all notifications had at least one tag (with the exception of a few marketing ones) and critical notifications with lots of overlap ended up with 11 tags at most.

 

Notif. details page

Clicking into a notification reveals the details page. This contains:

  1. Free text description of the notification that shows the information, triggers, timing and exceptions

  2. Channels” section which contains configurable fields to customize the notification preview on each channel.

  3. The preview of the notification on all corresponding channels: SMS, push, and email.

  4. Related notifications - relation being based on number of 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.

 

After shipping the changes we surveyed the employees who had used the Notification Browser the most. The feedback was resoundingly positive. Based on my past projects I calculated this tool would have saved me 20 hours of manual verification and documentation.

 

Editing Notifications

future ideas.png

Once a user knows everything about a notification, the next thing they’d want to do is edit them. Since Rover had very little tracking of their transactional notifications over the years many duplicates have cropped up, or old notifications not being updated with the latest data we have. Various members of the design team including myself had plans on how to make these notifications better by tweaking the copy. But what if we could do those without requiring a developer? The edit experience is designed to give just enough control around the templates of the notifications while not being too complex. It won’t change the logic like the timing or the triggers, but if we want to rework the templates its as easy as using a text editor with a few available variables.