Cuando presentas una propuesta web y preguntas si gusta, obtienes opiniones sobre colores, fotografías o preferencias personales. Esa conversación puede ser útil, pero no demuestra que alguien encuentre lo que necesita. Un prototipo permite explorar tareas antes de construir toda la solución. Para un espacio de coworking, una tarea podría ser localizar una sala para una reunión breve y consultar sus condiciones. La prueba no busca examinar al participante ni convencerlo del diseño, sino descubrir dónde la interfaz exige explicaciones que el sitio debería proporcionar por sí mismo.
Escribir situaciones sin revelar el camino
Una buena tarea describe el objetivo y el contexto, no los botones que se deben pulsar. En vez de pedir entrar en servicios y seleccionar salas, plantea que necesitas reunirte con un cliente durante una mañana y quieres saber si el lugar ofrece una opción adecuada. Añade restricciones realistas, como cantidad aproximada de personas, sin saturar el escenario. El participante debería elegir el recorrido por su cuenta. Prepara tareas que representen decisiones importantes y evita una lista tan extensa que el cansancio se convierta en el problema principal observado durante la sesión.
Preparar el alcance del prototipo
Indica al comenzar qué partes funcionan y cuáles son una simulación. Si un formulario no envía mensajes, no permitas que el participante introduzca datos personales reales. Utiliza información ficticia y revisa que no exista conexión a una operación productiva. Asegúrate de que los destinos necesarios para la tarea estén representados; un enlace sin pantalla posterior puede impedir distinguir un problema de diseño de una limitación del prototipo. No hace falta simular cada detalle del negocio. Basta con que las decisiones relevantes tengan una respuesta coherente y se puedan explorar sin instrucciones improvisadas del moderador.
Observar sin corregir inmediatamente
Pide que la persona explique lo que intenta hacer y registra dónde duda, qué interpreta y cuándo retrocede. Si pregunta dónde está algo, devuelve la atención a lo que esperaba encontrar antes de señalarle una respuesta. Evita defender el diseño durante la prueba. Una etiqueta puede parecer obvia al equipo porque conoce la estructura desde hace semanas. La evidencia útil es el comportamiento ante una situación, no una discusión sobre quién interpreta correctamente una palabra. Separa los problemas observados de las sugerencias del participante: ambas aportan, pero una solución propuesta también necesita evaluarse antes de adoptarla.
Convertir notas en decisiones verificables
Agrupa hallazgos por obstáculo: no reconoce la categoría, no entiende el precio o no encuentra cómo consultar. Anota la tarea afectada y el cambio que probarás. No conviertas una sesión pequeña en una estadística universal de usuarios. Para evaluar la corrección, repite la situación y observa si desaparece el obstáculo sin crear otro. WAI recomienda involucrar usuarios al evaluar accesibilidad, junto con otras comprobaciones; de forma similar, una prueba de tareas complementa la revisión técnica y editorial. El prototipo habrá cumplido su función si permite tomar decisiones mejor fundamentadas antes de invertir en la implementación completa.
DE LA LECTURA A LA ACCIÓN
Para aplicar hoy
- Describe un objetivo sin indicar los pasos de navegación.
- Registra problemas observados sin defender la propuesta durante la prueba.
- Relaciona cada cambio con una tarea y vuelve a comprobarla.
Fuentes y referencias
Documentación para profundizar. Los ejemplos de esta guía son didácticos.