Case Study — Trialbuzz, diseñando un gestor de suscripciones
Una alternativa sencilla, completa y segura para sacar todo el partido a tus suscripciones sin pagar de más.
Proyecto personal grupal
Rol: Diseñador UX/UI
Duración del proyecto: 6 semanas a tiempo parcial
Es difícil imaginar nuestras vidas sin suscripciones a servicios digitales (como Netflix, Spotify, Sketch, Notion…). Nos encanta descubrir y probar herramientas nuevas; nunca sabes cuándo una app puede marcar un antes y un después en algún aspecto de tu vida.
Pero, en esta era de las suscripciones, es difícil tener todos los cabos atados, saber cuándo caduca cada periodo de prueba o cuánto gastas en total. No será la primera vez que nos llevamos una desagradable sorpresa con una suscripción que se nos olvidó cancelar.
Con este problema en mente, mi compañera Daria y yo comenzamos a planear los pasos que nos llevarían a diseñar un producto digital que ayude a cancelar las suscripciones antes del próximo cobro.
Research
Comenzamos poniendo sobre la mesa todos los datos que encontramos sobre el uso de suscripciones en España y en Europa.
Olvidarse de cancelar la suscripción es un problema tan común que no tiene sentido echarse la culpa por no haberla apuntado en los recordatorios del móvil. Sencillamente, el mundo necesita herramientas que hagan esta tarea más fácil.
Lo primero que debemos hacer es comprobar si los usuarios realmente tienen problemas para gestionar sus suscripciones. Necesitamos validar nuestra idea, determinar nuestra propuesta de valor y anotar qué más podemos ofrecer.
Para ello, llevamos a cabo una encuesta a 56 usuarios digitales de entre 22 y 50 años, de la que obtuvimos, entre otros, los siguientes resultados:
El 75% se ha olvidado alguna vez de cancelar una suscripción.
El 59% no utiliza ninguna herramienta para recordar sus suscripciones.
El 77% no conoce ningún producto digital para gestionar las suscripciones
Al 84% le gustaría poder cancelar sus suscripciones de manera automática
Esta encuesta también nos sirvió para comenzar tantear el modelo de negocio y las funcionalidades complementarias. Sin embargo, debíamos profundizar más y conocer de manera cualitativa las necesidades de nuestros potenciales usuarios.
Entrevistas
Realizamos entrevistas a 6 usuarios digitales de diferentes perfiles. Principalmente, encontramos una clara división entre quienes se dedican a sectores relacionados con lo digital (como un programador o un diseñador gráfico) frente a quienes trabajan en otras áreas.
Mientras que los primeros tenían un elevado número de suscripciones que necesitaban organizar, los segundos contaban con muchas menos (alrededor de 5), de modo que la funcionalidad principal de Trialbuzz se les quedaba corta.
En general, las entrevistas nos ayudaron a acotar los problemas de los usuarios y plantear unas soluciones hipotéticas:
- Cancelación automática de las suscripciones.
- Sincronización con email.
- Notificaciones personalizadas.
- Alternativas más económicas a suscripciones que ya tienen (cross selling).
- Balance de gastos y ahorro.
- Tiempo de uso de cada app.
Empatizando con los usuarios
Para concretar aún más las necesidades de nuestros usuarios, necesitábamos ponernos en su lugar, conocer sus bloqueos y sus expectativas de nuestro producto. Elegimos el Value Proposition Canvas como herramienta para comenzar a adentrarnos en la mente de nuestros users. Esto nos sirvió para validar la propuesta de valor y saber en qué aspectos del producto debíamos hacer hincapié.
En este punto de la investigación ya teníamos bastante claro que nuestro producto sería una app para móvil. Un servicio como este requiere notificaciones personalizadas en cualquier momento y en cualquier lugar. Además, la idea del cross selling tiene más sentido si podemos enviar al usuario directamente a la App Store o a Google Play para que se suscriba a los servicios que Trialbuzz les sugiere (idealmente, servicios patrocinados 🤑).
A continuación, definimos 3 buyer personas, es decir, arquetipos de usuarios ficticios de Trialbuzz, e indagamos en sus comportamientos y necesidades. Cada uno de los buyer personas representa a usuarios en situaciones muy diferentes.
Por ejemplo, Sandra (“la centennial fotogénica”) quiere probar aplicaciones nuevas de edición de imágenes y estar al día de las apps que van saliendo al mercado, pero tiene miedo de que le cobren al finalizar sus periodos de prueba. A Maricarmen, por su parte, lo que no le deja dormir son los gastos y la desorganización, ya que está suscrita a un gran número de suscripciones tanto para ocio como para su trabajo como profesora.
El siguiente paso fue conocer un poco más el entorno de nuestros usuarios, sus bloqueos y los posibles resultados que ofrecería nuestro producto. Para ello, desarrollamos un Mapa de Empatía para cada uno de nuestros user personas.
Para terminar esta parte de la investigación, nos adentramos en los User Journeys de Sandra, Maricarmen y Franklin, nuestros user personas.
El user journey es el camino que realizaría cada usuario dentro de nuestra aplicación. Gracias a esta herramienta pudimos ver los bloqueos específicos que necesitábamos resolver.
Por ejemplo, Sandra, (“la centennial fotogénica”) ha sincronizado sus suscripciones con Trialbuzz a través de su cuenta de correo, pero se ha dado cuenta de que no están todas, ya que tiene algunas en otro email o bien necesitaría añadirlas a mano.
Ante este problema, planteamos diferentes soluciones, como la sincronización con más de un email, sugerencias de aplicaciones o la posibilidad de seleccionar qué suscripciones quieres que se sincronicen.
Mediante el desarrollo de los user journeys planteamos una respuesta para cada uno de los puntos problemáticos de nuestro PMV, desde el proceso de Onboarding hasta la personalización de las notificaciones, pasando por el sistema de sugerencias y cross selling.
Antes de pasar a la arquitectura, hicimos acopio de las conclusiones extraídas durante la etapa de Research y las organizamos mediante un Affinity Diagram para planificar de manera más clara el desarrollo del proyecto.
Lo que al principio parecía un producto muy sencillo, donde añades suscripciones y eliges cuándo quieres que se te notifique, había crecido exponencialmente. La funcionalidad principal seguía siendo la misma, pero ahora conocíamos los escenarios y los problemas que un usuario puede encontrar en cada proceso, desde la categorización de las suscripciones hasta los ajustes, y teníamos respuestas para cada uno de ellos.
Por último, hicimos un resumen de las principales conclusiones de la investigación y nos preparamos para saltar a la siguiente fase.
Arquitectura de la información
Llegados a este punto, tenemos bastante definido qué va a ofrecer este gestor de suscripciones; es el momento de entrar más en detalle en la estructura de nuestra aplicación.
Comenzamos definiendo el sitemap de Trialbuzz, es decir, el esqueleto del producto. Va a estar dividido en tres secciones principales: Mis suscripciones, donde puedes añadir y quitar suscripciones, cancelarlas y gestionar las notificaciones. Además, cuenta con una vista de calendario para un mejor control de los cobros.
Por otro lado, estaría la sección de Estadísticas, con la funcionalidad de control de gastos por categorías y tiempo de uso de cada herramienta o aplicación. Y, por último, la sección Explorar nos permite buscar nuevas suscripciones con o sin periodo de prueba.
A continuación validamos el sitemap mediante un TreeTest, donde preguntamos a tres usuarios que localizaran diferentes secciones de la app. Gracias al testing pudimos pulir algunos detalles de nuestro sitemap.
Ya estábamos más cerca de nuestra parte favorita del proyecto: ¡dibujar pantallas! ¿Pero cuántas pantallas tenemos que dibujar? ¿Cuántas interacciones realiza el usuario?
Los userflows nos permiten ven con mayor detalle las diferentes interacciones que realizan nuestros user personas para conseguir sus objetivos a través de nuestra app.
Una vez determinados los diferentes pasos necesarios para completar acciones como la sincronización con email, el añadido manual de suscripciones o la personalización de notificaciones, cogemos rotulador y papel y nos remangamos para hacer los primeros bocetos de Trialbuzz.
Wireframes
¡A dibujar! Pero no sin antes empaparnos de referencias tanto de aplicaciones para gestionar suscripciones, como Truebill y Bobby, como de apps bancarias, app markets y productos digitales de todo tipo. El objetivo es encontrar la mejor solución para cada una de las interacciones de debe realizar el usuario… y esa solución puede estar en cualquier lugar.
Tras unos primeros bocetos, pasamos a desarrollar los wireframes de alta fidelidad, que nos permitirá hacer test con los usuarios.
Seguidamente probamos estos wireframes, ya en forma de prototipo interactivo, con cuatro usuarios de diferente perfil, a quienes pedimos completar dos tareas:
- Sincronizar su correo con la aplicación y elegir las suscripciones que quiere añadir.
- Buscar y añadir manualmente una suscripción, personalizando la ficha (precio, frecuencia de pago, recordatorios…).
Gracias a los test, detectamos algunos bloqueos, especialmente en el proceso de sincronización. Por ejemplo, los usuarios no se sentían cómodos introduciendo la contraseña de sus correos. Necesitábamos reforzar aún más la sensación de seguridad.
Otro ejemplo lo encontramos en la pantalla que nos indica las suscripciones detectadas. Los usuarios eliminaban una de las suscripciones, pero luego no podían recuperarla a menos que cerraran la ventana modal y volvieran a repetir el proceso.
Para resolverlo, cambiamos la cruz de la derecha por una checklist que aparece marcada por defecto. Resulta más intuitivo desmarcar las suscripciones que no quieres añadir.
Visual
Nervios. Nos sentíamos como una madre a punto de coger a su bebé en brazos por primera vez. Pero diseñar la parte visual de la aplicación no era tarea fácil. Por suerte, ya teníamos un nombre, Trialbuzz, y nos habíamos empapado de cientos de referencias, también a nivel de UI.
Queríamos que la aplicación fuera accesible, con un toque desenfadado y divertido, alejándose de la estética típica de un producto de gestión de gastos.
La palabra “buzz” (zumbido en inglés) nos inspiró a jugar con el concepto de las abejas. El amarillo era una decisión obvia; el morado, casi que vino solo. Pero funcionaban. Diseñamos el logo, el icono de la abeja en forma de campana, la mascota y una muestra de la dirección visual de la app.
“Solo” nos queda darle color a nuestra interfaz, pulir detalles, contar muchos píxeles de ocho en ocho y… tras seis semanas de trabajo a tiempo parcial, terminamos el diseño de nuestro Producto Mínimo Viable.
Solo un comienzo
Como todo producto digital, Trialbuzz es un proyecto continuo, itinerante, donde queda mucho por hacer. Gracias al proceso de diseño de esta aplicación, he aprendido a meterme más en la piel de los usuarios y a tener en cuenta cada feedback, cada gesto, cada clic en el botón incorrecto para mejorar continuamente el producto.
Por último, quiero agradecer a mis profesores de Elastic Heads, Óscar, Samuel, Anaís y Fede, a mi compañera en este proyecto, Daria, y a todos los que nos han prestado su tiempo para participar en las encuestas, entrevistas y test. ¡Gracias por vuestra ayuda y paciencia!
