Tapper — Diseño de una app de Wellness
El primer proyecto individual de Ironhack llegó una semana antes de lo que esperábamos. Aunque en teoría empezaríamos este camino a solas a partir de la semana 5, nuestros instructores nos dieron la noticia justo al final de la semana 3, cuando ya habíamos presentado el proyecto grupal de Cabify.
El reto que nos planteaban para el fin de semana, era detectar tres problemas de los usuarios, cuanto más específicos mejor, dentro de las áreas de Wellness o Finanzas. Dentro de estos tres problemas, nuestros instructores elegirían uno de ellos para empezar a trabajar en el proyecto individual durante las dos siguientes semanas.
¿Preparadas? ¡Allá vamos!
Día 0 - Definición del problema
Durante el fin de semana, organicé tantas videollamadas como me fue posible (tanto por tiempo como por la disponibilidad de los usuarios a los que iba a entrevistar). El plan era llevar a cabo varias entrevistas de guerrilla muy genéricas donde el usuario llevase la voz cantante de la conversación. Conseguí entrevistar a cinco personas, planteándoles temas muy genéricos relacionados con Wellness y Finanzas que pudieran resultar controvertidos o problemáticos. Para ello, había preparado una larga lista:
Sin embargo, los temas que mayor preocupación parecían despertar en los usuarios siempre eran los mismos: “mejorar sus hábitos alimenticios”, “encontrar motivación para realizar deporte” y, literalmente, “ganar más dinero”. Como, por desgracia, la solución a los dos últimos temas no está en un producto digital, decidimos centrarnos en la primera.
Mejorar los hábitos alimenticios sonaba bien. Pero, ¿qué exactamente tenía que mejorar de los hábitos alimenticios? ¿Es eso un problema? Me parecía un tema un poco vago y demasiado genérico, así que decidí seguir investigando los usuarios que me habían indicado que esto les resultaba un problema en su vida.
Tras esta segunda ronda de entrevistas de guerrilla, concreté tres problemas desde los que podría partir mi app:
- Es complicado establecer y mantener una dieta equilibrada
- No siempre sabemos cómo y cuánto conservar la comida y eso deriva en un desperdicio de la misma y un descontrol en nuestra planificación alimenticia.
- En pisos compartidos se desperdicia mucha comida, con su consecuente gasto económico. Podría generarse una planificación común de la comida necesaria, en función de los hábitos de cada uno, de manera que los recursos se rentabilicen al máximo y se reduzca el gasto.
El problema elegido por Ironhack para empezar a trabajar fue una mezcla de los dos primeros. Con esta información en la mano, me puse a trabajar.
Semana 1, UX: Día 1 — Lunes
Partiendo del Lean Survey Canvas y de los problemas que me habían asignado en Ironhack, comencé poniendo en orden todo aquello que ya sabía, lo que necesitaba saber y de qué usuarios necesitaba extraer esa información. Aunque aún no era consciente, estaba orientando mi investigación en una dirección que no tendría muchas salidas, por lo que no vamos a ahondar mucho en esta fase inicial. Solo es interesante destacar que la primera encuesta estaba orientada al registro de las comidas realizadas y a la creación de sugerencias de platos específicos que ayudasen al usuario a conseguir unos objetivos de alimentación específicos.
El problema de este problema, valga la redundancia, es que los hábitos alimenticios de cada usuario son tremendamente susceptibles al cambio, al estar condicionados por infinidad de factores, que imposibilitaría que la solución, sea cual sea, consiga adaptar sus avisos y funcionamiento a la realidad de los usuarios.
Por tanto, casi al final del primer día, y con varias herramientas ya terminadas sobre la primera idea, decidí dar un pequeño volantazo y centrarme en el segundo problema:
El desperdicio de comida debido a la falta de información sobre cómo conservarla.
Rehice las encuestas, esta vez mucho más satisfecha con el resultado, y las lancé por Instagram. Este recurso lo suelo utilizar únicamente como apoyo a las encuestas que obtengo en las encuestas de Google. Pero, a situaciones desesperadas, medidas desesperadas.
En Instagram, al menos en mi experiencia, las respuestas son menos numerosas pero llegan mucho más rápido. En menos de una hora ya había conseguido 37 respuestas con las que podía empezar a trabajar al día siguiente.
Semana 1, UX: Día 2 — Martes
Al empezar el segundo día y revisar los resultados de las encuestas, me sorprendió ver que la gran mayoría de las personas reconocía no recordar que había guardado comida, pero que nadie consideraba que desperdiciase mucha comida. Incluyendo personas que en las entrevistas de guerrilla se habían definido como ese perfil de usuario. Por tanto, decidí enfocar las entrevistas a resolver este aspecto.
Tras volcar los datos en un Affinity Diagram, vi que los resultados apuntaban a que los usuarios no tomaban en consideración los restos de la comida que podían ser utilizados y que tan apreciados son en la cocina de aprovechamiento. Simplemente, no consideraban que esta comida fuera, como tal, comida. Una vez definido este punto en las entrevistas, continuamos con el resto de cuestiones.
Los restos de comida y las conservas que no consiguen terminarse en un solo uso se presentaban como los alimentos más susceptibles de ser desperdiciados según nuestros usuarios.
Por una parte, los restos de comida no generaban confianza en los usuarios tras dos o tres días en la nevera, por lo que se terminaban tirando sin saber realmente si estaban en mal estado. La razón por la que se tiraban los botes y latas de conserva era, simplemente, que los usuarios olvidaban cuánto hacía que lo habían abierto.
Así que, de aquí, pude extraer dos problemas concretos y perfectamente definidos, que además guardaban una estrecha relación entre ellos:
- Los usuarios no saben cómo ni cuánto conservar los restos de sus comidas correctamente.
- Los usuarios olvidan la fecha en la que han abierto o guardado ciertos productos de larga conservación, tanto en nevera como en congelador.
La segunda mitad del día la dediqué a volcar todos los datos obtenidos de las nuevas encuestas y las entrevistas que había conseguido hacer durante la mañana, y a seguir avanzando por las herramientas de diseño UX que me ayudarían a definir mejor el problema a resolver y el usuario al que estábamos intentando ayudar.
Llegados a la creación del Lean UX Canvas definitivo, decidí orientar la solución a resolver los problemas de gestión de comida de los usuarios con hábitos alimenticios inestables. Esto incluye, entre otros, a personas cuyos empleos no les ofrece una estabilidad horaria o jóvenes que se han independizado recientemente y aún no tienen los conocimientos necesarios para conservar la comida correctamente.
Por tanto, la solución que estaba diseñando debía estar orientada a:
- Recordar a los usuarios la fecha de apertura o cocinado (en función del producto).
- Sugerir modos de conservación y fecha máxima de consumo, según los componentes del producto a conservar y la fecha de cocinado.
- Mostrar información relevante acerca del producto y su conservación, así como avisos de precaución si fuera necesario.
Desde aquí, definí mi User Persona definitivo:
Con esto terminaba la planificación del día 2 y estaba por fin al día y con camino definido que tenía bastante más sentido que el anterior. Había merecido la pena pegar el volantazo el primer día.
Semana 1, UX: Día 3 — Miércoles
Con el usuario y los tres problemas a resolver ya definidos, se abrieron varias opciones para mi solución. Gracias a la herramienta MoSCoW, descarté muchas de las funcionalidades que había pensado.
El tiempo para el proyecto era limitado y muchas de ellas no aportaban demasiado para el objetivo principal, así que decidí descartar muchas y apuntar algunas para integrarlas en el futuro de la app.
¿Y por qué una app y no una web? Porque el usuario iba a necesitar recibir avisos en cualquier lugar y momento, y tener acceso fácil a ellos de manera rápida. De otra manera, la solución que se proponía no tenía sentido.
Tras elaborar y lanzar a testeo el cardsorting, recopilé los resultados de los cinco usuarios que habían testado el cardsorting. Con ellos, diseñé uno definitivo que, aunque era un poco distinto del que había diseñado en origen, tenía más sentido para los usuarios.
Desde aquí, empecé a diseñar el Site Map y el primer boceto de la app en un Crazy 8. Son dos herramientas que, al menos en mi caso, están muy relacionadas entre sí y cambian en función de la otra, así que fui saltando entre ellas hasta que las dos tuvieron sentido y quedó algo con lo que estaba satisfecha.
Este es el Site Map que propuse para Tapper:
Semana 1, UX: Día 4 — Jueves
En este punto del proceso de diseño UX, ya solo quedaba crear una jerarquía visual para lo que había diseñado el día anterior.
Cuando testeé el primer diseño Low-Fi, el feedback que recibí por parte de los usuarios no fue nada positivo. Tras revisarlo, me di cuenta de que los conceptos que para mí eran evidentes, no resultaban nada intuitivos para los usuarios. Y aquí empezó uno de los días más frustrantes de mi experiencia en Ironhack, pero de los que más he aprendido en estos meses.
Probé distintas soluciones que no dieron buenos resultados, y entonces que estaba partiendo de una idea demasiado compleja para mi MVP. Reduje los espacios de almacenamiento a nevera y congelador, con una estructura que permitiese añadir más espacios en futuros diseños de la app, en el caso de necesitarlo.
Di más importancia a las estadísticas, simplifiqué el formulario de creación de los tappers y rediseñé la arquitectura de la información de algunas secciones para que fueran más intuitivas para el usuario.
Y tras un día entero de ensayo y error, el resultado del Low-Fi tras las correcciones fue este:
Durante el desarrollo de la versión Mid-Fi, surgieron algunos cambios orientados a seguir simplificando el uso de la app para el usuario. Sin embargo, tras el feedback de los instructores, decidí hacer un repaso general a todo el diseño de la app durante el fin de semana. Esta fue la propuesta final que presenté:
Semana 2, UI: Día 1 — Lunes
Además de revisar el Mid-fi durante el fin de semana, el domingo intenté adelantar trabajo haciendo el moodboard, y lo mandé a testear a través del canal de Slack de Ironhack. Me sorprendió ver en los resultados que casi todas las respuestas incluían la palabra “colaborativo”.
Cuando pregunté a los usuarios me explicaron que, simplemente, una de las imágenes les había evocado una app colaborativa. Me anoté esta idea porque me resultó interesante para el futuro de la app.
Rehice el moodboard, orientándolo al uso individual de la app y lo envié a testear. Esta vez, los resultados fueron más afines con mi app. Los brand attributes extraídos de los usuarios fueron: Eficiente, Fresca, Funcional, Natural y Se Preocupa.
Desde el moodboard, seleccioné la paleta de colores que creía que mejor irían con la app. Y volví a seleccionarlos. Y los seleccioné otra vez. Y con varias paletas de colores ya creadas, decidí decantarme por dos de ellas, aplicarlas en algunas pantallas del hi-fi y testarlas con los usuarios.
Tras los testeos, me decanté por una paleta de colores complementarios porque, en parte, los necesitaba para comunicar correctamente la información de la app.
Y tras esto seleccioné las tipografías, que para todos los casos serían de la familia San Francisco — Pro para el contenido de la app y Round para el Logotipo.
Algo a destacar del lunes fue que, en este punto del Bootcamp, nos descubrieron el diseño en base 8. Por tanto, rehice los espaciados en algunas pantallas del Mid-fi con esta nueva información (sobre los cambios que ya había hecho durante el fin de semana) y adelanté el entregable del día 2 de espaciados, alineamiento y consistencia. Y menos mal que lo hice.
Semana 2, UI: Día 2 — Martes
Para estar segura de que el Style Tile que creaba de Tapper iba a estar cerca de la versión final, decidí aplicar los colores que había elegido para la app. Y no me gustaron. Los testeé, aún así, para estar segura. Los resultados confirmaron mi teoría, así que ajusté los colores, intentando ceñirme a la estética del moodboard de partida, y volví a aplicarlos.
Así empezaba a ser el aspecto final de Tapper.
Semana 2, UI: Día 3 — Miércoles
Aunque tenía algo de presión porque tenía que terminar todo el Hi-Fi para el feedback individual del día siguiente, este día lo disfruté mucho. Lo dediqué entero a terminar de encajar todos los elementos en base 8, a crear los estilos de texto y color definitivos, y a adelantar algunas partes del prototipo que necesitaba para tomar las últimas decisiones.
No hubo nada destacable, más allá de que es un trabajo muy laborioso y que requiere, más que otra cosa, tiempo y concentración. Algo así tenía preparado para el feedback del día 4:
Semana 2, UI: Día 4 — Jueves
El feedback me hizo cambiar algunas cosas para reducir el ruido visual para el usuario. Durante estos cambios, me di cuenta de que si reubicaba algunos elementos, como la alarma, fuera de la ficha de cada Tapper, reducía los pasos que necesitaba el usuario para establecer la alarma. Este y otros cambios que introduje simplificaron el uso de la app.
Aun así, teste ambas versiones con tres usuarios y diseñé una app que incluía lo mejor de cada versión y seguía simplificando el proceso. Y, por fin, después de dos semanas, llegué a la versión final de Tapper:
Fue un día de muchísimas horas de trabajo, pero como se dice por ahí, “sarna con gusto, no pica”. Podéis acceder al prototipo interactivo de Tapper haciendo click aquí.
¿Recordáis que durante el moodboard salió la idea de una app colaborativa? Esto sembró una idea que me resultó muy interesante y que podía ayudar a completar el uso de la app y mejorar la experiencia.
En futuros diseños, se plantea integrar la funcionalidad de Nevera Compartida, la cual permite crear neveras a las que se puede incluir varios usuarios, de manera que una misma nevera pueda ser editada desde distintas cuentas.
Normalmente, las neveras son usadas por más de una persona. ¿Por qué no integrar esta característica también en nuestra nevera de bolsillo?
Conclusión
Fueron dos semanas de mucho trabajo, muchas dudas y muchas decisiones. Trabajar de manera individual todos los aspectos del diseño de un proyecto te hace entender de otra forma las herramientas y entender en qué campos tienes más fuerza y en cuáles necesitas más apoyo externo.
Para mí, al igual que para muchos de mis compañeros, este proyecto fue un punto de inflexión en nuestra evolución durante el Bootcamp.
Mil gracias por acompañarme hasta aquí, ¡nos vemos en los comentarios!
