Trucos y tratos con el “maldito usuario”

Los estudios con usuarios tienden a provocar cierta pereza en un proceso de desarrollo de producto, a menudo, desde la distancia, se tiene la sensación de que el usuario es una partícula minúscula diluida entre los porcentajes de google analytics. Pues si…en cierto modo lo es, especialmente para los departamentos de marketing, pero esa es solo una de las múltiples aportaciones que nos puede brindar nuestro subestimado y (a su vez) mitificado usuario, también conocido como “maldito usuario” en círculos reducidos. Sin duda lo que entendemos por “usuario” es algo más que una micropartícula monitorizable por profesionales de la business inteligence. Además de eso, resulta ser una fuente de información tremendamente fiable y mucho más aprovechable de lo que se tiende a imaginar. El problema acostumbra a ser el hecho de enfrentarse a una persona en lugar de a un dato, eso siempre intimida algo más, además es más lento, menos automático y desplaza a la mayoría de profesionales de su zona de confort. Imaginemos que superamos ese escollo y nos aventuramos a organizar un pequeño estudio con usuarios para descubrir los detalles de los índices de rebote, puntos de fuga o para poner a prueba un prototipo.

Bueno, vamos a enfrentarnos al “maldito usuario” face to face. Planteemos un test de tareas, la técnica reina de testeo con usuarios en usabilidad y UX. Las instrucciones para un test de tareas son claras y relativamente sencillas, hay que proponer unas tareas al usuario para poder observar como realiza ciertas acciones que reproduzcan un uso natural del producto. Gracias a esas acciones se podrán tomar datos relevantes sobre la tarea como el tiempo en completarla, el éxito o fracaso de la misma (en varias modalidades), número de clicks, navegación, etc. Resulta de vital importancia relacionar estos datos cuantitativos con los datos cualitativos que obtendremos de los comentarios de los usuarios (aplicando el protocolo think aloud) y con las observaciones que vayamos a anotar sobre cada tarea a lo largo de la sesión.

Bien, pero…¿A que nos enfrentamos? Son muchas las situaciones que pueden darse en un test con usuarios reales, pero vamos a destacar 3 aspectos que debemos tener claros cuando tenemos delante al “maldito usuario”.

1.- Facilitación; Cordialidad distante

La función del facilitador del test consiste en dar las instrucciones pertinentes al usuario, claras sencillas y concisas, siempre en actitud amable y cercana, aunque sin llegar a una proximidad excesiva, nuca invadiendo un terreno personal. El facilitador es un ser amistoso pero no un amigo. La responsabilidad, nada trivial, del facilitador consiste en aplicar el diseño de test de modo preciso, un error de facilitación puede contaminar los datos muy fácilmente y hacerlos completamente inservibles. Se da la circunstancia de que datos de interés en un test, únicamente se producen si el usuario está cómodo, confiado y actúa de manera natural. De modo que la misión del facilitador y su función estricta es procurar que eso suceda aplicando un principio de cordialidad distante, el usuario debe sentirse seguro, confiado, no juzgado y distendido para actuar con naturalidad, pero a su vez no debe percibir un contexto familiar o excesivamente informal que le distraiga de la prueba, ya que ese extremo contamina frecuentemente los datos de testeo. En caso de llevar a cabo una facilitación con un conocido íntimo o familiar hay que prestar más atención de la habitual a la conducción del test, es mucho más fácil desconcentrarse y caer en un trato coloquial que nos contamine los resultados de las pruebas.

2.-El usuario es incapaz de ser culpable

El test de tareas tiene un pequeño e inevitable problema de diseño, tiene formato de examen, al usuario le provoca la sensación de que se le está evaluado a él, a sus habilidades, en lugar de al producto, así que cuando no consigue realizar una tarea tiende a sentirse frustrado. Algunos usuarios descargan su frustración contra la aplicación, lo cual nos resulta conveniente (siempre el usuario no manifieste una tendencia obsesiva al respecto), pero muchos otros en lugar de echarle la culpa al producto se la echan a sí mismos. La autoinculpación (fenómeno bastante habitual) en usuarios que no consiguen realizar con éxito una tarea es algo que debemos evitar a toda costa, eso perjudica la fiabilidad de las valoraciones y comentarios y ataca nuestro “setting experimental” (ese ambiente de confianza y de “no ser juzgado” que conseguimos al facilitar con cordialidad distante).

En los casos en los que se detecte esa tendencia auto inculpatoria en el fracaso de tareas hay que tener en cuenta que el usuario no ha entrado en la mecánica del test correctamente, puesto que presupone que tiene la capacidad de equivocarse, y no es así. En un test de tareas se evalúan los errores de diseño de una aplicación o producto, el usuario no tiene posibilidad de equivocarse y debe ser consciente de ello. ¿Cómo?, primeramente explicándoselo, -no estamos evaluándote a ti sino al producto- si aun así vemos que el usuario se inculpa debemos flexibilizar nuestra distancia (la de cordialidad distante) y animarle a criticar el producto de modo sincero, quitándole hierro al hecho de valorar negativamente al producto, asegurándonos de que entienda que no puede ofender al equipo de testeo por no agradarle alguna función o proceso, y recordándole que sus valoraciones nos brindan una oportunidad de oro para entender qué tipo de problemas tiene la gente que utiliza el producto que testeamos. Los errores nos ayudan mucho más que los aciertos en este tipo de pruebas, así que hay que procurar que el usuario esté en actitud productiva (productiva de información), si el usuario tiene la actitud adecuada nos brindará información prácticamente imposible de obtener de otra manera que no sea el testeo presencial. ¿Y si…se diera el caso de que un test presencial con usuarios de verdad, nos brinda una información similar a la que ofrece google analytics, que significaría?, muy sencillo, significaría que nuestro test ha sido lamentable. Sería como llegar a los mismos resultados con un hacha que con un bisturí, no habríamos utilizado correctamente una de las dos herramientas.

3.-Uso de la paradoja

Para finalizar, un tercer aspecto de gran utilidad en testeo con usuarios, es el uso de pequeñas paradojas en momentos determinados de la sesión. Recordemos que los mejores resultados se dan cuando el usuario está lo bastante confiado y relajado como para actuar naturalmente, para favorecer ese objetivo a menudo se utilizan mensajes de gran carga paradójica como por ejemplo al inicio de la sesión cuando le decimos:
-Puedes abandonar el test en el momento en que lo creas necesario- ¿Porque le decimos eso? ¿Queremos acaso que abandone en cualquier momento?, obviamente no, estamos precisamente provocando el efecto contrario, al darle la opción de parar y tomarse un descanso le des estresamos y provocamos que raramente el usuario quiera abandonar el test. Es como si alguien nos dijera: ¡No puedes salir del edificio! ¡Las puertas estarán cerradas durante 2 horas!...inmediatamente nos estresaremos y querremos salir del edificio antes de esas 2 horas. Con los mensajes paradójicos al inicio del test provocamos el efecto contrario, evitar que el usuario tenga prisa por terminar o se agobie por tener escapatoria hasta el final de la sesión. Por tanto, el hecho de utilizar frases como:- puedes tomarte un descanso cuando quieras- se utilizan precisamente para que el usuario no pida un descanso, aunque si lo pide…habrá que dárselo.

Bueno…por hoy estos son los tres aspectos que, entre muchos otros, creo dignos de mención sobre el maravilloso mundo del testeo con usuarios. En próximos posts sobre actividades y seminarios del PUX continuaremos viendo aspectos fundamentales sobre la aplicación de técnicas de user research con nuestros bien amados, y bien odiados usuarios.

продвижение сайтов продвижение сайтов