QA visual con IA: validar que la implementación coincide con el Figma

Hay una distancia incómoda entre el Figma que diseña el equipo de UX y lo que finalmente llega a producción. En el diseño, cada margen está pensado, cada color es el correcto y cada componente está en su sitio. En la implementación, en cambio, se cuela un padding de menos, un gris que no es exactamente ese gris, un botón que quedó cuatro píxeles más abajo o un estado que nadie maquetó. Ninguna de esas cosas rompe la aplicación. Todas, juntas, hacen que el producto deje de parecerse a lo que se diseñó. A esa distancia la llamamos deriva de diseño, y es justo lo que quisimos atacar en uno de los experimentos de nuestro Lean Improvements Day, la jornada interna en la que construimos prototipos con IA sin la presión de que salgan perfectos.

La idea es simple de enunciar y sorprendentemente difícil de hacer a mano: un ojo de IA que mire una historia de usuario ya implementada y valide, como lo haría una persona de diseño, si el resultado se corresponde con el Figma original a un nivel del 99%. Antes de entrar en materia, la aclaración de siempre: esto es un experimento, un prototipo open-source en evolución, no un producto terminado. Os contamos qué construimos, cómo funciona y qué aprendimos.

El problema: la QA de diseño se hace a ojo, se hace tarde o no se hace

Cuando una historia de usuario toca interfaz, alguien debería comprobar que lo implementado coincide con el diseño acordado. En la práctica, esa comprobación es de las primeras que se sacrifican bajo presión. La hace una persona, a ojo, comparando dos pestañas: el Figma en una, la aplicación en la otra. Es un trabajo tedioso, subjetivo y lento, y por eso acaba pasando una de tres cosas: se hace deprisa y corriendo, se hace tarde (cuando cambiarlo ya cuesta), o directamente no se hace.

El resultado es acumulativo y silencioso. Ninguna desviación individual parece grave, pero la suma va erosionando la coherencia visual del producto hasta que el diseño real y el diseño soñado son dos cosas distintas. Y recuperar esa coherencia a posteriori, cuando ya hay veinte pantallas que se han ido de madre, es carísimo.

El problema de fondo es que validar fidelidad al diseño es una tarea de comparación repetitiva, exactamente el tipo de trabajo en el que las personas nos cansamos y la máquina no. Pero no vale cualquier máquina: un test que compare píxel a píxel se ahoga en falsos positivos. Necesitábamos algo que mirara con criterio.

Ruido frente a desviación real: la distinción que lo cambia todo

La clave del experimento es que no todas las diferencias entre el Figma y la implementación importan igual. Hay dos categorías, y confundirlas es la raíz de la frustración con las herramientas clásicas.

Por un lado está el ruido tolerable. Son diferencias reales, pero que no representan un fallo de fidelidad al diseño:

• Antialiasing y renderizado de fuentes: el suavizado de bordes de texto e iconos varía entre el motor de Figma y el navegador que pinta la aplicación.
• Diferencias de subpíxel: un elemento desplazado una fracción de píxel por cómo redondea el layout el navegador.
• Timing de animación o contenido dinámico: una captura tomada un instante antes o después, un avatar de ejemplo distinto, una fecha que cambia.

Por otro lado está la desviación real, la que sí rompe la correspondencia con el diseño:

• Espaciado y layout: paddings y márgenes que no respetan el diseño, elementos descolocados, una rejilla que no cuadra.
• Color, tipografía y tamaños: un color fuera de la paleta, un peso de fuente distinto, un tamaño de texto que no es el especificado.
• Elementos que faltan o sobran: un icono que no se implementó, un estado vacío que nadie maquetó, un botón que aparece donde no debía.

Una herramienta que cuenta píxeles no distingue estas dos categorías: para ella, un texto que se re-renderiza (ruido) puede afectar a más píxeles que un botón desplazado (desviación real). Por eso contar no sirve. Hay que leer intención de diseño, no volumen de píxeles.

Cómo funciona el ojo de IA

El prototipo sigue un flujo que va desde las dos imágenes de partida hasta un veredicto accionable.

1. Figma de diseño frente a pantalla implementada

El punto de partida son dos entradas: el diseño de referencia (el Figma que produjo UX, la fuente de la verdad) y la implementación (la captura de la pantalla real de la historia ya construida). El diseño hace de baseline; la implementación es lo que se pone a examen.

2. Alinear y comparar como lo haría una persona

En lugar de superponer píxeles a ciegas, el ojo de IA alinea ambas imágenes y las interpreta a nivel de composición: identifica bloques, textos, controles y espacios. La pregunta que se hace no es cuántos píxeles cambiaron, sino la misma que se haría un diseñador: ¿esto se parece a lo que diseñamos?.

3. Detectar desviaciones por regiones y calcular severidad

Las diferencias se agrupan en regiones revisables (esta cabecera, este formulario, este pie), no en una nube de puntos rojos imposible de interpretar. A cada región le asigna una severidad, ponderando si parece ruido de renderizado o una desviación de diseño de verdad. Así, en vez de una alarma indiferenciada, obtienes un mapa de qué zonas cumplen y cuáles no, ordenadas por importancia.

4. Puntuar la fidelidad y dar un veredicto

El resultado se resume en un nivel de fidelidad respecto al diseño, con un objetivo de referencia en torno al 99%, acompañado de un veredicto claro y explicado para que lo entiendan por igual QA, diseño y desarrollo: la implementación coincide con el diseño, necesita revisión en zonas concretas, o no coincide y hay que corregir antes de dar la historia por terminada. Cada veredicto viene con el porqué, no con un simple pasa o falla.

Qué significa el umbral del 99% (y por qué no 100%)

Perseguir el 100% de coincidencia píxel a píxel es una trampa: por el ruido de renderizado que ya hemos visto, dos capturas idénticas en intención nunca son idénticas en píxeles. Por eso el objetivo no es la identidad perfecta, sino una fidelidad alta y con criterio: que todo lo que importa (espaciado, color, tipografía, presencia de elementos) cuadre, y que lo que no cuadra sea ruido explicable.

Fijar el umbral en torno al 99% es una forma de decir dos cosas a la vez. Primero, que la vara es exigente: no vale un parecido razonable. Y segundo, que se acepta el margen inevitable del renderizado, para no ahogar al equipo en falsos positivos. Ese umbral es, además, una palanca de conversación: un equipo puede decidir que ciertas pantallas críticas exigen más y otras menos.

El artefacto y la Definition of Done de la UI

Cada comparación genera un artefacto exportable: un resumen autocontenido con el nivel de fidelidad, las regiones que se desvían, su severidad y el veredicto. Ese artefacto se puede adjuntar a la pull request o al ticket de la historia. La revisión deja de ser un cara a cara entre pestañas y pasa a ser una evidencia compartida: aquí está la comparación, aquí están las zonas marcadas y aquí el porqué.

Esto conecta con algo que en LeanImprovements nos importa mucho: la Definition of Done. Si una historia toca interfaz, su definición de terminada puede incluir de forma explícita que la implementación coincide con el diseño por encima del umbral acordado. La fidelidad al Figma deja de ser una opinión de última hora y se convierte en un criterio de aceptación objetivo y comprobable.

Cómo encaja en el flujo de UX a desarrollo

El encaje natural es cerrar el ciclo entre diseño e implementación. UX produce el Figma; desarrollo implementa la historia; y antes de darla por hecha, el ojo de IA compara ambas y emite su veredicto. En un flujo con integración continua, esa comprobación puede correr sobre cada historia que toque UI: una fidelidad alta pasa sin fricción, una intermedia pide una mirada humana, y una baja avisa con contundencia de que la implementación se ha ido del diseño. El objetivo no es añadir otra alarma más, sino sustituir la revisión manual a ojo por una señal con criterio y trazable.

Qué aprendimos construyéndolo

La primera lección fue que el problema casi nunca es detectar diferencias, sino interpretarlas. Comparar imágenes es viejo; decir si una diferencia traiciona el diseño o es puro renderizado es lo difícil, y es justo donde un enfoque con IA aporta valor frente a un diff de píxeles.

La segunda: agrupar por regiones y hablar el idioma del diseño (espaciado, color, jerarquía) en lugar del idioma de los píxeles reduce muchísimo la fatiga, incluso antes de afinar la puntuación. Reducir el número de decisiones que una persona tiene que tomar ya es media batalla ganada.

Y la tercera, quizá la más importante: poner un número a la fidelidad, con un umbral acordado, transforma una discusión subjetiva (a mí me parece que está bien) en un criterio compartido. No para sustituir el ojo humano, sino para reservarlo justo para las zonas donde de verdad hace falta.

Como referencia ilustrativa, y lo decimos como tal, hablamos de tres tipos de veredicto (coincide, revisar, no coincide), de un objetivo de fidelidad en torno al 99% y de un artefacto exportable por comparación. Son cifras orientativas de un prototipo, no métricas de un despliegue en cliente.

El Figma siempre fue la promesa. Lo interesante, lo que nos apetece seguir explorando, es enseñarle a una máquina a comprobar si esa promesa se cumple.