¿Cómo se sabe cuando un diseño falla una prueba de usabilidad?
Una técnica útil que aprendí del trabajo equivocado ...
Hace años, pasé un período incómodo de mi carrera como diseñador de instrucción, creando cursos para el aprendizaje en línea. Fue un mal ajuste 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 quiere que el alumno aprenda al final de la capacitació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 es útil para determinar si un diseño ha aprobado o no una prueba de usabilidad. Solo recuerda: es el diseño el que está siendo probado, no los participantes.
¿Qué necesita hacer o decir el participante de la prueba para que se sienta seguro de que el diseño ha tenido éxito? ¿Necesitan rastrear tres horas de tiempo para un proyecto en particular? ¿Generar una factura a un cliente basado en ese tiempo rastreado? ¿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é hará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? Los haces que lo describan. Y una vez que lo hayan 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 hacen que sea más fácil compartir esos resultados.
Los verbos son mágicos
El libro que me enseñó sobre los objetivos de aprendizaje, George Piskurich's Diseño instructivo rápido , ofrece una lista práctica de comportamientos para comenzar sus criterios de éxito.
Por ejemplo, los objetivos para la comprensión pueden ser "describir" o "demostrar". Una vez más, "entender" no es bueno; necesitas que digan (es decir, describan) o lo hagan (es decir, demuestren) algo que te demuestra que han entendido.
Y luego, en un grado más alto de dificultad, un participante podría "explicar" u "organizar"; a un nivel más alto aún, podrían "crear" o "evaluar".
Cualquiera que sea el verbo que elijas para comenzar tus criterios de éxito, el punto es que puedes observar si un usuario realmente ha dicho o hecho lo que constituye el éxito de la tarea.
"Al final de esta sesión ..."
Por lo tanto, cuando planifica su próxima prueba de usabilidad y está trabajando en tareas, empiece por preguntar: "¿Qué debería 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:
- seguir tres horas de tiempo para un proyecto en particular;
- generar una factura a un cliente basado en ese tiempo rastreado;
- describir la diferencia entre el tiempo de seguimiento y el tiempo de registro.
Ahora tiene tres criterios de éxito y, basado en ellos, también tiene un sentido bastante claro de las tareas que deberá realizar 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 al participante, y pueden incluir algún contexto sobre la tarea, particularmente si los está dirigiendo a buscar algo en su prototipo. Por ejemplo:
Criterios de éxito: generar una factura a un cliente en función de ese tiempo rastreado
Tarea: "Ahora que ha rastreado tres horas en el proyecto Atlas, muéstreme cómo facturaría los productos Acme por su tiempo".
Muy 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 trata de describir algo, en lugar de completar una tarea. Puede ser una pregunta de seguimiento para 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 su camino a través de una tarea, pero luego me describen un modelo mental de la aplicación que está en desacuerdo con la forma en que fue diseñado. Ése es el éxito de una tarea para un participante, pero lo más importante es que hay un problema subyacente al emparejar el modelo mental de ese participante.
Entonces, comience con sus criterios de éxito, luego escriba sus tareas y preguntas de seguimiento según sus criterios.
Las partes interesadas aman 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, estarán legítimamente irritados.
"El usuario logró rastrear algunas horas, pero no estábamos seguros si ella entendió que el tiempo de seguimiento no es lo mismo que registrarlo contra un cliente ..." Bueno, ¿por qué no estás seguro? ¿No es tu trabajo resolver esto? Está perdiendo el tiempo y no les está dando instrucciones claras sobre cómo solucionar los problemas de UX, que también es su trabajo, ¿no?
Los criterios de éxito lo ayudan dos veces: aclaran si su diseño es realmente exitoso, y hacen que sea más fácil compartir esos resultados.
Hemos tenido éxito en el seguimiento de los criterios de éxito en una tabla simple y en la codificación por colores de los resultados. Al igual que:
Desarrollamos una tabla de resultados codificada por colores (verde = éxito, rojo = falla) en nuestra wiki. En la fila superior, listamos 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 fundamenta los resultados en las experiencias de los participantes reales. También enumeramos un resumen de los resultados y una lista de problemas de usabilidad y recomendaciones justo debajo. Nos centraremos en esos problemas y repetiremos hasta que creamos que están resueltos. Su proceso puede ser un poco diferente, tal vez usted es un consultor entregando un informe a un cliente, por ejemplo, pero los beneficios son los mismos.