CASE STUDY: Fullsharing · Registra fácilmente todos tus gastos compartidos
En la semana 4 del bootcamp llegó la hora de hacer nuestro primer proyecto individual (yay!) . La misión de los alumnos con este proyecto era encontrar un problem statement relacionado o bien con el mundo de las finanzas o bien con el mundo del wellness. A partir de nuestro problem statement, llevaríamos a cabo una investigación para determinar el problema a solucionar (UX) y diseñaríamos una solución centrada en nuestros usuarios (UI).
🙋🏽♀️ EQUIPO
Individual
⏰ TIEMPO
2 semanas
❓ PROBLEM STATEMENT
“Los jóvenes que viven en pareja necesitan una forma fácil y eficiente de compartir gastos y pagar sin tener que pasar por los trámites de tener que abrir una cuenta bancaria conjunta.”
UX
Empatizar
En esta primera fase de la investigación comencé haciendo una serie de entrevistas y encuestas de guerrilla a parejas de mi entorno para saber cuáles eran las dinámicas y conductas que más se repetían en cuanto a la organización de sus finanzas: si compartían gastos, qué clase de gastos compartían, si llevaban un registro de estos… Una vez recabada cierta información, me lancé con las encuestas y entrevistas definitivas para poder recoger la mayor cantidad de información útil posible.
Finalmente obtuve 22 encuestas y 7 entrevistas, lo cual, para ser la cuarta semana del bootcamp y ser mi primer proyecto individual, no estaba nada mal. En cuanto a los insights de dichas encuestas y entrevistas, fueron muy interesantes y me arrojaron muchos puntos desde donde partir con mi proyecto. Por un lado, el 100% de los encuestados y entrevistados compartían gastos con sus parejas, lo cual es un dato interesante teniendo en cuenta la cantidad de personas a las que se entrevistó de forma individual. Los principales beneficios asociados a compartir gastos mencionados por los usuarios entrevistados/encuestados son el ahorro y la comodidad. Además, mencionaban la flexibilidad como valor añadido muy importante, ya que el 63,2% de las parejas estudiadas no aportaban la misma cantidad cada mes, sino que su aportación se medía en función de su economía individual, lo cual permitía a la pareja vivir de una forma más cómoda.
En cuanto a inconvenientes de compartir gastos, los usuarios mencionaban principalmente el descontrol y la dificultad de ahorrar. Por un lado, al no tener una cuenta conjunta, señalaban la dificultad de controlar cuánto dinero gastaban al mes en total entre los dos, así como generar ciertas estadísticas de gastos fijos como la luz, el agua o el alquiler. Esta situación de falta de control hacía que, por un lado, acabasen gastando muchos meses más dinero del que esperaban y, por otro lado, les imposibilitaba ahorrar en la mayoría de los casos. Estos dos inconvenientes frustraban mucho a los usuarios, aunque no llegaba nunca a pesar tanto como las ventajas de compartir gastos.
Cuando se les preguntó por la forma en la que controlaban los gastos, tan solo un 15% de los usuarios entrevistados y encuestados realizaba un seguimiento de los gastos, aunque ninguno detallado, sino por medio de la cuenta bancaria o apuntando ciertos gastos importantes (luz, agua o alquiler) en una tabla de Excel.
Definir
Una vez tuve anotados todos los insights de la etapa anterior, pude rellenar el Lean UX Canvas con toda la información, lo cual me dio una visión global de mi proyecto y hacia dónde podía expandirse. El siguiente paso lógico fue trazar un User Persona para poder empatizar de forma más sencilla con el usuario y desarrollar un User Journey con el que identificar los puntos débiles del proceso de compartir gastos donde mi potencial solución podría tener cabida.
Como se muestra en el User Journey anterior, en base a los datos obtenidos de las encuestas y entrevistas mi producto tenía que intervenir, sobre todo, en la forma en la que las parejas anotan sus gastos para registrarlos y en cómo se organizan para lograr ahorrar a final de mes. Con esta herramienta y con el Affinity Diagram que realicé posteriormente, pude determinar aquellas funcionalidades que obligatoriamente tendrían que desarrollarse en mi MVP.
Otras funciones que aparecieron en las entrevistas y encuestas y que fueron descartadas en un análisis de MoSCoW eran un sistema de deudas y beneficios por el cual la app informaría a cada miembro quién debe dinero a quién, la posibilidad de pagar desde la propia app al otro miembro de la pareja (añadiendo un método de pago o conectando con Bizum), un sistema de hucha y notificaciones push para recordar al usuario registrar sus gastos. Para seleccionar las funcionalidades que finalmente se desarrollaron en el producto final se atendió al requerimiento principal de los usuarios, que era ejercer un mayor control sobre sus finanzas compartidas.
Idear
En esta fase del proyecto desarrollé el Affinity Diagram donde realicé un brainstorming de posibles soluciones a todos los problemas que habían aparecido en la fase de investigación. Como mencioné anteriormente y gracias a un análisis de MoSCoW, determiné intervenir sobre los dos pain points principales que aparecen en las parejas de jóvenes que comparten gastos: la dificultad para ahorrar a final de mes y la falta de control sobre el dinero que gastan.
Para el primer pain point decidí proponer una solución que incluiría estadísticas y gráficos mensuales y anuales de los gastos de la pareja tanto de forma individual como de forma conjunta, de manera que los usuarios puedan ver el dinero que gastan al mes y compararlo con otros meses, así como visualizar si están consiguiendo ahorrar o, por el contrario, deben reducir los gastos en meses futuros para alcanzar su objetivo.
Por otro lado, para conseguir un mayor control sobre el dinero que gastan y llevar un seguimiento efectivo, la solución que elegí fue un sistema de registro de gastos que se anotaría en un historial de meses, donde el usuario pudiese añadir los gastos que realiza al día (supermercado, delivery, luz…). Estos gastos podrían repetirse en el tiempo (como, por ejemplo, una suscripción a Netflix, que es un gasto que se repite cada mes) o un gasto puntual. De esta forma, la pareja podría añadir el gasto en el momento en el que ocurre, indicando cuándo se realizó, quién de los dos miembros lo llevó a cabo y el concepto del gasto.
Una vez tuve planteadas las funcionalidades principales, comencé a trabajar en la arquitectura de la información de lo que sería mi app de finanzas definiendo el Sitemap del sitio y, posteriormente, el Userflow de las dos partes principales del MVP.
Por último, comencé a dibujar las primeras pantallas de mi prototipo con la ayuda del Crazy 8, lo cual sentó las bases para lo que más tarde sería el Low-fi.
Prototipar + Testear
A partir del Low-fi y los primeros test con varios usuarios, comencé a perfilar el Mid-fi prototype. En este prototipo comencé a definir los espaciados de las cards de gastos, así como la curvatura de los botones principales. Además, pude determinar la cantidad de elementos que tendría la tab bar de mi producto digital. Una vez acabado el Mid-fi, testeé una vez más el producto y me sorprendí al encontrar que la mayoría de los usuarios desarrollaban las tareas que se les pedían sin casi ninguna complicación.
UI
La segunda semana del proyecto la dediqué al UI del MVP que tendría que presentar, comenzando por esbozar un moodboard que reflejara los valores y el look and feel de mi producto. En un Desirability Test que se llevó a cabo con las imágenes del moodboard los usuarios arrojaron las características más significativas de la marca: funcional, creativa y fiable.
A continuación, comencé a explorar paletas de colores que fueran acorde con la marca que había creado y que se vería reflejada en el producto final. De todas las opciones que barajé, finalmente me decanté por una paleta que incluía el blanco y el negro como colores principales y secundarios, y un tono azulado como color de acento. Esta paleta escogida resultó ser bastante funcional, ya que el color de acento resaltaba bien entre el blanco y el negro y cumplía su función principal, que era la de guiar al usuario a través del flujo.
Una vez habiendo definido los colores y tipografía, comencé a hacer pruebas sobre el Mid-fi para definir ciertos elementos gráficos como las sombras, los símbolos de la tab bar, el tamaño de la tipografía para cada sección y el espaciado entre los textos, entre otros. De esta forma pude, de forma simultánea, dibujar un pequeño Style tiles con los elementos gráficos de la app.
Al tener casi todas las pantallas de mi High-fi prototype listas, pude armar finalmente el UI Kit del proyecto. Trabajé con sombras ligeras y espaciados en Base 8, y, al diseñar todo el proyecto en Figma, creé un sistema de diseño que me facilitó bastante la composición de las pantallas.
Finalmente y llegando al décimo y último día del proyecto, conseguí reunir un MVP, Fullsharing, que permitía a las parejas jóvenes registrar sus gastos del día a día para llevar un seguimiento de los mismos, así como acceder a estadísticas y gráficos de los gastos de forma mensual y anual para controlar sus finanzas de forma fácil y eficiente.
Aprendizaje
Este primer proyecto individual me hizo darme cuenta de lo valioso que puede llegar a ser tener un equipo detrás que nos ayude a tomar las decisiones más importantes y salir de los “atascos” creativos. Durante estas dos semanas, eché de menos a todos los compañeros que había tenido hasta el momento.
No obstante y habiendo reconocido el valor de un equipo de diseñadores a la hora de desarrollar un producto, en este primer proyecto también aprendí a conocerme a mí misma y mi forma de trabajar más a fondo. Durante todo el proceso me encontré bastante cómoda trabajando de forma individual, lo cual me hizo valorar también mi esfuerzo y mi trabajo.
Además, me gustaría resaltar como aprendizaje clave para este proyecto la organización de los tiempos. Para mí fue muy importante delimitar los tiempos de descanso y los de trabajo para llegar al último día de estas dos semanas y poder presentar un MVP completo y realista.
