Notifications — The good, the bad and the irrelevant
Thoughts about what people like getting as notifications, and what not.
When it comes to notifications, people (including me), are really picky. We don’t want to see too many notifications cluttering our most precious real-estate, the one that controls our attention span, our beloved Notification Center.
Thing is, I believe that with the right execution notification platforms can actually reduce the amount of notifications we get. If, as notification platforms, we follow strict guidelines into what is a good notification and what is a bad one, users can trust we deliver a better stream of notification than stand-alone apps.
Facebook’s new app, Notify, is out and offers an array of stations, that users can turn on and receive notifications from.
While working on our own notifications app Yo, we’ve discovered and defined basic guidelines into what people are interested in getting as notifications versus what they don’t versus what they think they want — but actually don’t. People may think they want something, but their measured actions may tell a different story.
In our app, Yo, users receive notifications from either real people — i.e their friends, or from publishers. In this post I would like to focus on notifications from publishers.
Notifications from publishers can be very useful or they can be annoying. There are only 2 properties a notification needs in order to be good:
- Contextual
- Time-sensitive
They answer these 2 questions:
- Contextual — Why did I get this notification?
- Time-sensitive — Why did I get this notification now?
If the answers to these question are clear within the split second that we got the notification, we immediately get the value. Otherwise we start wasting brain cycles to determine if we should open it or not and that’s where it starts to get annoying.
Context:
If users subscribe to a specific trigger, when they get a notification that the event has triggered — they immediately know why they got it. The more specific the triggers a platform suggests, the better. If a user subscribes to a very broad subject, for example — a specific brand, they get all sorts of notifications from that brand — whether it’s a random article, or an important news update, it all has the same weight. In email this problem has been solved by all kinds of priority filters, in push — not yet. Therefore it’s best to provide a way for users to easily select what they are actually interested in within a broad subject.
If we don’t understand why we got it, or even why we got it now, these notifications are annoying and even if not after the first few ones, later on we consider them annoying, then spammy, and then we rush to search for the unsubscribe button. If we can’t find that easily, we either disable notification access for the whole app, or use the doomsday weapon and uninstall the app.
Time-sensitivity:
A notifications is good if it’s time-sensitive. That by itself rules out every notification that can be scheduled before hand. In our publishers dashboard we used to have a “Schedule a Yo” feature. We’ve removed it when we realized that people don’t open these Yos.
A piece of content that comes every day at the same time have already been invented and has a name. It’s called a “Newsletter” and we found that news letters belong in email, not as a notification.
If the answers to the user’s question “why did I get it now?” is “because this is a cool article and we thought you should read it. NOW!”, that’s not really time-sensitive and maybe should be tweeted rather than pushed.
Here are some examples of what we consider good notifications:
- Favorite soccer team scored a goal just now.
- A startup got acquired just now.
- Marc Andreessen just started a tweetstorm
The more notifications we are going to get, the more picky we will be in which apps get access to our beloved notification center. The notification center slowly becomes our desktop and platform developers must become diligent in what exists there and what can exist inside folders (standalone apps).
