Evaluar si tu diseño funciona significa observar a personas reales usarlo y registrar dónde tienen problemas, no adivinar lo que sienten.
La tarde en que todo pareció perfecto
Mariana lleva tres semanas diseñando el flujo de compra para una tienda de ropa en línea. El prototipo en Figma luce impecable. Los colores son consistentes, los botones están bien ubicados y el flujo tiene sentido... para ella. El viernes presenta el diseño a su equipo y todos aplauden. El lunes siguiente, cinco usuarios reales prueban el prototipo. Cuatro de ellos no pueden completar el pago.
Ese momento incómodo tiene nombre: sesgo del diseñador. Cuando tú construyes algo, tu cerebro llena automáticamente los vacíos. Ves lo que quisiste crear, no lo que realmente está ahí. El problema es que tus usuarios no tienen ese mapa mental. Ellos llegan sin contexto y sin paciencia infinita.
Aquí está la verdad que cambia todo: el 85% de los problemas de usabilidad se detectan con apenas 5 usuarios. Nielsen Norman Group documentó este dato hace décadas y sigue siendo válido. No necesitas una investigación masiva. Necesitas un método.
¿Qué es una prueba de usabilidad?
Una prueba de usabilidad es una sesión estructurada donde observas a una persona real intentar completar tareas con tu diseño. Tú no explicas nada. No ayudas. Solo escuchas y registras.
No es una encuesta de satisfacción. No es pedirle a tu amigo su opinión. Es observación directa con tareas específicas. La diferencia importa porque las personas dicen una cosa y hacen otra. Si le preguntas a alguien si el diseño le gusta, dirá que sí para no herirte. Pero si lo observas intentar pagar un pedido en Liverpool y se tarda cuatro minutos buscando el botón de confirmar, eso es evidencia real.
Existen dos grandes tipos de pruebas que puedes aplicar desde el inicio de tu carrera.
Pruebas moderadas: tú estás presente
En una prueba moderada, tú guías la sesión en tiempo real. Te sientas frente al usuario (o en videollamada) y le das tareas concretas. Por ejemplo: "Imagina que quieres comprar unos tenis en este sitio. Intenta agregarlos al carrito y llegar al pago."
Mientras el usuario trabaja, tú observas sin intervenir. Si se atasca, no digas nada todavía. Deja que el silencio hable. Ese momento de duda es exactamente lo que necesitas registrar.
Una técnica fundamental se llama pensar en voz alta. Le pides al usuario que diga lo que está pensando mientras navega. "Estoy buscando el menú... no lo veo... ah, está hasta abajo, qué raro." Esas palabras son oro. Te dicen exactamente qué elemento de tu diseño falló y por qué.
Para una prueba moderada básica necesitas tres cosas: un guión de tareas, papel para tomar notas y un acuerdo verbal de que el usuario puede abandonar cuando quiera. Nada más. Puedes hacerlo en una cafetería cerca de las oficinas de FEMSA o en una videollamada de Google Meet. El equipo no importa tanto como la actitud de escuchar.
Pruebas no moderadas: el usuario solo
En una prueba no moderada, el usuario completa las tareas sin que tú estés presente. Plataformas como Maze o UsabilityHub graban la pantalla y el tiempo que tarda cada persona en completar cada tarea. Tú revisas los videos después.
Esta modalidad es más rápida de coordinar. Puedes enviar un enlace a diez personas en un día. Sin embargo, pierdes la riqueza de escuchar al usuario pensar en voz alta. Para diseños simples con flujos cortos, funciona muy bien. Para flujos complejos como el proceso de facturación en el SAT, necesitas la versión moderada.
Un dato que sorprende a muchos diseñadores principiantes: el tiempo promedio que un usuario tolera estar confundido antes de abandonar una tarea es de 72 segundos. Menos de dos minutos. Si tu flujo de registro tarda más de eso en ser comprendido, estás perdiendo usuarios reales.
Cómo diseñar tareas que revelen problemas reales
El mayor error en pruebas de usabilidad es hacer preguntas en lugar de dar tareas. "¿Puedes encontrar la sección de ofertas?" es una pregunta. "Imagina que quieres aprovechar una promoción de fin de semana. Muéstrame cómo llegarías a ella" es una tarea.
Las tareas deben ser realistas y estar escritas en lenguaje del usuario, no en lenguaje del diseñador. No digas "navega al módulo de pagos". Di "quieres pagar tu saldo de este mes". Esa diferencia cambia completamente cómo el usuario interactúa con el prototipo.
Para un proyecto de diseño de una app de nómina para PyMEs mexicanas, Sofía diseñó estas tres tareas: registrar a un empleado nuevo, calcular el aguinaldo de diciembre y generar el recibo de pago en PDF. Cinco usuarios, tres tareas cada uno. En la segunda tarea, cuatro usuarios buscaron el botón de aguinaldo en el menú principal. Sofía lo había puesto dentro de la sección de "Configuración". Ese hallazgo le tomó 90 minutos de pruebas. Corregirlo le tomó 20 minutos en Figma.
Qué registrar durante la sesión
No puedes recordar todo. Por eso necesitas un sistema de registro simple. Divide tu hoja en tres columnas: qué hizo el usuario, qué dijo y qué sintió (según su lenguaje corporal o tono de voz).
Después de cada sesión, marca los momentos donde el usuario dudó más de cinco segundos, donde preguntó algo, donde se equivocó de ruta o donde expresó frustración. Esos momentos son tus áreas de oportunidad.
Con cinco usuarios, empezarás a ver patrones. Si tres de cinco personas no encontraron el botón de "Agregar al carrito" en tu diseño para Mercado Libre, ese botón necesita moverse o hacerse más visible. No es opinión. Es evidencia.
Errores comunes que debes evitar
El primero es defender tu diseño durante la prueba. Si el usuario dice "no entiendo para qué sirve este botón", tu trabajo es escuchar, no explicar. En el mundo real, tú no estarás sentado junto a cada persona que use tu producto.
El segundo error es reclutar a personas que ya conocen el producto. Si pruebas el rediseño de la app de Bimbo con empleados de Bimbo, los resultados no son representativos. Busca usuarios que se parezcan al público real: edad, nivel tecnológico, contexto de uso.
El tercero es esperar tener el diseño perfecto antes de probar. Puedes hacer una prueba de usabilidad con un prototipo en papel, con pantallas estáticas o con el prototipo interactivo de Figma que aprendiste en la lección anterior. Entre más temprano pruebes, más barato será corregir.
El cuarto error es ignorar los hallazgos porque "son solo cinco personas". Cinco usuarios bien seleccionados revelan los problemas críticos de usabilidad. No necesitas cien.
El cierre del ciclo
Vuelve a Mariana. Después de esa tarde de pruebas frustrante, identificó un problema claro: el botón de "Confirmar pago" tenía el mismo color gris que los botones desactivados. Los usuarios asumían que no podían hacer clic. Un cambio de color y el problema desapareció.
Eso es diseño UX basado en evidencia. No en intuición, no en opiniones del equipo, no en lo que tú crees que es obvio. En lo que las personas reales hacen cuando nadie las guía.
Tu camino desde aquí
En este curso recorriste el proceso completo de diseño UX/UI: desde entender qué es la experiencia de usuario, pasando por investigación, arquitectura de información, wireframes, sistemas de diseño, hasta prototipado y pruebas. Eso es el ciclo completo.
Tu siguiente paso práctico es diseñar un flujo pequeño, construir un prototipo en Figma y hacer pruebas con tres personas de tu círculo cercano. No necesitas un proyecto de empresa. Necesitas práctica real con observación real.
Un diseñador que prueba sus diseños con usuarios reales toma mejores decisiones, comete menos errores en producción y construye productos que la gente quiere usar. Ese diseñador tiene más valor en cualquier equipo, ya sea en una startup de tecnología financiera en Monterrey o en el área digital de Liverpool en Ciudad de México.
Diseñar es hacer preguntas. Evaluar es escuchar las respuestas.