Cabishare_ Añadir una nueva funcionalidad a Cabify
En la tercera semana del Bootcamp de Diseño UX/UI de Ironhack, nos pidieron añadir una funcionalidad nueva a una app ya reconocida y con recorrido en el mercado. De entre una lista de grandes marcas, nuestra elegida fue Cabify, al ser un producto con el que las tres integrantes del equipo estábamos familiarizados y había información de la investigación con la que ya contábamos. Además, el acceso a los usuarios de esta app era muy sencillo.
Día 1 — Lunes
En un primer lugar, realizamos un Lean Survey Canvas para diseñar nuestra encuesta. Aquí volcamos la información que ya teníamos y detectamos los usuarios a los que queríamos dirigir la encuesta. En el caso de Cabify, el público objetivo es amplio, por lo que solo descartamos a los usuarios menores de edad, con la intención de simplificar el proceso de investigación.
Tras plantear las cuestiones que necesitábamos resolver para el proyecto, decidimos acotar la entrevista a usuarios de VTC que ya hubieran utilizado estos servicios y pudieran encontrar vacíos en la app móvil de Cabify. Por tanto, nos interesaba no descartar usuarios de otros servicios de VTC, como Uber, ya que podían aportar ideas con las que los usuarios de Cabify no estaban familiarizados.
Una vez resueltas estas cuestiones, diseñamos la encuesta y la lanzamos a nuestro target. Esta vez, por suerte, las personas que teníamos alrededor eran usuarios frecuentes de VTC y la investigación, en este sentido, resultó relativamente sencilla.
A continuación, pasamos a plantear en la entrevista aquellas cuestiones que en la encuesta no habíamos podido resolver. Por la experiencia en proyectos previos, decidimos diseñar una entrevista breve y animar a los entrevistados a plantear temas que le supusieran un problema o que en algún momento les hubiera dado que pensar.
Nos sorprendió ver en las respuestas de los usuarios, tanto en las encuestas como en las entrevistas, que apenas se compartía el servicio de Cabify en aquellos casos en los que los usuarios realizaban trayectos muy parecidos, cosa que sí sucedía entre los usuarios de Uber.
Al ahondar un poco más, descubrimos que, aunque Cabify daba la opción de compartir el trayecto a sus usuarios, el método a seguir parecía muy rudimentario y requería la atención del usuario, que tenía que estar atento al punto de parada y repartir los gastos posteriormente con el resto de usuarios a través de otras plataformas. De hecho, algunos usuarios ni siquiera eran conscientes de que esta opción existe, ya que no aparece en ninguna parte del proceso de contratación.
Para concretar un poco más, os dejo aquí los resultados extraídos de las encuestas y entrevistas. Un 71% de los usuarios encuestados reconocían ser usuarios frecuentes de VTC. De estos, un 84% había utilizado alguna vez este servicio con amigos, pero solo un 50% de los encuestados era consciente de que este servicio existía en Cabify.
Además de investigar a los usuarios, analizamos el contexto de negocio de Cabify, tanto a nivel propio como con respecto a su competencia. En primer lugar, realizamos un análisis DAFO para entender un poco mejor la situación de la marca en el mercado y dónde podíamos mejorar la experiencia de usuario. Por otro lado, a través de un Análisis Competitivo, detectamos la principal competencia y pudimos realizar una comparativa de las funcionalidades de nuestro producto con respecto a la competencia.
Como nos habían adelantado las entrevistas y encuestas, descubrimos que el trayecto con múltiples paradas era una funcionalidad que se podía encontrar en la principal competencia de Cabify, Uber, mientras que en nuestra app no se ofrecía esa opción al usuario durante la contratación del servicio.
Tras llevar a cabo toda esta investigación, ya teníamos la información suficiente para empezar a esbozar un Lean UX Canvas. Decidimos centrarnos en la problemática de compartir trayectos y gestionarlo a través de la app, ya que las opiniones de los usuarios a los que accedimos se orientaban en esa dirección.
Día 2 — Martes
El segundo día planteaba tres tareas: definir a nuestro usuario, estructurar la información de manera que tuviera sentido con el flujo de usuario en la app de Cabify y, lo más importante: ponernos de acuerdo. Al conocer tan de cerca la app, teníamos ideas muy variadas que podían encajar muy bien con los problemas que estábamos planteando. El problema era que había demasiadas ideas.
Por eso, el día comenzó con un brainstorming para volcar todas las ideas que habían ido surgiendo durante la investigación. Entre ideas poco realistas como crear un servicio de recogida de niños para el colegio o instalar un minibar en la zona del pasajero del vehículo (así son los brainstorming), nos encontramos con algunas ideas interesantes que nos ayudaban a resolver los problemas planteados en el Lean UX Canvas.
Algunas ideas como “creación de viajes con paradas múltiples”, “invitar a otros usuarios al viaje” o “recogida de compañeros de trabajo que sigan la misma ruta”, nos marcaron un camino que podía tener sentido seguir.
Llegadas a este punto, no podíamos seguir diseñando sin saber más a fondo para quién estábamos diseñando. Esta parte es siempre divertida y especial. El usuario para el que estás diseñando pasa a tener cara y nombre y, de repente, se ve con autoridad para decirte no a ciertas ideas, y pasa a ser uno más del equipo.
Reuniendo partes de las entrevistas que habíamos hecho y de algunas encuestas de guerrilla que pudimos realizar en el último momento, diseñamos a nuestra usuaria ideal en el User Persona: Celeste Navarro.
Además, con el User Journey planteamos un día en el que nuestra funcionalidad habría venido de perlas a Celeste (quizá más basado en hechos reales que ninguno de los User Journey que habíamos diseñado para proyectos anteriores), y resolvimos estos vacíos de la app en el User Scenario.
Ponernos de acuerdo sobre cómo integrar la funcionalidad en la app fue relativamente sencillo. Aunque los Crazy 8 no coincidieron en un primer momento, no tardamos en ponernos de acuerdo sobre qué versión era la que se acercaba más a algo sobre lo que podíamos trabajar.
Una vez en ello, decidir cómo establece el usuario los puntos de origen y destino nos resultó muy complejo. Tras varias propuestas, decidimos simplificar el proceso para el usuario y hacerlo un poco más intuitivo. El resultado fue un híbrido de los tres Crazy 8 iniciales que se acercaba un poco más a la experiencia que ofrece Cabify en su app.
Desde aquí fue sencillo diseñar el User Flow, ya que muchas de las decisiones que tenía que tomar el usuario las habíamos resuelto en el diseño del Crazy 8 definitivo.
Lo que veis arriba fue el resultado del boceto del flujo de Celeste por nuestra app para contratar un viaje múltiple desde un destino común hasta dos puntos establecidos por ella. Además, invita a su amiga para que el viaje se registre también en su cuenta y se divida el pago de manera proporcional a la distancia recorrida por cada una de ellas.
Día 3 — Miércoles
En primer lugar, creamos un moodboard para saber en qué paleta de colores debíamos movernos para esta funcionalidad. En este caso no fue muy complicado porque no partíamos de cero, sino que ya teníamos una base que nos daba Cabify sobre la que trabajar. Lanzamos el moodboard con la lista de atributos para testearlo. Según los usuarios, los brand attributes asociados al Moodboard fueron: Moderna, Actual, Urbana, Enérgica y Profesional.
Dejamos los datos del moodboard reservados para cuando llegase el momento de crear el Hi-Fi y pasamos al Low-Fi. En base al Crazy 8, diseñamos las pantallas que necesitábamos para integrar la nueva funcionalidad. Algunos de los elementos y de las ideas que habían surgido se quedaron por el camino debido al tiempo limitado que teníamos para el proyecto.
Queríamos dedicar tiempo a diseñar correctamente las interacciones del prototipo, por lo que decidimos mostrar en el Low-fi solo las pantallas necesarias para cumplir el objetivo de nuestra usuaria. El resto del tiempo del que disponíamos, lo dedicamos a adelantar un poco del trabajo del día siguiente (la creación del prototipo Hi-Fi). De esta manera, dispondríamos de dos días para diseñar las interacciones y aprender un poco más sobre ellas.
Una vez terminado el prototipo del Low-fi, lo testeamos con algunos compañeros y las personas que teníamos alrededor en casa. El proceso de testeo fue un poco rudimentario, pero tuvo sus ventajas. El método consistía en una videoconferencia de Hangouts a través de la cual el usuario que testeaba el Low-fi compartía su pantalla y completaba el flujo, exponiendo sus dudas.
Alguno de los test que realizamos implicaban la interacción simultánea de varios usuarios, lo cual daba pie entre ellos a una conversación improvisada sobre la nueva funcionalidad que daba luz a propuestas realmente interesantes que simplificaban el proceso y mejoraban el prototipo final.
Con el Low-Fi de base y usando también como referencia algunas pantallas ya existentes en la app, creamos el Mid-Fi y lo prototipamos. Esta herramienta no era obligatoria en la planificación de Ironhack, pero es inevitable pasar por él si no quieres hacer siete versiones del Hi-Fi. Se resuelven muchas dudas en el proceso.
Sobre el diseño Mid-Fi aplicamos lo que habíamos sacado del moodboard. Sin embargo, como se acercaba la mitad de la tarde y aún quedaba bastante trabajo, decidimos dividir el equipo. Irene empezó a diseñar las interacciones de las primeras pantallas y Juan y yo seguíamos pasando el Mid-Fi a Hi-Fi.
Cuando se acercaba el final de la tarde y el proyecto ya tocaba su fin, decidimos volver a trabajar todos en las últimas cuestiones que quedaba por resolver, ya que todo iba enlazado y había que realizar varias tareas simultáneas para algunos procesos. El Hi-Fi estaba terminado y ya solo faltaba ultimar algunas cosas del prototipo. Os dejo aquí la versión Hi-Fi del diseño.
Los últimos detalles los dejamos para el siguiente día, pero terminamos ese día relativamente temprano y muy orgullosos con todo el trabajo que habíamos adelantado. O eso creíamos.
Cerca de las once de la noche, leí en el portal de Ironhack que el prototipo Hi-Fi tenía que estar terminado ese mismo día. ¿Ese mismo día? Oh, no… En clase habíamos entendido que solo había que subir el Hi-Fi, pero no había que terminar las interacciones. ¿O sí? El portal era un poco confuso.
Escribí a mis compañeros y decidimos pecar de prudentes. Nos volvimos a conectar y dedicamos una hora más a terminar el prototipo para poder subirlo sin fallos al portal. Para desvelar el misterio, al día siguiente nos confirmaron que había sido un error y no era necesario tener el prototipo finalizado. Pero, por otro lado, el proyecto ya estaba casi finalizado y estábamos súper orgullosos del resultado.
Día 4 — Jueves
Revisamos el prototipo que habíamos entregado el día anterior, en busca de errores que corregir, y testeamos el prototipo entre nosotros. Los siguientes pasos fueron corregir y testear, corregir y testear… hasta que quedó listo para testearlo con usuarios que no hubieran trabajado en el proyecto.
Tras esto, mientras aplicábamos las correcciones que habíamos anotado durante los testeos, comenzamos la presentación. Esta parte fue sencilla y no tiene mucho más allá donde podamos ahondar. El proyecto estaba terminado. ¡Cabishare existía!
Prueba nuestra nueva funcionalidad para Cabify a través del prototipo interactivo haciendo click aquí.
Si has llegado hasta aquí, solo me queda darte las gracias por leerme y decirte que espero tu opinión sobre nuestra nueva funcionalidad. ¿Alguna vez has dejado de compartir un trayecto de VTC porque era demasiado difícil gestionarlo? ¿Usarías Cabishare?
¡Te espero en los comentarios!
Nerea
