De reclutar usuarios a aplicar cambios… En este artículo se revisan las fases de ejecución de un test de guerrilla.

Reclutar buenos participantes para la prueba

El punto de partida es elegir a usuarios que sean lo más similares posibles a los que emplean realmente la interfaz.

Es posible que existan múltiples usuarios potenciales, en ese caso es importante incluir usuarios representativos de todos esos grupos y evaluarlos de forma separada para poder concentrarnos en la información o la funcionalidad basada en un rol.

Un error común es incluir a los miembros del personal, estos solo deberían ser incluidos como participantes si coinciden con el target de la audiencia.

Configuración del test

Antes de empezar las sesiones es preciso tener listos: los materiales, los consentimientos y la documentación.

También es importante de ser posible tener un equipo de reserva con el mismo software de medición por si algo fallase.

Prueba piloto

Es recomendable hacer una prueba piloto, esto permite:

• Testar el equipamiento, algunos programas de grabación pueden dar sorpresas en sesiones largas y hacernos perder todo el trabajo.
• Ofrece algo de práctica a los miembros del equipo
• Obtener un buen feedback de si las preguntas y escenarios están claros para el participante
• Realizar ajustes de última hora

Preparación entre pruebas

Deben planificarse separaciones entre las pruebas de por lo menos 20 minutos, son útiles para revisar datos anotados y hacer los ajustes necesarios para revertir la prueba al estado inicial.

Establecer un checklist de tareas nos ayudara a asegurarnos de no dejar ningún paso fuera, entre otras pueden ser:

• Probar el software de grabación
• Apagar cualquier software que permita interrumpir el test
• Estar seguro de que están en favoritos los vínculos a las páginas que se van a emplear en el test
• Someter a una prueba previa los materiales que se van a testar
• Resetear todos los elementos a emplear para evitar dar pistas a los usuarios (vínculos visitados…)

Realización de la prueba

Pasos generales

Un ejemplo de la prueba seria como sigue

1) El conductor de la prueba da la bienvenida al participante y explica cómo será la sesión de test, después le pide a los participantes firmar el formulario de participación.

2) El conductor explica la técnica de thinking aloud y le pregunta a los participantes si tienen cuestiones adicionales.

3) El participante lee las tareas y empieza a realizar las tareas pensando en voz alta.

4) Los encargados de tomar notas registran las conductas de los participantes, comentarios, errores y finalización (éxito o fracaso de la tarea).

5) La sesión continua hasta que todas las tareas se han completado o el tiempo destinado a la prueba ha finalizado.

6) EL conductor al final de la sesión realiza algunas preguntas subjetivas a los participantes o bien les remite a una encuesta online, gradece su participación, le da los incentivos pactados si existen y despide al usuario.

7) El conductor reestablece los materiales y equipos de prueba, habla brevemente con los observadores y espera al siguiente participante.

Consejos

• Sentarse al lado del participante, fuera de su vista generalmente a su derecha y ligeramente por detrás de el
• Permitir a los usuarios explorar el sitio uno o dos minutos inicialmente.
• Solicitar reacciones los más espontaneas posibles a la primera página, también es importante que verbalice las primeras impresiones que le sugieren las paginas siguientes
• Debe mantenerse al usuario hablando y no hacer juicios sobre su comportamiento, estos pueden condicionar sus respuestas al intentar complacer al conductor de la prueba.
• Es importante centrarse en la experiencia presente y evitar las preguntas genéricas, se busca la concisión.
• A veces es útil proveer un mínimo de ayuda para obligar al participante experimental a actuar independientemente de nuevo, cuanto antes se ayude al usuario más riesgo existe de perder un feedback valioso
• De forma complementaria cuando hay suficientes datos sobre un problema es posible ayudar al usuario inmediatamente especialmente si existen tareas posteriores a cerca de las cuales tenemos suficientes datos.
• Es importante controlar la comunicación verbal y no dar pistas al usuario como: sonrisas, movimientos de apoyo con las manos…

Pensar en voz alta

Es una técnica presente hace décadas en la recopilación de datos en Psicología y una amplia gama de ciencias sociales. Ya en 1945 el psicólogo Karl Duncher describía las verbalizaciones en voz alta como una forma de entender el pensamiento de los usuarios.

El método ha sido popularizado por Nielsen como el método de ingeniería de Usabilidad más valioso, directamente ligado a los test de usuarios de guerrilla.

Es una sencilla técnica diseñada para capturar que es lo que los participantes están pensando mientras trabajan.

Esencialmente se les pide a los participantes que verbalicen un comentario rápido de lo que piensan mientras realizan las tareas de la prueba.

Esta técnica de «leer mentes» es especialmente efectiva para conducir la investigación exploratoria en las fases iniciales.

Ventajas:

• Es posible capturar información de preferencias y de actuación de forma simultánea
• Ayuda a algunos usuarios a estar focalizados y concentrados
• Se reciben constantemente pistas sobre conceptos equivocados
• Los participantes puede revelar como están haciendo una tarea y que cosas funcionan bien o no sobre la marcha
• Es barato, robusto, flexible y fácil de aprender
• Es una exposición directa a lo que los usuarios piensan y en ese sentido resulta muy persuasivo para realizar cambios

Desventajas

• Algunos usuarios ven esa técnica como antinatural y distractora
• Esta técnica puede ralentizar el proceso de pensamiento mejorando la atención pero paralelamente y por eso mismo puede hacer que no se produzcan errores que si se darían en el entorno real de trabajo
• Requiere mayor esfuerzo para el usuario verbalizar sus pensamientos y puede ser agotador en sesiones largas

Métricas y Análisis de los datos

Los test de usuarios son esencialmente una prueba cualitativa; para emplearse como prueba cuantitativa harían falta muchos más usuarios con el objetivo de obtener datos estadísticamente consistentes.

Aun disponiendo de un gran número de usuarios este tipo de pruebas no suelen ser utilizados para realizar estudios cuantitativos (con la excepción tal vez de los remotos).

No obstante al final de las pruebas es posible hablar de datos cuantitativos y datos cualitativos:

A) Datos cuantitativos: tasas de éxito, problemas de Usabilidad, tiempo de la tarea y errores.

B) Datos cualitativos: pueden incluir: observaciones sobre el comportamiento de los usuarios, problemas experimentados y respuestas a preguntas abiertas.

Análisis de datos cuantitativos

Tasas de éxito

Son las métricas de Usabilidad más fundamentales. Se recogen típicamente en un formato binario donde uno es éxito y cero es fracaso.
A la hora de presentar los datos se divide el número de usuarios que han tenido éxito entre el total de usuarios por ejemplo si
8 de 10 usuarios han tenido éxito la tasa de éxito es del 0.8 y frecuentemente se presenta como el 80 por ciento de éxito.

Problemas de Usabilidad

Si un usuario encuentra un problema mientras intenta realizar una tarea asociada con la interfaz es un problema e interfaz. Este tipo de problemas
Se pueden apuntar durante las sesiones y establecer listas con ellos donde pueden ir asociados a una descripción y a lo que es más importante
La frecuencia de impacto en los usuarios.

Desde una perspectiva analítica una forma de organizar los problemas es asociar cada uno a los usuarios que los han encontrado, esto pude ofrecer una métrica del impacto de determinado problema.

Tiempo de la tarea

Se refiere a cuánto tiempo invierte un usuario en determinada tarea. Existen 3 tipos de medidas que se pueden hacer con estos datos.

a) Tiempo de terminación de la tarea: El tiempo empleado por los usuarios en completar una tarea con éxito.

b) Tiempo hasta el fallo: Tiempo que pasa hasta que los usuarios se dan por vencidos o completan la tarea de forma incorrecta

C) Tiempo total de la tarea: La duración total del tiempo que los usuarios invierten en una tarea.

Errores

Son cualquier acción no intencionada, desliz, error u omisión que comente el usuario mientras realiza una tarea. La contabilización de los mismos va a ser de 0 sin errores (esto suele ser raro) a un número concreto de errores (que no suele sobrepasar los 20)

Los errores proveen un excelente diagnóstico de información para mapear tareas.

Pueden ser mostrados en valores binarios 0, 1.

Tasas de satisfacción

Cuestionarios que miden la percepción de facilidad de uso de un sistema y que pueden ser completados inmediatamente después de una tarea o lo que es más común después de la sesión.

Informar de los resultados

Es importante ordenar los resultados de forma que se pueda establecer una escala de gravedad.

Critica: Si esos problemas no se solucionan el usuario no será capaz de completar la tarea.

Grave: Muchos usuarios se sienten frustrados si no arreglamos esto,

Menores: Los usuarios están molestos pero eso no les impide completar el escenario.

Redacción del informe

Un buen informe debe incluir información del plan de pruebas y detallar la metodología para poder ser reproducido posteriormente. Deben ser secciones cortas y deben emplearse tablas para mostrar métricas. Centrarse en conclusiones y recomendaciones y emplear ejemplos visuales para demostrar las áreas problemáticas.

El informe debe incluir:

A) Resumen de antecedentes

Un breve resumen que incluya: que se ha testado, donde, que equipo, cuantas personas, con que materiales y un breve resumen de los problemas.

B) Metodología

La metodología empleada para poder replicar la prueba.

Explicar cómo se llevó a cabo la prueba de la descripción de las sesiones de prueba, el tipo de interfaz de pruebas, mediciones recogidas, y una visión general de los escenarios de trabajo.

Describir los participantes y proporcionar tablas de resumen de los antecedentes / respuestas al cuestionario demográficas (por ejemplo, edad, profesión, uso de Internet, sitio visitado, etc.)

C) Resultados de la prueba

Describir las tareas con tasas de terminación más altas y más bajas. Proporcionar un resumen de las tasas de terminación de la tarea con éxito por los participantes, la tarea, y la tasa media de éxito de la tarea y mostrar los datos en una tabla.

En función de estos parámetros es posible mostrar:

• Número y porcentaje de participantes que completaron cada escenario, y todos los escenarios
• Tiempo medio empleado para cubrir cada tarea
• Resultados de satisfacción
• Comentarios de los participantes

D) Hallazgos y recomendaciones

Listar las conclusiones y recomendaciones con todos sus datos (cuantitativos y cualitativos, notas y hojas de cálculo).

E) Proporcionar un ranking de severidad

En base a los datos marcados previamente con su nivel de gravedad.

F) Implementar y retest

Implementar los cambios ne la medida que sea posible y retestar

Consejos a la hora de realizar cambios

Steve Krug propone una serie de consejos para resolver los problemas detectados en un test de usuarios:

A) Procura hacer lo mínimo posible

Hay que buscar el cambio más pequeño posible que permita solucionar el problema detectado.

• No buscar la solución perfecta, será demasiado costo y tardará en llegar
• Si no es posible arreglar el origen del problema detectado porque el cambio es demasiado costoso tratar de atenuarlo
• No enfocar el problema detectado como inamovible hasta un rediseño, debe ser un cambio lo suficientemente pequeño para que no exista la impresión de una reduplicación del esfuerzo

B) Retocar no rediseñar

La idea de rediseñar puede ser muy seductora en un sentido abstracto, prácticamente promete empezar de 0 todo bien. En ese sentido realizar ajustes no resulta tan satisfactorio pero tiene una serie de beneficios:

• El coste es bajo
• Requiere menos trabajo
• No requiere esfuerzos extra fuera del trabajo
• Es más rápido
• Se aproxima más a cambiar el problema que existe en ese contexto determinado
• Si se realizan más cambios es posible romper cosas que realmente funcionan bien
• A la mayoría de la gente no le gustan los cambios así que un rediseño suele molestarles
• Un rediseño implica un montón de cambios al instante que implican complejidades y riesgos
• Un rediseño implica un equipo más voluminoso y también más reuniones extra

C) Quitar algo

Una de las cosas que la gente suele hacer cuando existe un problema de Usabilidad es añadir algo.

Si alguien no entiende las instrucciones entonces se añaden nuevas instrucciones. Si alguien no encuentra algo la mejor forma de rescatarlo es resaltándolo más…

Lo que sucede realmente es que a menudo la mejor forma de arreglar un problema de usabilidad es hacer justamente lo contrario: quitar algo.

Habitualmente lo mejor es eliminar cosas que distraen al usuario.
Por ejemplo para destacar mejor un elemento es más útil eliminar el ruido existente que destacar aún más ese elemento (cuando destacamos todo al final no destacamos nada).

Referencias

• http://www.cehd.umn.edu/nceo/OnlinePubs/Tech44/
• http://www.nngroup.com/articles/how-many-test-users/
• http://www.nngroup.com/articles/risks-of-quantitative-studies/
• http://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/
• http://www.measuringusability.com/qualitative_risks.htm
• http://www.usability.gov/how-to-and-tools/methods/usability-testing.html
• http://www.userfocus.co.uk/articles/datathink.html
• http://www.userfocus.co.uk/articles/discount.html
• http://www.uxmatters.com/mt/archives/2009/02/writing-usability-requirements-and-metrics.php
• Barnum, Carol (2010) Usability Testing Essentials. Morgan Kaufmann
• Molich, Rolf (2001) 230 Tips and Tricks for a Better Usability Test. Nielsen Norman Group
• Krug, Steve (2010) Rocket Surgery Made Easy. New Raiders
• Rubin J, Chisnell D (2008) Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. Wiley Publishing
• Sauro, Jeff (2012) Quantifying the User Experience: Practical Statistics for User Research. Morgan Kaufmann
• Imagen principal de Samuel Mann via Flickr