Una de las cosas que más me apasiona a parte de ser Tester es la Cocina. He notado que hay mucha similitud entre la cocina y la usabilidad. Por ejemplo si comparamos la usabilidad con la sal cuando cocinamos una comida y el punto de sal está bueno nadie dice – que bueno quedó el punto de sal en la comida! simplemente la degustamos y celebramos el sabor de los alimentos en general, pero si en una comida se nos va la mano con la sal o le echamos menos, todos vamos a notar su ausencia o presencia en abundancia y comentaremos respecto al punto de sal. Lo mismo pasa con la usabilidad, si en una aplicación notamos que presenta una mala usabilidad enseguida vamos a comentar al respecto, pero si la aplicación es intuitiva y podemos interactuar con facilidad estoy segura que no vamos hablar sobre esto.
Imagen de KatineArt en Pixabay
Lo mismo nos pasa a todos los que estamos leyendo este post, que cuando accedemos a una aplicación y no logramos encontrar en poco tiempo la información que buscamos o no presenta un diseño agradable, seguro nos molestamos, enojamos, frustramos y no tardamos en abandonarla.
Una buena usabilidad es la clave fundamental para lograr que los usuarios se sientan atraídos y permanezcan más tiempo en nuestras aplicaciones; por lo que conocer y poner en práctica los factores fundamentales para el desarrollo de una aplicación usable es esencial en estos tiempos.
Debemos siempre recordar que nosotros no somos el usuario final de nuestras aplicaciones porque como dice Jeff Bezos el Director Ejecutivo de Amazon, en internet si tienes un cliente descontento no se lo dice a 6 amigos, se lo dice a 6000.
¿Cómo prepararnos?
Las pruebas bien hechas hay que realizarlas con un grupo de usuarios con ciertas características, pero si esto no entra dentro de nuestras posibilidades, al menos haciendo una validación con otras personas que no conozcan el sistema ya vamos a tener parte de los beneficios de este tipo de evaluación.
Sobre ese tipo de prueba con usuarios que son un poco más “informal” o de “guerrilla” cómo se le suele llamar vamos a estar abordando en esta charla.
Existen muchas técnicas en las que podemos evaluar nuestra aplicación con la ayuda de los usuarios, una de ella es la entrevista donde se le solicita al Usuario que lleve a cabo tareas determinadas en la aplicación y debe existir una persona que guíe la evaluación que sería un Moderador, una persona que sería el Tomador de Notas para que vaya tomando nota de lo que va realizando el usuario mientras navega por la aplicación y el Observador que es la persona interesada en el producto.
Descripción de roles
El facilitador o moderador es una persona neutral que realiza una sesión de prueba de usabilidad (y, por lo tanto, es un experto en usabilidad). El moderador es la única persona que puede hablar con el participante de la prueba durante la sesión de prueba de usabilidad.
El participante de la prueba de usabilidad es un usuario representativo que resuelve tareas típicas en una prueba de usabilidad.
El tomador de notas es un experto en usabilidad que registra importantes hallazgos de usabilidad.
Los observadores son generalmente interesados que están interesados en el producto de software o en las características requeridas para satisfacer sus necesidades y expectativas.
¿Cuántos usuarios necesitamos?
Esta es la pregunta del millón cuántos usuarios necesitamos para realizar las pruebas de usabilidad o este tipo de entrevistas?
Muchos se plantean que para poder estar seguros que mi aplicación es usable tengo que probar con 100 usuarios, pues no es necesario el número mágico es 5, como se muestra en la siguiente gráfica después de aproximadamente 5 usuarios ya estaríamos obteniendo los mismos resultados.
Gráfica del artículo Why you only need to test with 5 users
La idea acá sería realizar varias iteraciones con 5 usuarios y según el feedback en cada iteración, ya conoceríamos que debemos mejorar o cambiar y con las mejoras implementadas vamos a ir a realizar la siguiente iteración.
Distribuir presupuesto y esfuerzos
La curva de la gráfica anterior muestra que necesitamos 15 usuarios en total para descubrir todos los problemas de usabilidad en el diseño. Entonces ¿por qué Nielsen recomienda hacer las pruebas con un menor número de usuarios por iteración?
La razón principal es que sería mejor distribuir el presupuesto y esfuerzo para las pruebas de usuario en muchas pruebas pequeñas en lugar de gastar todo en un solo estudio.
Entonces, si debemos encontrar 15 usuarios para hacer nuestras pruebas es preferible que dividamos las pruebas en 3 estudios con 5 usuarios cada uno.
Es importante realizar más estudios porque el objetivo real de las pruebas de usabilidad esmejorar el diseñoy no solo documentar sus debilidades.
Distribución de estudios
Después de realizar el primer estudio donde encontraremos un aproximado de 85% de los problemas, y realizando el rediseño pensamos que ya solucionamos todos los problemas que habíamos detectado pero como nadie puede diseñar la interfaz de usuario perfecta, lo más común es que este rediseño muchas veces no soluciona los problemas o introduce nuevos problemas.
Además, el segundo estudio con 5 usuarios descubrirá aproximadamente un 10% de los problemas de usabilidad originales que no se encontraron en la primera ronda de pruebas. En este segundo estudio se podrá profundizar más en temas como la estructura fundamental de la aplicación, se podrá evaluar cuestiones como la arquitectura de la información, el flujo de tareas y la correspondencia con las necesidades del usuario. Estos problemas importantes muchas veces están ocultos en el primer estudio porque el usuario tiende a enfocarse en problemas de usabilidad más simples que le impiden enfocarse en problemas con más profundidad en la aplicación.
Y todavía quedará un aproximado del 5% de los problemas originales que tendrán que esperar hasta que se realice el tercer estudio.
¿Por qué no probar con 1 usuario?
Podríamos llegar a pensar que 15 estudios con un usuario es mejor que 3 estudios con 5 usuarios. Incluso la gráfica mostraba que aprendemos más del 1er usuario que de los posteriores, pero por qué no se recomienda probar solamente con 1 usuario por dos razones:
- Siempre existe el riesgo de ser engañado por el comportamiento de una sola persona que puede realizar ciertas acciones por accidente o de manera no representativa. Incluso 3 usuarios son suficientes para tener una idea de la diversidad en el comportamiento de los usuarios y comprender qué es único y qué se puede generalizar.
- Existe un costo inicial fijo en la planificación y ejecución de un estudio: es mejor depreciar este costo inicial en función de los hallazgos de múltiples usuarios.
Pero realizar al menos la prueba con 1 usuario es mejor que no realizarla con ninguno, por lo que pudimos ver en la gráfica obtenemos más del 30% de los errores de usabilidad con el primero usuario.
¿Cuándo probar con más usuarios?
Necesitamos probar con usuarios adicionales cuando un sitio web tiene varios grupos de usuarios muy distintos. La fórmula que hemos visto hasta ahora solo es válida para usuarios que utilizarán el sitio de forma bastante similar.
Si, por ejemplo, tiene un sitio que será utilizado tanto por niños como por padres, los dos grupos de usuarios tendrán un comportamiento lo suficientemente diferente como para que sea necesario probarlo con personas de ambos grupos.
- De 3 a 4 usuarios de cada categoría si se prueban dos grupos de usuarios.
- 3 usuarios de cada categoría si se prueban tres o más grupos de usuarios.
Siempre planificar con al menos 3 usuarios para asegurarnos de haber cubierto la diversidad de comportamientos dentro del grupo.
Además debemos considerar más usuarios en los siguientes tipos de evaluación:
- Estudios cuantitativos (con el objetivo de obtener estadísticas, no información): probar al menos con 20 usuarios para obtener números estadísticamente significativos.
- Card sorting: probar al menos con 15 usuarios por grupo de usuarios.
- Eyetracking: probar con 39 usuarios si queremos mapas de calor estables.
Conclusiones
He participado en varios proyectos donde me hacian recordar a Bilbo el famoso personaje de la película “El Señor de los Anillos”.
Me hacían mucho recordarlo porque como mismo Bilbo no enseñaba su anillo a nadie, ellos no querían que la aplicación la vieran los usuarios antes del lanzamiento o intentaban postergar las pruebas de usabilidad con usuarios o nunca se llegaban a realizar.
Pero al final se llevaban tremenda sorpresa cuando un usuario externo al equipo nos daba feedback de la aplicación porque muchas cosas que se habían omitido o pasado por alto para ellos era muy difícil comprender.
Esto nos pasaba porque los del proyecto ya lo entendíamos a la perfección el funcionamiento y asumíamos que todos lo iban a comprender y les sería usable. Cuando ya la aplicación estaba totalmente terminada y necesitábamos hacer reajustes de las funcionalidades por supuesto esto nos conllevaba más esfuerzo y tiempo en esas etapas tardías del proyecto, en cambio si hubiéramos realizados las pruebas con usuarios lo antes posible los cambios hubieran sido mínimos y sin mucho esfuerzo.