11 mini-detalles para tener en cuenta en las pruebas de usabilidad thinkaloud

Vi con mis propios ojos todas estas cosas inverosímiles, así que se las escribo para que no les suceda lo mismo.

1. Armemos consignas que no sesguen el camino de los usuarios

Detalle no menor, a menos que lo deseemos para probar un mecanismo o componente específico, si deseamos observar cómo el usuario resuelve problemas, enfoquemos las consignas a objetivos – no a tareas – sin marcar el camino a recorrer desde la misma pregunta.

Sí, es terrible: el usuario se podrá ir por cualquier lado y va a intentar resolverlo a su manera, pero es parte de lo que necesitamos descubrir.

Ej: Sobre un sitio de un artista:

Hagamos algo así como:

“Imagínate que deseas conocer la biografía de Concha Buika, ¿cómo harías para encontrarla en este sitio?”

En lugar de:
“Imagínate que deseas conocer la biografía de Concha Buika, utiliza el buscador para encontrarla.”

2. Redactemos las consignas cuidando el lenguaje (y la ideología!)

Mil cuidados con estas cosas (!)

  • Si vamos a escribir consignas que impliquen hijos, filtremos de antemano que tengan hijos realmente. Puedo contar mil cosas – lindas y no tan lindas – sucedidas al respecto ;)
  • Otro detalle fatal que he visto mil veces – sobre todo en culturas fuertemente católicas como México -, es una consigna diciendo: “Imagínate que te vas a casar y tu esposa…”. Ver que el usuario era gay y que al sentirse completamente incomprendido intente ponerse en un rol ajeno al suyo y que se sesgue la muestra. Por eso siempre utilizo la palabra “pareja”.
  • Y esta es peor y también la vi: armar consignas que incluyan enfermedades de seres queridos. Pliis, no. O más bien: cuidado.

3. Preparemos la información de apoyo con una tipografía grande

Si necesitamos imprimir información para que el usuario complete, que la tipografía sea grande. Es más, un tamaño de 14 px no están nada mal ;)

4. Preparemos a los observadores para que se contengan en silencio y no intervengan queriendo ayudar a los usuarios

Por Zeus, esto es muy difícil.
Cuando participen observadores del mismo proyecto, lo cual es super importante que suceda, hay que prohibirles que hablen hasta el final de la sesión.

Siempre dicen que no van a hablar, que entendieron que deben permitir que los usuarios no entiendan y se equivoquen; pero hablan. Cuidado con esto ;)

5. Filtremos desde la inscripción a los participantes para que no sean de la industria digital

No nos sirven programadores, diseñadores, ni personas de marketing digital.

Necesitamos gente ajena a nuestra industria que no esté viciada y que no venga a darnos una opinión profesional, sino a equivocarse desde el desconocimiento de la lógica interna del producto.

6. Si el usuario viene con alguien, que el acompañante espere afuera ;)

He visto dos cosas increíbles:

  • Que los acompañantes intenten colaborar en la prueba (!) Algo obvio: si tenemos dos personas frente a un test, entre ellas se ayudan y se potencian y la curva de aprendizaje que estamos midiendo ya no será de un usuario, sino de dos sujetos complotándose.
  • Que los acompañantes inhiban el comportamiento de la persona que está haciendo el testing.

Entonces, en caso de que los usuarios lleguen con acompañantes, super amablemente lo ideal es pedirles que vayan a dar una vuelta y vuelvan en breve ;)

7. Hagamos una introducción generando un ambiente flexible, informal y no de examen

Desde hace poco empecé a incluir – casi obligatoriamente – la frase inicial: “esto es un juego, nada de lo que hagamos está bien ni mal”.

Lo empecé a hacer luego de que un usuario mexicano se me quedó perplejo y cuando le pregunté qué le pasaba me contestó ultra francamente: “me inhibo porque sos mujer y argentina” (!)

Tenemos que dejar afuera todo lo que son tensiones y formalismos de “examen”.

De hecho, si hay observadores que sabemos que tienen intrínsecamente “mala vibra” (me encanta la frase “mala vibra”) o cambian la vibra o mejor les pedimos que no participen, para no contaminar el buen ambiente que debe respirarse ;)

8. Felicitemos a los usuarios aunque se equivoquen y no hayan seguido el camino que esperábamos

Ante cada cosa que haga el usuario, sea lo que esperábamos que hiciera o no, reforcemos su autoestima con un “Muy bien, está todo perfecto” para que tenga seguridad y siga avanzando… y se siga equivocando; que en definitiva es lo que necesitamos.

9. Miremos simpáticamente a los usuarios pero no respondamos sus preguntas hasta el cierre de la sesión

Si los usuarios hacen preguntas, simplemente respondemos: “Ahá, se te generó esta duda. Perfecto, al cierre la vamos a responder”.

10. Distingamos entre lo que observamos que hacen los usuarios vs. escuchamos que opinan

Mi frase de siempre es: una cosa es lo que los usuarios hacen, otra lo que interpretan que hacen y otra ultra distinta, es lo que dicen que hicieron.

Uno es el mundo de la operabilidad, otro es el mundo de la percepción.

11. Comprendamos que es un juego

Y por último: esta es la base de todo. Una prueba de usabilidad, desde mi perspectiva, es un juego donde los observadores interpretamos la forma de jugar del otro.

No es un examen. No es QA. Es un juego donde analizamos un vínculo humano-computadora.

Muchos éxitos :)

2 comentarios

  1. Hola Veronica!
    Ahora que estoy de vacas espero leer tu blog.

    • Verónica Traynor

      2 enero 2014 a las 22:44 pm

      Gracias Tomás! Que buena onda… Si estás de vacaciones te recomiendo para leer Don Norman. Amo a ese hombre :) Besos!!

Deja un comentario

Tu dirección de correo electrónico no será publicada.

*