Creating a notifications system for Taringa! Shouts

We faced the challenge of making the Taringa! Shouts notifications system a useful and engaging tool for users

In general, we assume that users will love to receive notifications. We suppose that the only app they have installed in their phones is our own, so we are seduced by the idea that once the users have seen those sugary, persistent messages over and over again, they’ll get excited and come back to our app —all frenzied and loyal.

Truth is, they don’t. Most likely, users have so many apps sending them notifications that their cellphones look like Reddit after a new episode of Doctor Who. The thing they’ll want the least is their cellphones constantly interrupting, so it’s only logical that they turn off notifications or even uninstall those apps that are annoying them all the time.

Faced with this situation, a number of designers believe that notifications are actually a bad practice. Some even consider them an anti-UX pattern.


What should we do then? Should we wipe out notifications?

Nope. There’s no need to escalate that much. Notifications are in fact a very useful tool. They help to generate engagement and keep users updated about our apps’ activities and events. The important thing here isn’t only about not bothering our users with notifications, but also nutting out a functional solution.

When we developed Taringa! Shouts app and its notifications system, we knew it would be a big challenge: it’s a social network with millions of users and many types of actions: likes, reshouts, comments, answers, followers… and the list goes on.

We also knew that designing the notifications of an app didn’t just mean following Material Design or Android developers guidelines. In addition to being a source of information and engagement, we needed notifications to be a really useful tool for users —and for the client.

What should we do to get users to want notifications and like receiving them?

The first thing we did was grab a pencil and a sheet of paper and jot down lots of questions. We needed to be designers with the curiosity of a 4-year-old child. Above all, our task was asking ourselves what and why all the time.

Why would anyone want to receive notifications? What happens if they’re heavy users? And if they’re light users? What kind of notifications will they receive? What kind of information do these provide? How many types of notifications will there be and why?


Questions helped us define the variables that would give shape to our notifications system. At the same time, they contributed to classifying the types of notifications —informative and actionable— and defining user categories according to their level of participation in the community: heavy users, regular users and zombie users.

Once the variables were outlined, we kept asking more questions and using more paper. We put together user stories for notifications: we got into the skin of every type of user in order to establish what degree of importance each of them gave to each type of notification.

Taringa! Shouts holds a large percentage of heavy users who participate a lot in the community by posting content and commenting. This type of users receive hundreds of notifications every day, so it’s more likely that they’re interested in getting information about the activities in which they can perform an action (answers, comments), rather than those that are simply informative (likes, reshouts).


Now, what can we do to capitalize on that differentiation and, at the same time, make it useful for those users who don’t participate as much?

This is where we found out that time plays a critical role. If users are annoyed because they continually receive notifications, then time is the key.

We we were able to use time to check both the quantity and frequency of the notifications that reached our users. And, in fact, we used frequency as a tool to establish how many notifications users did receive.

On the one hand, we resolved that if a user received two or more notifications within a given span of time, then these could be put together in one message. By doing this, informative notifications would be less frequent for heavy users, while the standard frequency would be used for regular and zombie users, which would still generate the desired engagement.

On the other hand, we decided that actionable notifications (i.e. those that entail a direct action) would have a real-time frequency for all users, therefore stimulating participation in the community.

We had a new hypothesis, which had arisen from paper and our curious minds. The question we needed to answer wasf no longer whether notifications were good or bad, but how we could structure them so that they could be really useful to our users. Frequency was then our answer