«¿Logrará el usuario alcanzar su objetivo?» Esa es la pregunta clave de la usabilidad y es la pregunta que también se ha planteado Lottomatica para uno de sus últimos proyectos innovadores.
Para tratar de averiguarlo, el equipo multifuncional compuesto por el departamento de UX, Producto e Investigación de Mercado ha contratado a nuestro equipo compuesto por AppQuality y Ergoproject. Para hacerlo, le preguntamos a la única persona capaz de responder: el propio usuario, o más bien un grupo de usuarios acompañados y escuchados por investigadores de UX mientras utilizan un servicio. La muestra se seleccionó entre la comunidad de probadores de AppQuality mediante la identificación de usuarios reales del servicio; por su parte, Ergoproject aportó sus investigadores de UX para estudiar las características de los usuarios, su comportamiento y sus necesidades.
.
De la unión de las fuerzas de estas dos realidades innovadoras ha tomado forma el proyecto de prueba de Lottomatica, que ha demostrado ser muy interesante tanto desde el punto de vista del «modus operandi» como de los resultados; tanto que nos ha llevado a decidir compartir no solo el resultado sino también, y sobre todo, el proceso paso a paso, prueba a prueba.
Desde hace más de diez años, Ergoproject presta apoyo a grandes empresas públicas y privadas a través de actividades de investigación, consultoría y formación sobre cuestiones relacionadas con el rendimiento humano y la calidad de las interacciones con los productos/servicios digitales en términos de errores de uso, estado funcional, accesibilidad, usabilidad y experiencia del usuario.
AppQuality es la empresa líder en Crowdtesting en Italia. Gracias a esta metodología y a sus soluciones, es posible encontrar bugs y limitaciones de UX en cualquier producto digital (aplicaciones, páginas web, comercio electrónico, dispositivos IoT, chatbots, etc.) a través de una multitud de probadores que van desde expertos en la búsqueda de errores hasta usuarios ordinarios (como los usuarios de las máquinas tragaperras de Lottomatica).
Se puede explicar una prueba de usabilidad a partir de dos perspectivas opuestas pero complementarias. La primera (teórica) se centra en cómo funciona el método, mientras que la segunda (práctica) en por qué debe usarse y qué resultados se pueden obtener. Esta última es la parte en la que nos centraremos para explicar el trabajo realizado con Lottomatica para definir un marco de análisis capaz de guiar la toma de decisiones de diseño de su nuevo producto phygital para sus clientes.
La experiencia nos parece especialmente interesante porque muestra de forma práctica cómo los datos obtenidos de la evaluación y la investigación con los usuarios (User Research) deben ser parte integral de un proceso de diseño y desarrollo.
Es necesario tener en cuenta, de hecho, que la actividad de User Research, aunque se lleva a cabo con precisión desde el punto de vista metodológico, no puede alcanzar ningún objetivo si no se integra con el funcionamiento normal del producto. En nuestra experiencia, demasiados informes de pruebas de usabilidad llegaron tarde o se quedaron en un cajón porque no había tiempo para leerlos y analizarlos en profundidad. No es casualidad que desde hace algún tiempo se hable de Design Operations (DesignOps) y Research Operations (ResearchOps) que tienen como base la integración de la gestión y el empoderamiento de las personas, los procesos y las herramientas utilizadas para la investigación y el diseño de productos capaces de aportar un valor añadido a los clientes y al negocio.
No nos detendremos más en la teoría y volveremos a nuestro caso práctico.
El objetivo era apoyar a Lottomatica en la evaluación y mejora del diseño de la experiencia de sus clientes, completamente nueva y multicanal, con un servicio que preveía precisamente el uso simultáneo de un m-site accesible a través de smartphones y de un tótem presente en el interior de los establecimientos físicos.
Hemos imaginado un recorrido que, partiendo de la más profunda comprensión de las diferentes dinámicas de interacción con el servicio, les apoyara en la mejora iterativa del diseño hasta alcanzar un MVP (producto mínimo funcional) listo para el desafío de salir al mercado.
Explicaremos cómo lo hemos hecho.
Comenzamos realizando una prueba de usabilidad con 16 usuarios que permitiera a todo el equipo del proyecto alinearse con la calidad de la experiencia e identificar las áreas en las que intervenir para mejorarla. Mientras el investigador moderaba las sesiones con los usuarios dentro de una sala de apuestas simulada, las diversas partes interesadas del proyecto seguían desde la «sala de observación» cada comportamiento y lo comentarios y, entre una sesión y otra, lo discutían entre ellos y con los otros investigadores presentes (Customer Success Manager, encargado de tomar notas y encargado de la estrategia).
Para profundizar en la comprensión de la experiencia del usuario con esta interacción multidimensional entre el teléfono y el tótem, se empleó un dispositivo de seguimiento ocular que permitió registrar y ver en tiempo real lo que se observaba, durante cuánto tiempo y en qué secuencia.
Al final de cada uno de los tres días de prueba, se elaboró un informe que permitió consolidar y priorizar los hallazgos para poder configurar en «tiempo real» la estrategia de intervención con el equipo de diseño y desarrollo incluso antes de recibir el informe con todos los resultados del trabajo.
Teniendo en cuenta la experiencia reciente de los usuarios que ven, usan y comentan el servicio, el equipo del proyecto decidió abordar una segunda fase de investigación con el objetivo de profundizar en algunos temas más centrados en la redacción y la comunicación de la experiencia, que surgieron durante la primera fase. Para esta segunda fase, por lo tanto, se decidió actualizar el prototipo solo a nivel de la interfaz de usuario sin involucrar aún al equipo de desarrollo. Este proceso permitió entregar directamente el prototipo final a desarrollar para el lanzamiento.
A partir de aquí nació una segunda prueba de usabilidad, realizada con 19 usuarios, con un objetivo diferente en cierto modo al del primer estudio. Por un lado, este estudio pretendía asegurarse de que los cambios realizados fueran mejoras (tanto en términos de métricas como en términos de comportamientos observados), pero por otro lado también quería dar soporte a microsprints de diseño.
En la práctica, el estudio siempre se llevó a cabo con la lógica de «visualización en directo» (las partes interesadas siguieron las sesiones en tiempo real), las tareas (tareas o casos práctico) que se les pidió que realizaran a los usuarios fueron las mismas, pero se introdujeron dos variantes que cambiaron el enfoque de la perspectiva de «entender» a la de «mejorar»: la estrategia de moderación de las sesiones cambió y los informes al final del día condujeron directamente a pequeñas intervenciones correctivas, (por ejemplo, cambiar la posición y las características gráficas de un CTA, refinar la copia y la microcopia) que se verificaron a continuación al día siguiente.
Nunca hay suficiente tiempo para resolver todos los problemas de una interfaz de usuario o para satisfacer todas las necesidades de un usuario. Llega un momento en el que hay que proceder y es necesario estar en condiciones de evaluar el riesgo que se asume al liberar una solución en un estadio preciso de madurez.
En el caso de la prueba de Lottomatica, la mayoría de los problemas se identificaron con el primer estudio y se resolvieron durante las iteraciones del segundo, pero durante las sesiones surgió una pregunta que quedó sin respuesta: ¿cuánto afectaría este nuevo canal a un canal ya existente, fundamental para Lottomatica? De hecho, parte de las intervenciones de mejora habían servido para aumentar la visibilidad y la comprensibilidad de algunas CTA que favorecían la conversión de nuevos clientes, pero podrían afectar la experiencia de los clientes actuales en otros flujos.
El último estudio tuvo como objetivo proporcionar datos para evaluar este impacto y para hacerlo se necesitó una muestra más grande de usuarios (para aumentar la capacidad del estudio para detectar cualquier diferencia entre las diferentes soluciones de diseño), manteniendo los tiempos de ejecución y el intercambio de resultados al mínimo.
Por esta razón, se optó por una prueba de clics remota no moderada realizada con una muestra de 50 usuarios a los que se les pidió que usaran dos versiones (A y B) de la CTA tanto para comprender si esta afectaba al canal de otros usuarios como para identificar la interfaz de usuario preferida.
El estudio, lanzado el viernes, arrojó los resultados el lunes y permitió verificar que la interacción con el canal principal no se hacía más compleja debido a la UI refinada durante las pruebas anteriores.
Repasemos brevemente las etapas del proyecto:
Imaginar lo que hace el cliente no es suficiente. Si bien el equipo de Lottomatica tenía a su favor un profundo conocimiento de sus usuarios y una fuerte experiencia en el campo de la UX, el paso de la teoría a la práctica siempre esconde dificultades.
Poder verificar las propias suposiciones sobre el cliente, sobre todo con interacciones nuevas como es el caso de phygital, ha hecho que sean más conscientes con respecto a qué dirección a tomar para mejorar el producto y se sientan más seguros a la hora de presentar, con los datos en la mano, las elecciones de diseño al negocio.
En detalle, evaluar iterativamente los prototipos con los usuarios abrió una ventana al uso «real» que permitió:
En todas las fases de prueba participaron exclusivamente probadores mayores de edad.
Caso práctico redactado en colaboración con Simon Mastrangelo, cofundador y administrador de Ergoproject Srl.