
Design Sprint y el futuro de la movilidad.
Se nos propuso el retro de realizar un Design Sprint, con una duración de una semana, para embarcarnos en la búsqueda del Futuro de la Movilidad propuesto por la marca automovilista Seat y su nuevo centro de desarrollo de software Seat:CODE.
DÍA 1
Tras haber realizado los grupos, comenzamos con el Design Sprint. El primer paso fue comenzar a realizar, en forma de preguntas, suposiciones para poder comenzar el proyecto. Qué podría o no podría realizar el usuario a través de la app, si abría la app o si simplemente tendría que interactuar con el vehículo, por ejemplo. Las Sprint Questions, que es así como se llama esta parte, son un buen método para comenzar el camino hacia la idea principal.
Tras esto, realizamos nuestro canvas. Estará divido en: Meta, Mapa de Usuarios, Sprint Questions y HMW.

Una vez escritas todas las cuestiones, sacamos alrededor de unas 65 preguntas, empezamos con el siguiente paso. Este seria HMW (How Might We). Consiste en escribir todas las cuestiones anteriores en post-it pero formulando desde el principio con “¿Cómo podríamos…?”. Una vez que teníamos todas las cuestiones escritas las organizamos en diferentes clúster.
El siguiente paso que completamos fue crear un mapa de usuarios. Con tres usuarios realizamos tres supuestos casos en los cuales se podrían observa situaciones de un día cualquiera usando/interactuando con la app. El primero de ellos era Eduardo, un hombre casado y con hijos que trabaja en una oficina, que posee un coche eléctrico con sus ventajas en inconvenientes. El segundo caso era la familia Benítez, que compuesto por marido, esposa, hijo y abuela, deciden realizar un viaje vacacional con su coche eléctrico. Y el tercero y último es Joaquin, un estudiante universitario de 23 años que es usuario frecuente de transporte público y ve se limitado por no tener acceso a un medio de transporte privado.
Tras el almuerzo tuvimos las diferentes entrevistas con los expertos. En nuestro caso fueron tres poseedores de un vehículo eléctrico Tesla. Nos hablaron de los puntos fuertes, cómo ven que está evolucionando el sector, los diferentes competidores respecto a Tesla, la experiencia de compra o los fallos o mejoras que, en su opinión, presentan este tipo de vehículos.
Una vez terminadas las entrevistas con los expertos comenzamos las votaciones. Volvimos a repasar y debatir, e incluso añadir algunas preguntas más. A la hora de los resultados, estaba todo bastante repartido. Nuestros decisors eligieron dos cuestiones: “¿Cómo podríamos hacer que el usuario alquile su vehículo?” y “¿Cómo podríamos hacer que el sistema recomendara la distribución del equipaje para optimizar el espacio?”. El grupo de nuevo se divide en dos. Nos quedamos con la segunda cuestión y el segundo mapa de usuario.
DÍA 2
Comenzamos con la realización de los Lightning demos. Cada uno individualmente. Buscando referencias y nuevos aportes para introducirlos o para que nos sirvan de inspiración en nuestro proyecto. Podían ser cualquier tipo de referencias, de interfaz, diseño, tecnologías, servicios…

Terminados los moodboards, añadimos a nuestro canvas las aportaciones que más nos interesaba incluir en nuestro proyecto y las exponíamos al resto de compañeros.
El siguiente paso fue volver a pensar sobre la idea. Seguir intentando mejorarla ahora que todos los compañeros habíamos puesto todas las ideas en común. Resaltamos las ideas más importantes e hicimos cuatro bocetos rápidos sobre ello. Finalmente pasamos a limpio todas la ideas e, individualmente, realizamos los wireframes de nuestra idea.
DÍA 3
Empezamos colgando los wireframes realizados el día anterior para que los miembros del grupo puedan ver las ideas obtenidas. Seguidamente dimos quince votos, cada uno, a las ideas que más nos gustasen para, posteriormente, llevarlas acabo. Realizamos una segunda votación, pero esta vez solo se podía dar un voto a una idea. Sería el voto definitivo.
La idea que se desarrollara finalmente consistiría en en una aplicación para poder llevar el equipaje de forma correcta en el maletero de nuestro vehículo. El proceso se realiza con realidad aumentada. La cámara del smartphone medirá las longitudes de el equipaje y, tras haber seleccionado el modelo de coche, se llevara acabo el proceso de colocación.
Este mismo día también realizamos el storyboard de un supuesto caso de utilización del servicio a través de la aplicación .
DÍA 4
Se comenzó a crear el prototipo de la aplicación. Partiendo de la base ya expuesta, cada miembro del equipo tendría que crear desde cero un app con algunas de las ideas que anteriormente se votaron.
La aplicación se creo con Figma. Al ser un prototipo, la aplicación no debería de tener una carga importante a nivel estético, sino, centrarse en las funcionalidades. Un diseño limpio y sin pocas distracciones ayudaría posteriormente a un buen testeo de los usuarios.


DÍA 5
Tras tener el prototipo terminado pasamos a la fase de testing con los usuarios. Se seleccionó un grupo de ocho personas para el proceso, con edades comprendidas entre los diecinueve y cincuenta y nueve años.
Se les preguntaba unas cuestiones iniciales antes de ponerles delante de la aplicación. Si tenían carnet de conducir, si utilizaban mucho el coche, la frecuencia de realización de viajes en coche, el número de ocupantes con los que se suelen realizar dichos viajes y si tenían problemas a la hora de organizar el equipaje del vehículo.
Una vez contestadas las preguntas se les ponía en contexto con la aplicación y explicándoles sobre lo que iba. El proceso de testing simplemente consistía en realizar el proceso de la búsqueda del modelo de coche, añadir pasajeros y equipaje y proceder a dar el visto bueno a toda la información.
Al terminar el proceso, se les realizaba de nuevo otras preguntas. Si les parecía útil la aplicación, si la utilizarían y si añadirían o quitarían algo. También se les pidió que evaluaran sobre cinco el conjunto, utilidad y facilidad de uso de la aplicación.
Con el resultado de los testing se creó la siguiente tabla:

RESULTADOS
Tras los datos expuestos se puede apreciar que los resultados para nuestros objetivos principales (¿Te parece útil? y ¿La utilizarías?) están divididos. Vemos que hay, en las dos cuestiones, cuatro usuarios que la ven útil y la descargarían y otros cuatros que no la utilizarían ni la descargarían.
El feedback que nos dan es bastante positivo en la mayoría de los casos. Las mejoras y puntos que podríamos añadir a la aplicación están muy bien pensadas. La inclusión de un pequeño tutorial inicial, añadir un itinerario del viaje, incluir información sobre la presión de las ruedas… son ideas realmente buenas y, que incluso, se podrían añadir a la versión final sin ningún tipo de problema.
Hay que destacar algunos comentarios de los usuarios que se repiten. Como es el hecho de que la aplicación la ven más como un complemento y no como una aplicación aparte.
CONCLUSIÓN

Una vez superada todas las fases, realizado el prototipo, el testeo y feedback por parte del usuario, toca la valoración sobre el Design Sprint.
En mi opinión es una metodología bastante eficiente. Se parte desde un concepto muy amplio para acabar, finalmente, en un tema bastante concreto, el cual, es más factible para desarrollar la idea.
La mayoría de los pros de esta metodología se centran en las interacciones con los compañeros. El reparto de tareas, por ejemplo, es igual para todos. Todos hacen el mismo volumen de trabajo. No hay ningún tipo de jerarquías y eso ayuda a estar todos al mismo nivel. Hay una obligación en colaborar continuamente, aportando ideas para el proyecto.
Al final, otro punto más a su favor y el más importante, es una metodología que da resultados rápidos y bastante precisos sobre la idea o concepto que se quiere desarrollar.
