Guion de test de usabilidad: escribir tareas que no den pistas
Un guion de test de usabilidad ordena la sesión: intro neutral, tareas sin pistas, seguimiento y cierre. Cómo escribir tareas y qué decir si alguien se atasca.
¿Qué lleva un guion?
Lyssna propone una estructura de cinco bloques, que es también la más habitual:
- Introducción y consentimiento. Bienvenida, explicación del objetivo, permiso para grabar y uso de los datos.
- Preguntas de contexto. Cosas sobre la persona que ayudan a interpretar lo que hace: cómo usa productos similares, con qué frecuencia.
- Tareas y escenarios. El núcleo de la sesión.
- Preguntas de seguimiento. Para entender lo que la persona vio, pensó o esperaba.
- Cierre. Preguntas finales, agradecimiento, preguntas de la persona y, si corresponde, una pequeña encuesta de satisfacción.
La plantilla de Lyssna asigna cinco minutos a la introducción, cinco a las preguntas de calentamiento, diez a las preguntas finales y dos al cierre, y recomienda no pasar de 30 minutos por sesión. Con esos tiempos quedan unos ocho minutos para las tareas, y la guía recomienda entre tres y cinco tareas por sesión (Lyssna, “Usability test script”).
¿Por qué le importa a un diseñador?
Porque la tarea es lo que más cambia el resultado. Una tarea mal escrita te dice más sobre tu redacción que sobre tu diseño: si la persona encuentra el botón es porque la tarea le dijo cómo se llamaba.
Escribir el guion también te obliga a decidir qué es importante. Si no puedes escribir una tarea concreta para una función, probablemente no sabes para qué sirve esa función.
¿Cómo se escribe una buena tarea?
NN/g resume tres reglas: la tarea debe ser realista, accionable y sin pistas (NN/g, “Task scenarios for usability testing”). En la práctica:
- Describe la meta, no el camino. Si el botón se llama «Configuración del espacio de trabajo», no escribas esas palabras en la tarea. Escribe algo como «Quieres que tu compañera pueda ver tus proyectos».
- Usa el lenguaje de la persona. Si la interfaz dice «Facturación» y la persona busca «cobrar a mis clientes», la tarea debe decir lo segundo.
- Da todos los datos necesarios. Fecha, presupuesto o destinatario. Una tarea vaga produce respuestas vagas.
- Pide la acción, no la explicación. «Haz el pedido» en vez de «¿Cómo comprarías esto?».
- Una tarea, una frase. Si necesitas tres frases para explicar una tarea, probablemente son tres tareas.
NN/g lo resume con una frase que conviene tener a mano: dale a la persona toda la información que necesita para completar la tarea, sin decirle dónde hacer clic (NN/g, “Task scenarios for usability testing”).
Userbrain añade que el enunciado no debe revelar el “camino correcto” ni pedir opiniones o predicciones de uso futuro, sino preguntar por comportamientos concretos (Userbrain, “How to write effective tasks”).
¿Qué decir cuando alguien se atasca?
Es el momento más difícil del moderador. La regla es no dar pistas. Lyssna sugiere preguntas neutras de pensamiento en voz alta, como «¿Qué estás buscando?» o «¿Qué harías ahora?», y advierte contra indicar dónde hacer clic, porque el objetivo es comprobar si el usuario encuentra la función por sí mismo (Lyssna).
Si la persona se queda bloqueada durante mucho tiempo, da la información que necesita para seguir con la tarea y anota que se atascó. Ese punto es un dato tan valioso como un error.
Ejemplo
Ejemplo ilustrativo: un guion para una app de agenda médica incluye la tarea «Eres una persona que necesita cambiar una cita del jueves por la tarde porque tu hijo tiene fiebre. Quieres pasarla a la semana siguiente». La versión inicial decía «Reprograma tu cita usando el menú de gestión de citas». En la primera sesión, tres de cinco personas miraron directamente ese menú sin leer la pantalla. Al reescribir la tarea sin esas palabras, dos de cinco se perdieron en la pantalla de historial, que era el problema real. La tarea nueva le dio al equipo el dato que necesitaba.
¿Cuándo NO conviene usar un guion cerrado?
- En entrevistas exploratorias. Si buscas entender un problema, un guion rígido te impide seguir lo que la persona dice. Ahí conviene una entrevista de usuario con temas, no tareas.
- Cuando la tarea depende de la persona. Si la prueba exige datos reales de su vida, una tarea inventada puede ser poco realista. Adapta el escenario con antelación.
- Si el objetivo es medir una sola cosa. Un test de primera impresión no necesita tareas. Usa un test de 5 segundos.
Errores comunes
- Usar el nombre del botón o de la sección en la tarea.
- Escribir tareas que terminan con «y dime si te gusta».
- Dar pistas cuando alguien se atasca, aunque sea sin querer.
- Usar siempre las mismas tareas aunque el producto haya cambiado.
- Llegar a la sesión sin haber probado el guion con un compañero.
Cómo empezar mañana
Toma la función más importante de tu producto y escribe tres tareas sin usar ninguna palabra de la interfaz. Para cada una, define qué cuenta como éxito. Prueba el guion con un compañero de tu equipo, no con alguien que conozca el producto, y corrige cualquier frase que dé pistas. Después, cuando tengas las sesiones, calcula las métricas de usabilidad de cada tarea. Si todavía no sabes a quién invitar, el texto sobre reclutamiento de participantes te ayuda a decidirlo.