Krypton Solid

¿Cómo se sabe cuando un diseño falla en una prueba de usabilidad?

¿Cómo se sabe cuando un diseño falla en una prueba de usabilidad?

Una técnica útil que aprendí del trabajo equivocado …

Hace años, pasé una parte incómoda de mi carrera como diseñador instruccional, creando cursos para el aprendizaje en línea. No encajó bien y seguí adelante felizmente, pero una parte de ese trabajo me ha convertido en un mejor diseñador de UX: Objetivos de aprendizaje.

Los objetivos de aprendizaje son simplemente lo que desea que el alumno aprenda al final de la formación. Si hay una prueba, las preguntas de la prueba deben basarse en esos objetivos; de lo contrario, ¿cuál es el objetivo de la prueba?

El mismo enfoque resulta útil para determinar si un diseño ha pasado o no una prueba de usabilidad. Solo recuerde: es el diseño lo que se está probando, no los participantes.

¿Qué necesita hacer o decir el participante de la prueba para que usted se sienta seguro de que el diseño ha tenido éxito? ¿Necesitan hacer un seguimiento de tres horas de tiempo para un proyecto en particular? ¿Generar una factura a un cliente basada en ese tiempo registrado? ¿Enviar la factura? Ese es su criterio de prueba.

Por supuesto, las pruebas de usabilidad consisten en observar cómo los usuarios completan las tareas, pero ¿qué conseguirás que hagan exactamente? La belleza de estos criterios es que lo alejan de objetivos de prueba vagos como «comprender cómo funciona el seguimiento del tiempo». ¿Cómo sabrá que lo han entendido? Consigues que lo describan. Y una vez que lo han descrito con precisión, puede decir que ese aspecto del diseño fue exitoso.

Los criterios de éxito lo ayudan dos veces: aclaran si su diseño es realmente exitoso y facilitan compartir esos resultados.

Los verbos son mágicos

El libro que me enseñó sobre los objetivos de aprendizaje, el libro de George Piskurich Diseño instruccional rápido, ofrece una lista útil de comportamientos para comenzar con sus criterios de éxito.

Por ejemplo, los objetivos de comprensión pueden ser «describir» o «demostrar». Una vez más, «entender» no es bueno; los necesita para decir (es decir, describir) o hacer (es decir, demuestre) algo que le demuestre que lo han entendido.

Y luego, con un mayor grado de dificultad, un participante podría «explicar» u «organizar»; en un nivel superior aún, podrían «crear» o «evaluar».

Cualquiera que sea el verbo que elija para iniciar su criterio de éxito, el punto es que puede observar si un usuario realmente ha dicho o hecho lo que constituye el éxito de la tarea.

«Al final de esta sesión …»

Entonces, cuando esté planeando su próxima prueba de usabilidad y esté trabajando en tareas, comience por preguntar: «¿Qué debería poder hacer un usuario con (o decir sobre) este diseño?»

Entonces, podrías escribir algo como esto:

Al final de la sesión, el participante debería poder:

  • rastrear tres horas de tiempo para un proyecto en particular;
  • generar una factura a un cliente basada en ese tiempo registrado;
  • describir la diferencia entre el tiempo de seguimiento y el tiempo de registro.

Ahora tiene tres criterios de éxito y, en función de ellos, también tiene una idea bastante clara de las tareas que deberá asignar a los participantes.

Una advertencia: los criterios de éxito no son lo mismo que las tareas. Las tareas tienen más contexto; están escritos para ser leídos por el participante y pueden incluir algo de contexto sobre la tarea, especialmente si los está dirigiendo a encontrar algo en su prototipo. Por ejemplo:

Criterios de éxito: Genere una factura para un cliente en función de ese tiempo registrado

Tarea: «Ahora que ha realizado un seguimiento de tres horas en el proyecto Atlas, muéstreme cómo facturaría los productos Acme por su tiempo».

Bastante similar, obviamente, pero los criterios de éxito son para usted y su equipo; la tarea es para el participante en el contexto de la sesión de usabilidad.

Y notará que uno de los criterios de éxito anteriores es describir algo, en lugar de completar una tarea. Podría ser una pregunta de seguimiento de una tarea. Estos son útiles para validar si el modelo mental de su diseño es claro para los usuarios. He visto a los usuarios encontrar el camino a través de una tarea, pero luego me describen un modelo mental de la aplicación que no coincide con la forma en que fue diseñada. Ese es el éxito de la tarea para un participante, pero lo que es más importante, hay un problema subyacente con la coincidencia del modelo mental de ese participante.

Entonces, comience con sus criterios de éxito, luego escriba sus tareas y preguntas de seguimiento según sus criterios.

A las partes interesadas les encantan los criterios de éxito

Las partes interesadas no necesariamente se preocupan por su proceso, pero realmente se preocupan por los resultados. Y si su presentación de los resultados es vaga, se irritarán con razón.

«El usuario logró realizar un seguimiento de algunas horas, pero no estábamos seguros de si entendía que el tiempo de seguimiento no es lo mismo que registrarlo en un cliente …» Bueno, ¿por qué no estás seguro? ¿No es tu trabajo resolver esto? Estás perdiendo el tiempo y no les estás dando una dirección clara sobre cómo solucionar los problemas de UX, que también es tu trabajo, ¿verdad?

Los criterios de éxito lo ayudan dos veces: aclaran si su diseño es realmente exitoso y facilitan compartir esos resultados.

Hemos tenido cierto éxito al rastrear los criterios de éxito en una tabla simple y codificar los resultados con colores. Al igual que:

Creamos una tabla de resultados codificada por colores (verde = éxito, rojo = fracaso) en nuestra wiki. En la fila superior, enumeramos a los participantes; en la columna de la izquierda, enumeramos nuestros criterios de éxito. Es feo, pero rápido y útil.

Esto es fácil de escanear, muestra con bastante claridad dónde están los problemas y basa los resultados en las experiencias de los participantes reales. También incluimos un resumen de resultados con viñetas y una lista de problemas de usabilidad y recomendaciones justo debajo. Nos concentraremos en esos problemas e iteraremos hasta que creamos que están resueltos. Su proceso puede ser un poco diferente, tal vez sea un consultor que entrega un informe a un cliente, por ejemplo, pero los beneficios son los mismos.

Deja un comentario