Métodos de Diseño – Pruebas de usabilidad

Métodos de Diseño – Pruebas de usabilidad

Las pruebas de usabilidad son ese ingrediente mágico que permite que UX sea realmente UX. Son un método clave y fundamental que nos permite contrastar nuestras expectativas contra las de las personas para las que decimos estar creando una solución. Es un método versátil, útil y relativamente sencillo, que cuando se ha aplicado bien, nos ha dado productos y experiencias que han cambiado nuestras vidas como usuarios. Hoy veremos todo acerca de este método y cómo se aplica.

Contexto

Las pruebas de usabilidad son el paso más importante en un proceso de creación de productos.

Las pruebas de usabilidad no son nuevas, ni exclusivas a lo que hoy conocemos como UX. Desde la revolución industrial, los creadores de estas máquinas y nuevas tecnologías observaban a las personas y evaluaban cómo realizaban algo y hacían adecuaciones para hacerlo más fácil o que el sistema fuera más productivo.

Voy a atreverme a decir que las pruebas de usabilidad, son incluso más importantes que las entrevistas con usuarios. Yo puedo Diseñar algo sin haber hablado con el usuario, voy a empezar sin información y sin foco, pero nada me detiene de hacerlo. Pero nada me salva de que eventualmente eso que estoy haciendo en algún momento va a tener que ser usado por alguien.

Por ejemplo, tal vez hoy decido que quiero diseñar zapatos para cocodrilos. No haber hecho investigación no me detiene, pero el algún momento voy a tener que ponerle un zapato a un cocodrilo, y voy a tener que ver si sirven para lo que yo creo que sirven.

No estoy condonando no hacer investigación previa, lo que estoy diciendo es que la investigación previa guía la prueba de usabilidad, pero la prueba de usabilida es inminente. Es el punto de quiebre para construir algo centrado en las personas.Puede no haber otros métodos, pero sin prueba de usabilidad, no hay ni remotamente UX.

Dieter Rams, uno de los Diseñadores más brillantes de la historia, crea sus productos a partir de observar cómo la gente hace cosas. Déjenme les cuento uno de los inventos más sencillos, pero más trascendentes: un radio.

El señor Rams quería crear un radio. Antes, los radios tenían un botón para encenderlos y otra perilla para manejar el volumen. Dieter observó que a veces una persona encendía el radio y tenía que bajar el volumen inmediatamente. O que no notaba que el radio estaba encendido porque el volumen estaba bajo.

Dieter encontró la relación ¿Prender el radio y manejar el volumen deberían ser acciones separadas? El señor Rams inventó una perilla de volumen que, en la posición cero, apaga el radio, pero que en cuanto se comienza a subir, enciende el radio y le da control al usuario de poner el volumen que quiera. Simple. Funcional. 

Hoy en día ni nos daríamos cuenta de una genialidad de diseño que damos por hecho. Pero Dieter llegó a esa conclusión haciendo una prueba de usabilidad. Y tú podrías hacerlo también si aprendes a hacer pruebas de la manera correcta.

Definición

Una prueba de usabilidad es una metodología de investigación en la que un moderador o facilitador le pide a un participante que realice una tarea o un conjunto de tareas. Mientras el participante la realiza, el moderador observa y, dependiendo el contexto, realiza preguntas.

Como lo hemos visto con otros métodos, esta herramienta, que tiene estas características particulares, sirve más en ciertos momentos del proceso que en otros.

Si se acuerdan, en los Benchmarks hablamos de su valor como herramienta en el espacio de la solución, porque no nos aporta mucho valor en el espacio del problema, porque un Benchmark requiere una serie de criterios específicos, que si no conocemos no podemos evaluar.

Igual con las encuestas. Vimos que funcionan en el espacio del problema, pero de manera limitada, porque las fortalezas de la herramienta realmente brillan más en el espacio de la solución.

Las pruebas de usabilidad son un poco más complicadas, porque es una herramienta a la que se le pueden dar varios usos. Es como una multi-herramienta.

Partamos de la definición. Una prueba de usabilidad requiere:
1. Un usuario 

2. Que use algo

3. Para cumplir una tarea

4. Mientras alguien lo observa

Como con los otros métodos, las características de alguna manera nos indican en qué contexto, o en qué punto del proceso este es un método que aporta valor. Según estas características ¿Tú cuál crees que es el momento ideal para aplicarlo?

Primero pensemos en el espacio del problema. No sabemos del usuario, no sabemos de su contexto, no sabemos de su problema, cómo sucede, qué le molesta, etc. ¿Puedo hacer una prueba de usabilidad? Yo no tengo nada para que use, no tengo una solución… Pero puedo evaluar soluciones que ya existen.

Esto es lo que hizo Dieter. Rams sabía que quería mejorar el producto, pero no sabía en que radica la mejora. Así que el hizo una prueba de usabilidad, con el producto de alguien más… Genio ¿No? 

Es decir, podemos hacer una prueba de usabilidad en el espacio del problema. Si, cuando lo que queremos es descubrir el problema de alguien más, puede darnos un punto de información contextual, y se puede combinar como parte de una inmersión de exploración o de una serie de entrevistas.

Puede ser parte de mi información generativa.

Ahora CUIDADO CON COMBINAR MÉTODOS en una sola sesión porque puedes contaminar entre ellos. Si estás comenzando, no lo hagas. Ya haremos un programa de eso.

Ahora, el espacio de la solución. Obviamente puedo aplicar una prueba de usabilidad en el espacio de la solución para evaluar MI solución. Puedo generar información evaluativa. Y yo creo que es aquí dónde el método brilla.

Dentro del espacio de la solución, y dependiendo de qué tan “madura” esté siendo tu solución, hay una gran cantidad de formatos con el que puedes aplicar la herramienta.

  1. Remoto o en persona
  2. Moderado o no moderado 

Obviamente en una etapa de baja madurez, quieres observar lo más posible. Por lo que suele ser buena idea que sean pruebas en persona y moderadas. Incluso existe una variante que se llaman “pruebas de guerrilla”, que como el nombre indica, se aplican en condiciones que requieren cierta flexibilidad o no ser tan estricto.

Por el otro lado, si tienes un diseño ya bastante pulido y lo que quieres es que quede a prueba de balas, puedes crear una prueba en una plataforma como Maze, por ejemplo, y compartir una liga para que la gente haga la prueba solo, y esto te permite poder probar con muchas personas, porque no tienes que estar tú ahí con cada uno para ejecutarlo.

Por eso les digo que en esta etapa brilla esta técnica. Se trata de que la gente use eso que construíste, que puedas obtener información de primera mano de si la gente lo entiende, lo usa, lo valora. Y no vivir en la fantasía o en los cuentos de que “ojalá le entiendan” o el legendario “en mi compu si se ve”

Esa es la clave de una prueba, poner a alguien a hacer algo y ver cómo lo hace.

Y solo por no dejar. ¿Que NO es una prueba de usabilidad?

  • Hacer un focus group, proyectar una interfaz y pedirle a la gente que opine
  • Presentar una pantalla, explicar cada detalle, y preguntarle al usuario su opinión.
  • Pegar una imagen en una encuesta y mandarla

Si la persona no está usando algo, no es una prueba de -usabilidad-

¿Cómo se hace?

  1. Objetivo

Como todos los métodos, primero necesitamos tener un objetivo claro de qué queremos lograr con la prueba, y qué vamos a hacer con la data que vamos a obtener.

¿Vamos a hacer una prueba para compararnos con la competencia? ¿Queremos encontrar puntos de mejora? ¿Queremos asegurarnos que se cumple con un estándar de calidad o se usabilidad? ¿Queremos refinar la idea? ¿Saber si estamos listos para lanzar? 

El Objetivo dicta fuertemente exactamente cómo vamos a ejecutar la técnica. Incluso si la técnica hace sentido en primer lugar. Entonces, ya saben ¿Qué queremos saber? ¿De quién queremos extraer la información? ¿Para qué queremos saberlo?

  1. Audiencia

Ah… el famoso ¿Con cuántos usuarios?

Lo primero es -son más de cinco-. El estudio de Nielsen que todos citan destaca una metodología, no un número. Y llegar a la conclusión de que hay que probar con 5 personas lo único que exhibe es que no leíste el artículo en dónde se explica por qué.

Pero bueno, si no son 5 ¿Entonces cuántos?

Bueno, el tamaño de una muestra en un estudio de usabilidad debe contestar únicamente una cosa: ¿Cuál es la probabilidad de que encontremos todos los problemas con esta iteración del producto?

En el estudio de Nielsen, en ese caso en particular para ese producto, con esos 5 usuarios. La probabilidad estaba entre 55% y 95%. Nielsen lo promedió a 85%. Para alcanzar el 100% Nielsen hubiera tenido que probar con 50 usuarios por ronda, entonces concluyó que 85% es suficiente por ronda de pruebas. Ahora tú tienes que hacer tu propia estimación.

El concepto que queremos buscar aquí se llama “saturación”. Deberías hacer pruebas hasta que ya no aprendas nada de ellas, porque los usuarios te empiezan a dar los mismos resultados. Llegar a esa saturación varía dependiendo de lo que estás evaluando y la complejidad de la prueba.

Si ya te mareó todo este choro, la saturación típicamente la vemos entre 8 y 25 participantes. Cuando es una prueba para el espacio del problema es posible que con 10 usuarios ya satures y no aprendas más.

Las pruebas de usabilidad son relativamente más flexibles en términos de perfiles que una entrevista a profunidad, pero igual deberías cuidar de ejecutarlas con alguien que potencialmente es usuario de lo que quieres evaluar.

Hay productos que el usuario es un mercado abierto, pero al menos trata de llevar un registro de la edad o de el nivel de familiaridad con tecnología o con la marca, para que puedas ver si tu muestra está sesgada hacia un perfil en específico y compensar en rondas subsecuentes.

  1. Criterios (tareas)

Como lo vimos en los otros métodos, esta es la parte que le da sentido a la herramienta, y es la que todos se saltan.

En Benchmarks todos se saltan los criterios, en Encuestas todos se saltan las temáticas. Pues en Usabilidad, todos se saltan lo que en este contexto, definiremos como las tareas a evaluar.

Una tarea es una acción que el usuario debe realizar para cumplir una necesidad. Abrir una cuenta, escoger un producto, encuentra la dirección de un distribuidor, envía un mensaje. Es decir, es una acción que tiene un claro criterio de éxito.

Esto es lo que me encanta de las pruebas de usabilidad. O las cosas funcionan o no. No hay tintas medias. O el usuario puede completar la tarea o no.

Entonces, tienes que definir las tareas que quieres evaluar en tu experimento. Tal vez estás haciendo un proceso de contratación y quieres evaluar 3 tareas:

  • Que el usuario lea y entienda las características del producto
  • Que el usuario introduzca su información
  • Que el usuario contrate y entienda lo que contrató

Esp significa que NUNCA le das algo al usuario a ver qué hace. Nadie, nadie, nadie nunca abre una app para ver qué hacer o entra a una página a ver qué se encuentra. Siempre tenemos un propósito en mente con las acciones que hacemos. El usuario necesita una tarea.

Cuando estás haciendo una prueba en el espacio del problema, quieres encargarle una tarea y que muestre cómo la cumple.

Cuando estás en el espacio de la solución, tu ya traes una data de que “debería” hacer para cumplirla. Por lo tanto puedes contrastar tu flujo “ideal” con lo que el usuario hace en realidad.

Tienes que saber cuánto tiempo toma, cuántos errores son tolerables y cuál es la condición de éxito. Para que luego tu puedas comparar cuántos clics dio por error, cuántos pasos o pantallas se saltó, o si llegó a un callejón sin salida o de plano nunca completó la tarea.

Esta es la parte que todos hacen mal.

Para que podamos hacer una prueba para “mejorar” algo, es porque tenemos una métrica exacta de qué es peor y qué es mejor. Si no sabes cuánto tiempo le toma al usuario cumplir una tarea ¿Cómo vas a mejorar el tiempo que toma realizar la tarea?

Cuando vimos el Solcast de Usabilidad, hablamos de que no hay opiniones en Usabilidad. Medimos eficiencia, eficacia y satisfacción, numéricamente. Número de errores, tiempo, tareas completadas.

  1. Ejecución

Con tus tareas definidas, ahora estamos listos para ejecutar.

Dependiendo de tu objetivo, vas a preparar una sesión moderada o no moderada, remota o presencial. Las pruebas de usabilidad suelen ser muy rápidas. En mi experiencia te avientas un estudio con 3, 4 o 5 tareas en 10-15 minutos, con todo y preguntas al usuario.

Puedes incluso ir a un lugar con muchos usuarios, a una plaza o un centro de atención a clientes y evaluar con la gente que está ahí. A eso le llamamos pruebas de guerrilla.

Obviamente si estás en una etapa muy inmadura de tu producto, probablemente quieras si tener como un espacio más completo de tiempo para profundizar más con el cliente.

Una sesión típicamente es así

  1. saludas al cliente
  2. le dices que quieres evaluar algo con él. Que no es una prueba para él, sino que lo que quieres saber es si esto está bien hecho para que el usuario lo use.
  3. Trata de grabar la pantalla, si es posible graba al usaurio también
  4. Le dices la tarea al usario, evita usar palabras que el usuario va a ver en la pantalla. Si quieres evaluar algo que incluye un botón que dice “Comprar” no le pidas que compre algo.
    La tarea se dice de manera genérica, para sesgar lo menos posible:
    “Imagínate que quieres sacar una tarjeta ¿Cómo lo haces?”
    Imagínate que estás en tu trabajo, y que te dijeron que tienes que hablar con Fulanito. Tú quieres usar tu nueva intranet para encontrar quién es ¿Qué te imaginas que tienes que hacer?
  5. Observas al usuario intentarlo. Le pides que te exprese en voz alta lo que va pensando. DEJALO TERMINAR LA TAREA. Si te pregunta cosas dile “tú dónde crees? ¿Qué esperarías ver ahí? Picas ahí y ves que no pasa nada ¿Qué esperabas ver? Si ves que de plano está atorado lo detienes y tu marcas la tarea como no completada.
  6. AL TERMINAR las tareas le haces preguntas:
    ¿Qué te llamó la atención? Noté que aquí titubeaste ¿Qué pasó? ¿Qué crees que le falta? ¿Lo usarías ahorita? ¿Cómo se compara con X? ¿Qué te sorprendió? etc.
  7. Le agradeces y concluyes.

Si es una prueba no moderada, es básicamente lo mismo, pero pues no vas a estar ahí. En una plataforma como Maze, preparas tu prueba, tienes que dar la instrucción, y al terminar puedes poner preguntas.

  1. Análisis

Las pruebas de usabilidad son relativamente fáciles de analizar, porque realmente todo orbita alrededor de una pregunta ¿El usuario completó la tarea o no?

Para las pruebas de usabilidad solemos llevar una matriz. Usuario vs Tarea 1, tarea 2, tarea 3. Lo logró, no lo logró. Y las notas ¿En qué pantalla se atoró? ¿Qué texto le resultó confuso? ¿Qué le tomó mas tiempo?

Si es una muestra de un producto poco maduro, seguramente quieres tomar esos hallazgos para una nueva iteración, hasta que tu muestra poco a poco se vaya saturando de usuarios con los que la prueba no falla.

En productos más maduros, te permite incluso estimar ya cómo se va a comportar el producto cuando salga a mercado y cuántas conversiones podrías esperar o abandonos.

En alguno de los startups con los que trabajé, un founder una vez me dijo: No puedes esperar converitr 5mil usuarios si no conviertes 1000, 100, 5. Y eso es algo con lo que siempre me he quedado.

Las marcas para las que trabajamos creen que pueden hacer una solución que funciona para 10 millones de personas, pero no pueden lograr que ni las personas que la están construyendo lo entiendan o completen las tareas.

Las pruebas de usabilidad son el antídoto para eso, y las marcas más exitosas del mercado las usan. No es un secreto, no es difícil, no es lento, no es tardado. Literal lo único que requiere es tener tiempo para eso. 

Cierre

Vamos a dejarla ahí. Si aprendieron algo invítenme un café con la liga en la descripción, compartan este episodio a quien creen que puede servirle y déjenme un like y un comentario platicandome lo que aprendieron. 

Háganme llegar sus dudas por acá, Twitter o Linkedin para contestarlas en las siguientes ediciones y no olviden revisar la descripción del video para notas y referencias. 

Nos vemos el próximo miércoles y… Felices trazos.

Notas del programa

The Beginner’s Guide to Usability Testing [+ Sample Questions]
https://blog.hubspot.com/marketing/usability-testing

Usability Testing 101
https://www.optimalworkshop.com/learn/101s/usability-testing/

A Beginner’s Guide to Usability Testing
https://maze.co/guides/usability-testing/

How to Conduct Usability Testing in Six Steps
https://www.toptal.com/designers/ux-consultants/how-to-conduct-usability-testing-in-6-steps

How to Determine the Right Number of Participants for Usability Studies
https://www.uxmatters.com/mt/archives/2016/01/how-to-determine-the-right-number-of-participants-for-usability-studies.php

Usability Testing 101
https://www.nngroup.com/articles/usability-testing-101/

A beginner’s guide to user & usability testing
https://www.hotjar.com/usability-testing/

Compartir:FacebookTwitter
Súmate a la discusión