Tree testing

Esta guía amplía la ficha de Tree testing. El tree testing es una técnica que se inscribe, dentro de un proceso de diseño centrado en el usuario, en la evaluación específica de la arquitectura de la información. A partir del planteamiento de varias tareas a los usuarios, permite comprobar:

• Si la estructura que se propone es intuitiva y permite encontrar con facilidad los contenidos buscados.
• Si el rotulado (terminología utilizada) es inteligible y se relaciona de manera óptima con los contenidos.

Definir el alcance

El primer paso al plantear un tree testing consiste en definir el foco, es decir, para qué se realiza la evaluación: ¿cuál es su objetivo y qué cuestiones específicas se quieren comprobar?

También hay que determinar cómo se realizará el test:

• Presencial, con el evaluador y el participante en la misma ubicación.
• Remoto, mediante herramientas en línea que permiten hacer tests a distancia.

Definir el foco permite saber cómo planificar las sesiones y qué habrá que observar cuando se lleven a cabo.

Definir el perfil de los participantes y hacer la captación de estos

Los usuarios que proporcionan información más relevante son los que tienen características parecidas a las de las personas del proyecto.

En términos generales, se recomienda que en un tree test participen entre siete y nueve usuarios, puesto que se considera el número ideal con el que se obtiene mayor cantidad de información relevante y no reiterativa. No obstante, este número se tiene que determinar de acuerdo con las condiciones de cada proyecto y teniendo en cuenta el número de personas definidas. Para que los resultados sean significativos, hay que tener más de un participante por persona.

Definir el guion de las sesiones

El evaluador tiene que preparar un guion o protocolo que determine qué pasos hay que seguir en la sesión. Para que sea eficiente, la sesión tendría que durar menos de una hora, puesto que el cansancio del usuario reduce su capacidad de responder a tareas y preguntas.

Aunque el contenido de las sesiones se puede flexibilizar dependiendo del comportamiento del participante, es importante partir de un guion que defina lo siguiente:

• Presentación. Cómo se presenta el evaluador y cómo explica el objetivo de la investigación. Es importante garantizar el anonimato de la información que se recoge y del usuario que participa.
• Cuestionario demográfico. Antes de iniciar el test, se pregunta brevemente al usuario sobre cuestiones demográficas que pueden ser relevantes para el proyecto (edad, género, ocupación, nivel de experiencia con la tecnología, entre otros). Hay que evitar incluir preguntas que no sean relevantes o excesivamente personales.
• Formulario de consentimiento. En caso de que la sesión se grabe o de que se utilicen datos identificables del usuario, es necesario que este firme una hoja de consentimiento. Si el usuario no quiere ser grabado, la observación se tendrá que llevar a cabo sin registro.
• Tareas del test. Enunciado de las tareas que se plantearán al usuario. Estas tareas tienen que redactarse de manera que contextualicen la situación y no sesguen los resultados.
  Por ejemplo, en el test de una web plantear una tarea como «Busca una receta con pollo» no es correcto porque no contextualiza la situación (el usuario tendrá que realizar una tarea sin ninguna razón concreta). Por otro lado, la palabra busca puede conducir al usuario a utilizar directamente la opción de busca, sesgando los resultados.
  Un enunciado mejor sería «Esta noche tienes invitados a cenar, y te gustaría encontrar alguna receta para preparar el pollo que este sábado compraste en el mercado. ¿Cómo lo harías?».
• Cuestionario final. Al final de la sesión se hacen algunas preguntas abiertas al usuario sobre cuestiones de tipo general y subjetivo: qué le ha parecido el prototipo en general, si mejoraría algo en particular… Al final es muy recomendable preguntar si quiere comentar o añadir algo más; cuando el usuario habla libremente puede desvelar cuestiones que hayan pasado desapercibidas.
• Retribución. En caso de que se haya establecido así, se retribuye al usuario con un obsequio o con cheques de compra. El final de la sesión es el momento para hacerlo. En todo caso, hay que agradecer siempre al usuario su participación.

Las sesiones de tree testing siguen el guion establecido en la fase de preparación, aunque, puesto que participan diferentes usuarios, cada sesión será diferente.

Aun así, hay que tener en cuenta unas pautas fundamentales:

Romper el hielo con el usuario

Para actuar normalmente, un usuario tiene que sentirse en un entorno de confianza. Es necesario que el evaluador le deje muy claro que no se le está poniendo a prueba a él, sino que su participación es fundamental para mejorar el producto o servicio en cuestión.

Plantear las tareas una a una

El evaluador ha de plantear las tareas una a una, dejando tiempo para que el usuario intente resolverlas. No se pasa a la siguiente tarea hasta que no finaliza la que se esté realizando.

Una tarea se puede dar por finalizada:

• Cuando el usuario llega al objetivo planteado (éxito).
• Cuando llega al que a él le parece que es el objetivo aunque en realidad no lo sea (falso éxito).
• Cuando declara que no sabe cómo resolverla después de haberlo intentado (error).

No intervenir en las acciones del usuario

El evaluador no tiene que dar pautas o explicar al usuario cómo resolver una tarea, aunque se sienta tentado a ello. El objetivo es observar cómo actúa el usuario para poder mejorar el diseño, no enseñarle a resolver problemas de un diseño deficiente.

Observar al usuario y pedirle que verbalice los pensamientos

Comprobar si el usuario puede completar con éxito una tarea es tan importante como saber cómo lo hace y cuál es su proceso de pensamiento.

Observar su gestualidad y escuchar lo que está pensando permite recoger cuestiones emocionales y saber si el usuario se encuentra cómodo o confuso, enfadado, cansado o irritado.

Hacer preguntas

El evaluador tiene que preguntar cualquier cuestión que no vea clara o sobre la que necesite más información. También debe evitar inferir o sacar deducciones personales sobre las razones por las que el usuario actúa de una manera determinada. Es mejor preguntar por exceso que por defecto.

Las preguntas tienen que ser neutras y no contener sugerencias o críticas para evitar sesgar las respuestas.

Del análisis de las sesiones se obtienen dos tipos de datos fundamentales:

Datos cuantitativos

Corresponden a:

• Los datos demográficos de los participantes (recogidos en el cuestionario previo).
• El análisis de los resultados de las tareas:
  • Ratio de éxito por tarea (por ejemplo, un 50 % de éxito implica que solo la mitad de los participantes han resuelto bien la tarea).
  • Tiempo medio por tarea (media de tiempo que necesitan los participantes para finalizar la tarea).
  • Ratio de errores y falsos éxitos (porcentaje de participantes que no han podido resolver la tarea, o que han obtenido un falso éxito).

Datos cualitativos

• Anotaciones sobre las actividades que los usuarios realizan para intentar resolver una tarea.
• Anotaciones sobre la actitud emocional del usuario al intentar resolver una tarea.
• Problemas observados.
• Respuestas a las cuestiones abiertas del final de la sesión.

A medida que se revisan los datos recogidos, hay que clasificar los problemas según su severidad:

• Crítico: si no se resuelve, los usuarios no podrán completar la tarea.
• Serio: muchos usuarios se frustrarán si no se resuelve, y pueden abandonar el uso del producto.
• Menor: el problema puede causar molestias, pero no impide que se realice la tarea; se puede resolver posteriormente.

El informe del test con usuarios tiene que incluir los siguientes contenidos:

• Introducción. Información fundamental del tree testing: objetivos, número de participantes, dónde se han realizado las sesiones, equipamiento utilizado en la grabación, y evaluadores que han participado en ella.
• Metodología. Guion del tree test y datos demográficos de los usuarios con los que se ha realizado la evaluación. No se incluirán sus identidades reales, a no ser que se haya planteado así desde el inicio y los participantes hayan firmado el consentimiento.
• Resultados del test. Datos cuantitativos y cualitativos recogidos durante las sesiones.
• Conclusiones y recomendaciones. A partir de los datos recogidos, indicar cuestiones que resolver y buenas prácticas que introducir en la arquitectura de la información. Es recomendable que las cuestiones que se hayan de resolver vengan acompañadas de recomendaciones sobre cómo hacerlo. La redacción de este apartado tendría que ser ejecutiva, es decir, clara, sintética y estructurada de forma ágil (el formato lista suele ser el más recomendable).

«How to use Tree Testing to Test the Information Architecture of Your Website or App» [en línea]. Loop11. <https://www.loop11.com/how-to-use-tree-testing-to-test-the-information-architecture-of-your-website-or-app/>. [Fecha de consulta: 25 de enero de 2021].

OBrien, Dave (2009). «Tree Testing» [en línea]. Boxes and Arrows. <http://boxesandarrows.com/tree-testing/>. [Fecha de consulta: 25 de enero de 2021].