El caso de las notificaciones de Taringa! Shouts

Edit 2021: Esto fue redactado en 2015, antes de que Android tenga un sistema para controlar notificaciones. Afrontamos el desafío de crear un sistema de notificaciones útil y atractivo para los usuarios de Taringa! Shouts.

Generalmente, asumimos que al usuario le va a encantar recibir notificaciones. Suponemos que en su teléfono tiene sólo nuestra aplicación instalada, y nos dejamos seducir por la idea de que cuando el usuario vea una y otra vez esos mensajes melosos e insistentes, se va a entusiasmar y, fiel y emocionado, va a regresar a nuestra app.

La verdad es que no, para nada. Lo más probable es que nuestro usuario tenga tantas apps enviándole notificaciones, que su celular seguro parece Reddit después de un nuevo capítulo de Doctor Who. Lo que menos va a querer este usuario es que su teléfono lo esté interrumpiendo a cada rato, y seguramente desactive las notificaciones o, incluso, desinstale aquellas apps que lo molestan constantemente.

Frente a esta situación, varios diseñadores postulan que las notificaciones son, en realidad, una mala práctica. Algunos incluso llegan a plantearlas como un patrón anti-UX.

¿Qué hacemos, entonces? ¿Eliminamos las notificaciones?

No, tampoco hace falta ser tan extremos. Las notificaciones son de hecho una herramienta muy útil. Ayudan a generar engagement y permiten que los usuarios se mantengan informados sobre las actividades y eventos de nuestra app. Lo importante aquí no es lograr únicamente que las notificaciones no molesten a los usuarios, sino encontrar la manera de que realmente les sean funcionales.

Cuando desarrollamos la aplicación de Taringa! Shouts y su sistema de notificaciones, sabíamos que sería un gran desafío, dado que se trataba de una red social con millones de usuarios y numerosos tipos de acciones: likes, reshouts, comentarios, respuestas, seguidores… y la cuenta sigue.

También sabíamos que diseñar las notificaciones de una app no significaba simplemente seguir los guidelines de Material Design o de developers para Android. Debíamos lograr que más allá de funcionar como una fuente de información y de engagement, las notificaciones fueran un instrumento realmente útil para los usuarios -y para el cliente-.

Entonces, ¿cómo logramos que el usuario quiera y le guste recibir notificaciones?

Lo primero que hicimos fue tomar papel y lápiz y hacernos muchas preguntas. Teníamos que ser diseñadores con la curiosidad de un niño de cuatro años. Nuestra tarea era preguntarnos ¿Qué? y ¿Por qué? todo el tiempo, sobre todo.

¿Por qué querría una persona recibir notificaciones? ¿Qué pasa si el usuario usa mucho la app? ¿Y si la usa poco? ¿Qué tipo de notificaciones va a recibir? ¿Qué tipo de información le brindan éstas? ¿Cuántos tipos de notificaciones va a haber y por qué?

Las preguntas nos ayudaron a delimitar las variables que le darían forma a nuestro sistema de notificaciones. Al mismo tiempo, nos permitieron clasificar los tipos de notificaciones en informativas y accionables, y definir las categorías de usuario según su nivel de participación en la comunidad: heavy users, regular users y zombie users.

Una vez delineadas las variables, continuamos con más preguntas y más papel. Armamos user stories para las notificaciones, nos metimos en la piel de cada tipo de usuario y nos propusimos determinar qué grado de importancia le daba cada uno de ellos a cada tipo de notificación.

Taringa! tiene un gran porcentaje de heavy users que participa mucho en la comunidad posteando contenido y comentando las publicaciones. Este tipo de usuarios recibe cientos de notificaciones todos los días, por lo que probablemente le interese más enterarse de las actividades sobre las que puede realizar una acción (responder, comentar), que sobre aquellas que simplemente son informativas (likes, re-shouts).

Ahora bien, ¿cómo hacemos para explotar esta diferenciación y que, al mismo tiempo, le sea útil a los usuarios con menor actividad?

Acá es donde descubrimos que el tiempo juega un papel fundamental. Si al usuario le molesta recibir notificaciones constantemente, entonces el tiempo es la clave.

Podíamos usar el tiempo para controlar la cantidad y la frecuencia de las notificaciones que les llegaban a los usuarios. De hecho, la frecuencia era la herramienta que nos permitía determinar cuántas notificaciones recibía el usuario.

Decidimos que si en un determinado lapso de tiempo el usuario recibía dos o más notificaciones, entonces éstas podrían condensarse en un solo mensaje. De esta manera, las notificaciones informativas serían menos frecuentes para los heavy users, mientras que para los usuarios regulares y los zombie users llegarían con la frecuencia real, generando en ambos casos el engagement deseado.

Por otra parte, resolvimos que las notificaciones accionables, es decir, aquellas que conllevan una acción directa, tendrían una frecuencia real time para todos los usuarios, fomentando así la participación en la comunidad.

Teníamos una nueva hipótesis, una que había surgido del papel y de nuestras mentes curiosas. La pregunta que debíamos responder ya no apuntaba a si las notificaciones eran buenas o malas, sino a cómo podíamos estructurarlas para que le sean realmente útiles a los usuarios. La frecuencia era, entonces, nuestra respuesta.