Tu equipo lleva meses construyendo el nuevo flujo de apertura de cuenta. Diseño lo aprobó, QA no encontró errores críticos y la demo con el comité salió bien. Luego sale a producción y la tasa de abandono en el paso de validación de identidad es mucho más alta de lo esperado. Nadie se equivocó técnicamente. Lo que faltó fue ver a personas reales intentando usarlo. Para eso existen las pruebas de usabilidad: sesiones en las que usuarios con el perfil de tu cliente intentan completar tareas concretas mientras observas qué hacen, dónde dudan y dónde abandonan.
Esta guía es para product managers, líderes de QA y directores digitales que necesitan decidir cómo, cuándo y con quién hacer un test de usabilidad. Vamos a lo práctico.
Qué son las pruebas de usabilidad y qué responden
Una prueba de usabilidad responde una pregunta simple: ¿puede una persona como mi cliente completar esta tarea sin ayuda, en un tiempo razonable y sin frustrarse?
La tarea siempre es concreta. "Abre una cuenta desde la app", "recarga 20.000 pesos a otro número", "paga la póliza del carro con tarjeta débito". El participante la intenta, idealmente pensando en voz alta, y el equipo observa.
De ahí salen tres tipos de datos:
- Efectividad: cuántos completaron la tarea.
- Eficiencia: cuánto tiempo y cuántos intentos les tomó.
- Satisfacción y comprensión: qué entendieron, qué esperaban encontrar y cómo se sintieron.
Lo que no responde una prueba de usabilidad es si el producto tiene mercado. Para eso hay pruebas de concepto. Aquí partimos de que la idea ya está validada y queremos saber si la ejecución funciona.
Tipos de test de usabilidad
No hay un formato único. La elección depende de qué tan maduro está el producto, qué tan sensible es el flujo y qué necesitas aprender.
Moderadas y no moderadas
En una prueba moderada, un investigador acompaña al participante en tiempo real, le da las tareas y hace preguntas de seguimiento. Sirve cuando necesitas entender el porqué: por qué el usuario no encontró el botón de transferir, qué pensó que significaba "saldo disponible".
En una prueba no moderada, el participante recibe las tareas por una plataforma y las resuelve solo, normalmente grabando pantalla y voz. Es más rápida y permite más participantes, pero pierdes la oportunidad de repreguntar. Funciona bien para flujos cortos y para comparar versiones.
Remotas y presenciales
Las pruebas remotas permiten llegar a usuarios en distintas ciudades o países sin mover a nadie. Para una app de banca o una billetera digital suelen ser la opción natural, porque el usuario la usa desde su propio celular y su propia red.
Las pruebas presenciales tienen sentido cuando el contexto físico importa: un cajero automático, un punto de venta, un kiosco de autoservicio, o personas con discapacidad que usan tecnologías de apoyo que conviene observar de cerca.
Prototipo o producto en vivo
Probar sobre un prototipo es lo más barato porque corriges antes de desarrollar. Es el momento de evaluar arquitectura de información, textos y orden de los pasos. En Paruma esto es lo que hacemos en el servicio para evaluar prototipos.
Probar sobre el producto en vivo (o en un ambiente beta) te muestra lo que un prototipo no puede: tiempos de carga reales, validaciones de backend, mensajes de error, comportamiento en distintos dispositivos y redes. Para esa etapa está el servicio para evaluar productos con usuarios reales.
Con cuántos usuarios hacer las pruebas de usabilidad
La referencia más citada es la de Nielsen Norman Group: con unos 5 usuarios por ronda encuentras la mayoría de los problemas importantes de un flujo. La clave está en "por ronda" y en "por perfil".
En la práctica:
- Un perfil, un flujo: 5 a 8 participantes por ronda.
- Varios perfiles muy distintos: una ronda por perfil. Un pensionado que usa la app una vez al mes no se comporta como un joven que paga todo desde el celular.
- Mediciones cuantitativas (porcentaje de éxito, comparación entre versiones): necesitas muestras más grandes, de decenas o cientos de personas.
- Validaciones técnicas con mucha variación, como biometría o lectura de documentos: también muestras grandes, porque el problema depende del dispositivo, la cámara, la luz y el estado del documento.
Es mejor hacer tres rondas pequeñas con correcciones en medio que una sola ronda grande al final.
Cómo hacer una prueba de usabilidad paso a paso
- Define la decisión que vas a tomar. "Queremos saber si el nuevo registro reduce los abandonos en el paso de datos personales" es útil. "Queremos saber qué opinan de la app" no lo es.
- Elige las tareas. Entre 3 y 6 tareas realistas, redactadas como objetivos y no como instrucciones. "Pagaste el servicio de luz y quieres guardar el comprobante" en lugar de "toca el botón de descargar".
- Define el perfil de participantes. Edad, ciudad, dispositivo, experiencia con apps financieras, si son clientes o no. Aquí está la mitad del éxito: reclutar mal invalida todo lo demás.
- Prepara el ambiente. Prototipo navegable, ambiente beta con datos de prueba o producción controlada. Revisa que nada se rompa antes de la primera sesión.
- Haz una sesión piloto. Una persona, para ajustar tareas confusas y tiempos.
- Ejecuta las sesiones. Observa sin ayudar. Si el participante pregunta "¿y ahora qué hago?", devuelve la pregunta: "¿qué harías tú?".
- Analiza por patrones. Un problema que le pasa a una persona es una anécdota. Si le pasa a cuatro de cinco, es un hallazgo.
- Prioriza y corrige. Ordena por severidad e impacto en el negocio, corrige y vuelve a probar.
Qué entregables esperar de un servicio de pruebas de usabilidad
Si contratas un servicio de pruebas de usabilidad, exige más que grabaciones. Un buen entregable incluye:
- Resumen ejecutivo con las decisiones recomendadas, legible en cinco minutos por alguien que no estuvo en las sesiones.
- Hallazgos priorizados por severidad, con evidencia (citas, clips, capturas) y el paso exacto del flujo donde ocurre.
- Indicadores por tarea: tasa de éxito, tiempo, número de intentos y percepción del usuario.
- Recomendaciones accionables, no solo diagnósticos. "Cambiar el texto del botón de 'Continuar' a 'Tomar foto del documento'" es accionable.
- Perfil real de los participantes, para que sepas a quién representa cada hallazgo.
- Grabaciones y material crudo para que tu equipo de diseño las revise.
Cuándo contratar un proveedor en lugar de hacerlo internamente
Hacer pruebas internas tiene sentido cuando el equipo tiene un investigador con tiempo, el perfil de usuario es fácil de conseguir y el flujo no es sensible. Contratar un proveedor conviene cuando:
- Necesitas perfiles difíciles: personas de cierta edad, en ciudades específicas, con un banco particular, con discapacidad visual o en otro país.
- El flujo es regulado o delicado: apertura de cuentas, validación de identidad, crédito, pagos.
- Necesitas variedad de dispositivos: gamas bajas, sistemas operativos antiguos, redes lentas.
- Necesitas neutralidad. Un equipo externo no tiene apego al diseño y los participantes son más honestos con alguien que no hizo el producto.
- El tiempo es corto y no puedes detener al equipo para reclutar, moderar y analizar.
En Paruma trabajamos desde 2016 con una comunidad de más de 2.500 participantes por país, más de 65 criterios de perfilación y más de 5.000 dispositivos digitales, lo que permite armar muestras específicas sin empezar de cero.
Pruebas con usuarios reales: casos de Paruma
Tres ejemplos de cómo se ven estas pruebas en la práctica:
- Registro de una billetera digital en tres países. Zinli quería simplificar su registro. Se evaluó un prototipo funcional de alta fidelidad con usuarios de Panamá, Venezuela y Colombia, de distintas edades y niveles de familiaridad con billeteras digitales. La experiencia fue consistente entre países, la organización de la información recibió buenas calificaciones y salieron oportunidades para hacer el registro más rápido y para dar instrucciones más claras. Lee el caso de Zinli.
- Pago en línea de seguros. Sura evaluó con usuarios reales de distintas edades, niveles socioeconómicos y ciudades la versión beta de Pago Express en su sitio web. Los usuarios entendieron bien el proceso de pago, la empresa conservó elementos de la versión anterior que la gente prefería e identificó mejoras en los filtros de búsqueda de pagos. Detalles en el caso de Pago Express de Sura.
- Una funcionalidad de finanzas personales. En el caso de "Día a Día" de Bancolombia, la prueba confirmó que los usuarios preferían categorizar sus gastos en cualquier momento después de la transacción, un dato que solo aparece observando el uso real.
Preguntas frecuentes
¿Cuántos usuarios necesito para una prueba de usabilidad?
Para encontrar los problemas principales de un flujo, Nielsen Norman Group recomienda rondas de unos 5 usuarios por perfil. Si tienes varios perfiles muy distintos (por ejemplo, clientes nuevos y clientes con años en el banco), haz una ronda por perfil y repite después de corregir.
¿Qué diferencia hay entre un test de usabilidad y una encuesta?
La encuesta mide lo que la gente dice que piensa. El test de usabilidad observa lo que la gente hace cuando intenta completar una tarea real, como registrarse o pagar. Ambos se complementan, pero solo el test muestra dónde se traba el usuario y por qué.
¿Puedo hacer pruebas de usabilidad sobre un prototipo?
Sí, y es lo más rentable. Un prototipo navegable en Figma o similar permite corregir problemas antes de que el equipo de desarrollo escriba una sola línea. Lo importante es que el prototipo cubra el flujo completo que vas a evaluar.
¿Cuánto tiempo toma una prueba de usabilidad con un proveedor?
Depende del alcance, el número de perfiles y si la prueba es moderada o no moderada. Como referencia, una evaluación típica toma entre una y cuatro semanas, incluyendo reclutamiento, sesiones, análisis e informe.
¿Las pruebas internas con empleados sirven como prueba de usabilidad?
Sirven para detectar errores evidentes, pero no reemplazan a usuarios reales. Tus empleados conocen el producto, la jerga y el contexto del negocio, así que completan tareas que un cliente nuevo no lograría. Por eso conviene probar con personas que se parezcan a tu cliente real.
¿Vas a lanzar o rediseñar un flujo?
Si tienes un prototipo listo o una versión beta que quieres validar antes de llevarla a todos tus clientes, cuéntanos qué flujo es, qué perfil de usuario necesitas y para cuándo debes tomar la decisión. Te proponemos el formato de prueba que mejor encaje. Escríbenos aquí.
