Design Sprint. Cómo mejorar la UX en un restaurante de lujo
Un design sprint es un proceso de 5 días que se utiliza para responder a problemas o preguntas críticas de negocio a través del diseño, prototipado y testeo de ideas con usuarios. Se suele utilizar cuando se quiere introducir un nuevo producto, servicio o característica en el mercado.
En lugar de esperar a lanzar un producto mínimo para averiguar si una idea es buena, el design sprint nos permite desarrollar y testear un prototipo realista en una sola semana para decidir si vamos por buen camino, reduciendo riesgos y costes si la idea no funciona. Se trata de una manera de conocer las reacciones de nuestros potenciales clientes antes de comprometernos con el desarrollo de una solución.
En este post os hablaré del design sprint en el que he tenido la oportunidad de participar juntamente con mis compañeros (Helena, Adrián y Marcello) describiendo brevemente cada una de sus fases hasta llegar al resultado final y las conclusiones obtenidas a partir de este proceso de trabajo.
Lunes: Crear un mapa y definir un objetivo
El reto al que nos enfrentamos mi equipo y yo fue el de ampliar digitalmente la experiencia de usuario (incluyendo el antes y el después) en un restaurante de alta cocina.
Para poder dar respuesta a este reto, nos planteamos una serie de sprint questions encaminadas a empezar a definir nuestro objetivo. Por ejemplo: ¿Se ayudará al cliente a apreciar la cocina? ¿Se reducirá el tiempo de espera?¿Mejorará la experiencia de pago? ¿Se ayudará a fidelizar al cliente? ¿Habrá opciones para gente vegetariana o vegana? Con estas preguntas, comenzamos a vislumbrar los posibles caminos para dar respuesta a nuestro reto.
A continuación creamos dos mapas de usuario en los que representamos los distintos momentos por los que dos clientes hipotéticos (y de perfiles distintos) pasaban durante su experiencia en el restaurante (llegada, acomodación, pedido, espera, etc.) y las emociones que sentían en cada momento. Estos mapas nos ayudaron a identificar los potenciales momentos de frustración o pain points por los cuales pasan los clientes de nuestro restaurante. Por ejemplo, encontramos pain points en el momento de pedir la comida o en el momento de hacer el pago.
El método HMW (“How Might We” o “Cómo podríamos…”) nos permitió coger los pain points detectados en el ejercicio anterior y replantearlos positivamente en forma de preguntas. Por ejemplo: ¿Cómo podríamos hacer que el cliente se sienta importante? ¿Cómo podríamos mejorar la experiencia de pago? ¿Como podríamos ayudar al cliente a entender el valor del plato?
Finalmente, aplicamos la dotmocracy (votación individual a partir de pegatinas) sobre nuestros HMW, eligiendo cada uno de nosotros las ideas que más interesantes nos parecían para alcanzar nuestro reto. Esto incluyó el voto particular de nuestro supervisor y decisor en el proyecto, Pere Feliu. A partir de los votos, decidimos que nuestro objetivo sería ampliar y mejorar la experiencia de usuario durante la estancia en el restaurante, ayudando al cliente a entender el valor del plato.
Martes: Revisión de ideas y creación de bocetos
El martes empezó con una investigación individual de ideas, conceptos y soluciones de otras empresas o proyectos relacionados con nuestro reto. Una vez hecho esto, llevamos a cabo las lightning demos: en turnos de 3 minutos, cada miembro del equipo presentó las ideas recopiladas mientras otra persona creaba rápidamente un boceto con cada idea aportada. Los bocetos se pegaron el la pared para tener una visión global de todas las ideas.
Una vez hecho esto, llegó el momento de convertir todo el material en soluciones y definir la estrategia. A partir de la información obtenida con las sprint questions, los mapas, el HMW y las lightning demos, cada uno de nosotros fue tomando notas con la información clave y bocetando soluciones con las ideas más prometedoras.
A continuación, cada uno eligió la idea que le resultó más factible/interesante para nuestro proyecto y creó 8 variaciones de ésta (lo que se conoce como Crazy 8s), para finalmente escoger una de ellas y crear el un boceto de 3 viñetas representando los detalles de la solución.
Miércoles: Decidir y crear un guión gráfico
El tercer día empezamos colgando los bocetos de nuestras soluciones en la pared para compartirlos con el resto del equipo. Cada uno de nosotros observó los guiones gráficos de sus compañeros y expresó sus dudas anotándolas en un post-it. Después, el responsable de cada guión aclaró las dudas de sus compañeros. A continuación volvimos a aplicar la dotmocracy para marcar las ideas que a cada uno nos parecieron más interesantes.
Finalmente decidimos que la mejor solución para alcanzar nuestro reto era crear una mesa interactiva que permitiera al cliente navegar por los distintos platos del restaurante y conocer sus detalles (origen de los ingredientes, preparación, alérgenos, etc.). La mesa también facilitaría el contacto con el camarero y el pago de la cuenta y permitiría al cliente dar feedback sobre su experiencia en el restaurante.
Una vez tomada la decisión, llegó el momento de empezar a concretar de qué manera funcionaría esta mesa interactiva. ¿De qué manera se le presentaría al cliente la solución? ¿Qué acciones permitiría la mesa? ¿Cómo se distribuiría la información en la pantalla?
Para responder a todas estas preguntas creamos un guión gráfico: una serie de viñetas que representaban la navegación de nuestro cliente por el producto. En esta fase tuvimos que concretar de qué manera presentaríamos la información de los platos, qué detalles incluiríamos sobre cada uno, cómo se podría contactar con el camarero, cómo se podría valorar la experiencia, etc. También decidimos que la pantalla de la mesa tendría un tamaño de un DIN A2 (42 x 59 cm).
Jueves: Crear un prototipo
¡Por fin llegó el día de prototipar! El jueves fue el día de ponerse manos a la obra para crear el prototipo de nuestra mesa interactiva. Había muchas decisiones que tomar: imagen gráfica (look and feel), distribución definitiva de las pantallas, navegación del usuario, platos a incluir en el menú, textos, imágenes…
Al tratarse de un prototipo, no podíamos incluir todos los productos del restaurante, o permitir al usuario realizar todas las acciones que nos hubiera gustado. El objetivo era crear un prototipo mínimamente viable y realista para poder ser testeado por los usuarios, y esa fue la tarea en la cual nos centramos.
Mientras unos buscaban recursos gráficos y redactaban los textos, otros empezamos a trabajar la estructura e imagen de nuestra mesa interactiva con Sketch. Poco a poco fuimos construyendo el menú, los detalles de los distintos platos y todas las pantallas que formarían parte de nuestro prototipo.
Una vez producidas todas las pantallas con Sketch, fue el momento de subir el proyecto a inVision para crear la navegación entre ellas. Finalmente, realizamos algunas pruebas de navegación para asegurarnos de que las pantallas estaban correctamente conectadas entre ellas y nos preparamos para el último día del sprint: el test de usuario.
Viernes: Test de usuario
Finalmente, llegamos al esperado día del test con usuarios. En este día, seleccionamos unas cuantas personas para probar nuestro prototipo, y así obtener feedback sobre el funcionamiento de nuestra aplicación.
Para realizar la simulación de una mesa interactiva utilizamos un proyector que enfocamos verticalmente a una mesa de color blanco. De esta manera pudimos simular la pantalla directamente en una mesa real y crear un ambiente lo más realista posible para el usuario. Los “clicks” del usuario sobre la mesa eran realizados en la aplicación por un miembro del equipo a través de su ordenador.
Los miembros del equipo nos fuimos turnando para interpretar los distintos papeles requeridos en un test de usuario: entrevistar y guiar a la persona, simular su interacción con la mesa y tomar notas sobre el feedback (verbal y no verbal) obtenido. Al acabar cada test (en total realizamos cinco) las notas tomadas se trasladaron a un mural para poder compararlas al final.
Los usuarios de nuestra aplicación nos permitieron obtener muchísima información valiosa sobre nuestro prototipo. En general, a las personas que participaron en nuestro test les gustó la idea de una mesa interactiva, a la vez que detectaron algunos pain points que nos ayudarían a mejorar la aplicación en el futuro. El día del testeo terminó con una gran sensación de satisfacción para todo el equipo, ya que lo habíamos conseguido: ¡habíamos creado y testeado un prototipo en tan solo una semana!
Puntos a mejorar
El feedback de los usuarios nos permitió identificar los principales pain points de nuestra aplicación. En equipo, analizamos los datos obtenidos y decidimos cuáles eran los puntos más importantes que debíamos mejorar:
- La mayoría de usuarios tuvo dificultades a la hora de pedir la cuenta a través de la mesa, ya que no localizaban el botón. Muchos optaron directamente por llamar al camarero y preguntarle.
- Muchos se sintieron confundidos con las opciones disponibles en la pantalla resumen del pedido. Esta pantalla mostraba los platos seleccionados y permitía pedirlos a cocina. En el momento de pedir el postre, resultó extraña la presencia de los platos principales y entrantes ya consumidos en la pantalla.
- Los usuarios echaron de menos una vista previa de todos los platos antes de ver el detalle de cada uno de ellos. La aplicación mostraba directamente el plato en pantalla, y el usuario se veía obligado a pasar por todos ellos para tomar una decisión.
- El hecho de que el único idioma disponible fuera el castellano causó problemas con los usuarios que no dominaban este idioma.
Mejoras implementadas
Después del design sprint tuvimos la oportunidad de mejorar algunos de los problemas de nuestro prototipo. Así, para los pain points comentados en el apartado anterior, creamos las siguientes soluciones:
- Creamos un segundo menú que se mostraría en el momento de los postres. Este menú excluía los platos principales y entrantes (que ya no se podían pedir) e incluía nuevas opciones, como cafés y cócteles.
- En la pantalla de resumen del pedido, los platos ya consumidos se diferenciaron de aquellos todavía por consumir para evitar confusiones.
- Se creó un menú intermedio que mostraba una vista previa de los platos antes de entrar al detalle en cada uno de ellos.
- Incluimos una opción para escoger el idioma en la pantalla principal de la aplicación.
- Realizamos algunos cambios de look and feel para incrementar el contraste entre algunos elementos o para mejorar la visualización.
Aquí os dejo un vídeo con el prototipo. En esta primera parte, podéis ver el recorrido que haría un usuario que pide los entrantes y platos principales.
En esta segunda parte, podéis ver el recorrido de un usuario que navega por los postres y que finalmente pide la cuenta y llega a la página final de valoración del producto.
Conclusiones y agradecimientos
¿Crear un prototipo y testearlo en 5 días? El lunes nos parecía imposible, pero a medida que fuimos avanzando y llegando a nuestras metas día tras día, comprobamos que es posible. Personalmente, estoy muy satisfecha con el resultado, ya que hemos conseguido lo que nos proponíamos.
Formar parte de un design sprint ha sido una gran experiencia. La mejor manera de aprender algo es practicándolo, así que poder participar en este sprint me ha dado una gran visión del funcionamiento de esta metodología que sin duda me será muy útil a la hora de aplicarla en mi vida profesional. Además, este ejercicio me ha servido también para seguir practicando con Sketch y con inVision, dos programas básicos para un profesional de UX.
Muchas gracias a todo mi equipo (Helena, Adrián y Marcello) por su profesionalidad y su apoyo durante todo el sprint. Gracias también a Pere y a Nuria por toda su ayuda y consejos. Y agradecimientos especiales a las personas que nos dedicaron un rato de su tiempo para probar nuestro prototipo: Gaia, Victoria, Clara, Ihab y Marina.
Ahora, ¡a por el siguiente proyecto!
Referencias
- The Design Sprint, GV.com
- Design Sprint, Wikipedia.org
