Un cliente me enseñó su aplicación de onboarding hace unos meses. Cinco pasos. Diseño limpio. Todo funcional en los tests.
La tasa de abandono era del 68% en el paso tres.
Revisamos los tests de integración: pasaban todos. El formulario enviaba datos correctamente. La validación funcionaba. El CI estaba en verde. Y aun así, casi siete de cada diez usuarios salían del flujo antes de terminar.
El problema no era que la aplicación no funcionara. Era que nadie había auditado cómo se usaba.
Ahí está la diferencia que muchos developers no distinguen hasta que lo ven en métricas reales: una cosa es que el código haga lo que debe, y otra muy distinta es que el usuario pueda usarlo sin fricción. La primera la resuelves con tests. La segunda la resuelves con automatizar usabilidad con agentes de IA — que es exactamente lo que vamos a ver aquí.
Automatizar usabilidad con agentes de IA consiste en delegar la auditoría de accesibilidad, flujos de usuario y fricciones de interfaz a un agente — como Claude Code con MCP de Playwright — que controla el navegador de forma programática, navega flujos reales y genera un reporte estructurado de hallazgos sin intervención manual.
Testing funcional vs. testing de usabilidad
Un test funcional pregunta: ¿el botón de "Enviar" llama a la función correcta?
Un test de usabilidad pregunta: ¿el usuario sabe que tiene que hacer clic ahí? ¿Lo ve? ¿Entiende qué va a pasar después?
Son preguntas distintas y se responden con herramientas distintas.
Los tests funcionales los escribes tú, los corre un CI, comprueban comportamiento esperado. Eso ya lo sabes hacer. Lo que un agente de IA aporta es la capacidad de navegar tu aplicación como si fuera un usuario — explorar rutas no documentadas, detectar elementos sin etiquetas accesibles, medir cuánto tarda en responder una pantalla, o identificar que un campo de error aparece debajo del scroll y el usuario nunca lo ve.
No te reemplaza un test de usabilidad con personas reales. Pero te da un nivel de auditoría automatizada que antes no existía — y que tú nunca harías manualmente en cada PR. Si quieres ver cómo encaja esto en un pipeline completo de desarrollo, tienes la explicación en el post sobre automatizar el proceso de desarrollo con IA.
Qué puede detectar un agente
Cuando conectas Claude Code con el MCP de Playwright o Chrome DevTools, el agente puede controlar el navegador de forma programática. Eso significa que puede:
- Navegar a cualquier ruta de tu aplicación
- Hacer clic en elementos, rellenar formularios, desplazarse por la página
- Leer el DOM y el árbol de accesibilidad (el que usa un lector de pantalla)
- Medir tiempos de respuesta entre interacciones
- Ejecutar axe-core para detectar violaciones WCAG
- Capturar screenshots en cada paso del flujo
- Generar un reporte estructurado con los hallazgos
Lo que un agente detecta bien:
- Accesibilidad técnica: imágenes sin
alt, botones sinaria-label, contraste insuficiente entre texto y fondo, formularios sin etiquetas asociadas, skip navigation ausente, foco de teclado atrapado en un componente modal. - Fricciones estructurales: mensajes de error fuera del viewport, campos obligatorios que no se identifican como tales hasta el submit, pasos de onboarding que no guardan el progreso si el usuario recarga.
- Performance percibida: cuánto tarda en aparecer el primer elemento interactivo después de una navegación, si hay loaders sin indicación de progreso, si el layout shift hace que el usuario haga clic en el elemento equivocado.
- Cobertura de flujos: si una ruta de error (credenciales incorrectas, sesión expirada, red caída) termina en una pantalla sin instrucciones claras.
Cómo configurar el agente para automatizar la auditoría de usabilidad
La combinación que funciona en producción: Claude Code + MCP de Playwright.
Para instalarlo: npx @playwright/mcp@latest. Una vez activo en tu configuración de Claude Code, el agente tiene acceso a las herramientas de control del navegador sin que escribas una línea de Playwright.
El MCP de Playwright expone herramientas al agente para controlar el navegador: browser_navigate, browser_click, browser_type, browser_snapshot, browser_evaluate. Claude puede encadenar esas herramientas para ejecutar flujos completos.
Un ejemplo de instrucción al agente para auditar el onboarding de una app:
## Tarea: Auditoría de usabilidad — flujo de onboarding
URL base: http://localhost:4200
Flujo a auditar:
1. Navega a /register
2. Rellena el formulario con datos válidos: nombre, email, contraseña
3. Haz clic en "Crear cuenta"
4. Completa los pasos del onboarding hasta llegar al dashboard
En cada paso:
- Captura un screenshot
- Extrae el árbol de accesibilidad del contenido principal
- Identifica elementos interactivos sin aria-label o sin texto visible
- Mide el tiempo hasta que el siguiente paso es interactivo
- Detecta si hay mensajes de error o advertencia y si son visibles sin scroll
Al terminar, genera un reporte en formato JSON con esta estructura:
{
"paso": string,
"url": string,
"tiempo_carga_ms": number,
"violaciones_accesibilidad": [],
"fricciones_detectadas": [],
"screenshot": string
}
El agente ejecuta eso de forma autónoma. Navega, interactúa, observa, y vuelve con un reporte estructurado.
Accesibilidad automática con axe-core
Para violaciones WCAG, la integración más sólida es axe-core. El agente puede ejecutarlo sobre cualquier página activa en el navegador mediante browser_evaluate:
// Si axe-core no está en el bundle de la app, inyectarlo primero:
// await page.addScriptTag({ url: 'https://cdn.jsdelivr.net/npm/axe-core/axe.min.js' });
// Ejecutar la auditoría en el contexto de la página
const results = await axe.run();
return {
violaciones: results.violations.map(v => ({
impacto: v.impact,
descripcion: v.description,
elementos: v.nodes.map(n => n.target)
}))
};
Lo que devuelve axe-core son violaciones categorizadas por impacto: critical, serious, moderate, minor. El agente puede filtrar solo las críticas, agregar el selector del elemento afectado, y generar una lista accionable para el developer.
Esto detecta cosas como:
- Contraste de color insuficiente (ratio menor a 4.5:1 para texto normal)
- Imágenes sin atributo
alto conaltvacío en imágenes informativas - Elementos
<div>y<span>usados como botones sin rol ARIA - Formularios sin
<label>asociado o conplaceholdercomo único identificador - Encabezados fuera de jerarquía (
<h4>después de<h2>sin<h3>)
Esta es una de las capacidades que trabajamos en detalle en el curso Construye con IA: cómo delegar auditorías estructuradas al agente para que el developer se centre en las decisiones de producto, no en el checklist técnico.
El reporte de hallazgos
Un agente que navega y detecta problemas no sirve de nada si los hallazgos terminan en un log de consola que nadie lee.
El formato que mejor funciona para integrar en un workflow de desarrollo es un JSON estructurado que puedas convertir en un issue de GitHub, una tarea en Linear, o un comentario en un PR.
Estructura mínima de reporte que el agente genera:
{
"auditoria": {
"fecha": "2026-06-17",
"url_base": "https://app.ejemplo.com",
"flujo": "onboarding",
"duracion_total_ms": 8420
},
"resumen": {
"violaciones_criticas": 3,
"violaciones_serias": 7,
"fricciones_detectadas": 4,
"pasos_con_retraso": 2
},
"hallazgos": [
{
"paso": "registro",
"tipo": "accesibilidad",
"impacto": "critical",
"descripcion": "Campo de contraseña sin label asociado. Solo usa placeholder.",
"selector": "#password-input",
"referencia_wcag": "1.3.1"
},
{
"paso": "paso-2-perfil",
"tipo": "friccion",
"impacto": "serious",
"descripcion": "Mensaje de validación aparece 280px por debajo del campo en mobile. No visible sin scroll.",
"selector": ".validation-message",
"screenshot": "paso-2-error-state.png"
}
]
}
Este reporte lo puedes consumir directamente en tu pipeline de CI, enviarlo a un webhook de Slack, o procesarlo con otro agente que abra los issues correspondientes.
Agentes IA vs Lighthouse
| Capacidad | Lighthouse | Agente IA + MCP Playwright |
|---|---|---|
| Métricas de rendimiento (LCP, CLS, FID) | ✅ | ❌ |
| Accesibilidad estática (axe-core) | ✅ | ✅ más granular |
| Flujos interactivos multipaso | ❌ | ✅ |
| Estados de error y modales | ❌ | ✅ |
| Reporte adaptado al contexto del proyecto | ❌ | ✅ JSON estructurado |
| Requiere código de automatización | ❌ | ❌ lenguaje natural |
| Integración en CI/CD | ✅ | ✅ |
Lighthouse mide el estado de una página en un instante. Un agente mide cómo un usuario real la recorre.
Lo que el agente no puede hacer
Esto es importante. Un agente mide lo que puede observar en el DOM y en el comportamiento de la interfaz. No puede medir lo que ocurre dentro del usuario.
No detecta:
- Frustración emocional. Si el flujo es técnicamente correcto pero genera ansiedad porque el lenguaje es frío o las instrucciones son ambiguas, el agente no lo sabe.
- Preferencias estéticas. El contraste puede pasar el ratio WCAG y aun así resultar incómodo visualmente en contextos específicos.
- Contexto cultural. Un ícono que es intuitivo para un usuario europeo puede no serlo para un usuario latinoamericano. El agente no tiene ese mapa cultural.
- Carga cognitiva subjetiva. Puede detectar que hay ocho campos en un formulario, pero no puede decirte si eso es demasiado para tu audiencia específica.
- Microcopy y confianza. El texto de un CTA puede ser técnicamente legible y aun así no generar suficiente confianza para que el usuario haga clic.
Esas decisiones siguen siendo tuyas — o del diseñador, o del researcher de UX. Lo que el agente elimina es el trabajo de auditoría técnica repetitiva que de otra forma no harías en cada ciclo de desarrollo.
Cómo integrarlo en tu workflow
El patrón que funciona sin complicar el pipeline:
- Local, bajo demanda: el developer lanza la auditoría sobre la rama antes de abrir el PR. El agente revisa el flujo afectado por el cambio.
- En CI, sobre entornos de preview: cada PR despliega a un entorno de preview (Vercel, Netlify, Railway), y el agente audita ese entorno de forma automática antes del merge.
- Semanal, sobre producción: un job programado lanza la auditoría completa sobre la app en producción y genera un reporte que llega al equipo.
El tercer nivel es el más valioso a largo plazo: detecta regresiones de accesibilidad que se cuelan en producción sin que nadie las vea en los tests unitarios.
El paso de code review automático antes del PR — que complementa esta auditoría de usabilidad — lo explico en detalle en el post sobre agentic code review con Claude Code.
Si quieres ver cómo construir este tipo de pipelines con agentes desde cero, en Dominicode Labs tenemos proyectos completos que aplican exactamente este enfoque — desde la configuración del MCP hasta la generación del reporte final.
FAQ
¿Necesito conocer Playwright para esto?
No necesitas escribir código Playwright. El MCP abstrae las herramientas de control del navegador y el agente las usa directamente. Basta con que describas el flujo que quieres auditar en lenguaje natural.
¿axe-core cubre todos los criterios WCAG?
Cubre los criterios que son detectables automáticamente — menos de la mitad de los criterios de WCAG 2.1. El resto requiere evaluación humana. Pero ese 30-40% incluye los problemas más comunes y los más graves.
¿El agente puede auditar aplicaciones con autenticación?
Sí. Puedes darle al agente las credenciales de una cuenta de prueba, o configurar el MCP para que arranque el navegador con una sesión ya autenticada. El agente navega como un usuario real, incluyendo el flujo de login.
¿Qué diferencia hay entre esto y Lighthouse?
Lighthouse audita métricas de performance, SEO básico y accesibilidad en un snapshot estático. Un agente con MCP de Playwright puede auditar flujos interactivos completos — formularios multipaso, modales, estados de error, interacciones con el teclado — y generar reportes adaptados a tu contexto específico, no a un checklist genérico.
¿Puedo usar esto con cualquier framework frontend?
Sí. El agente interactúa con el navegador, no con el framework. Funciona igual con Angular, React, Vue o cualquier app renderizada en el cliente o en el servidor.
La próxima vez que un cliente te muestre métricas de abandono con todos los tests en verde, ya sabes qué está pasando — y cómo resolverlo.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
Leave a Reply