Una referencia visual puede ahorrar mucho trabajo. También puede hacer que demos por buenas decisiones que nadie ha comprobado.
«Hazme una web como esta». Es un encargo perfectamente comprensible. Encuentras una página que te gusta, se la enseñas a un agente de programación y esperas que construya algo parecido. Si además ha ganado un premio, la elección parece bastante segura. Alguien que sabe de diseño ya la ha valorado.
La tipografía, los espacios, las animaciones, ese gris discreto que parece estar en todas partes. Hay mucho que aprender mirando el trabajo de otros. El problema aparece cuando, junto con la apariencia, importamos una certeza que la referencia no nos ha dado: que todo aquello funciona bien.
Construyendo UXMachine me encuentro cada vez más con esta distancia entre lo que una web aparenta y lo que puedo afirmar después de comprobarla. Y creo que trabajar con agentes la vuelve especialmente relevante. Podemos reproducir una solución antes de haber entendido qué problema resolvía. A veces, incluso antes de preguntárnoslo.
Diseño cargo cult: copiar la forma sin entender las decisiones
En su discurso de 1974 en Caltech, Richard Feynman recurrió a una imagen que se hizo famosa: pistas de aterrizaje, auriculares de madera y antenas de bambú construidos para intentar recuperar la llegada de aviones con suministros. La apariencia del sistema estaba reproducida; faltaba aquello que lo hacía funcionar.
Lo llamó cargo cult science: prácticas que imitan las formas de la investigación científica sin asumir el rigor que les da sentido. Me interesa esa metáfora para pensar en el diseño, sin tomar la anécdota como una explicación de las sociedades del Pacífico.
En una web podemos copiar el tamaño de un titular, pero desconocer por qué se eligió. Podemos reproducir una navegación sin saber qué alternativas se descartaron. Podemos enamorarnos de una portada sin haber recorrido el proceso que empieza después de pulsar el botón.
Esto ya ocurría antes de la IA. Lo que cambia es la facilidad con la que pasamos de admirar una referencia a tener una versión propia. Ese ahorro es extraordinario. Pero el tiempo que ahorramos construyendo no resuelve las preguntas que dejamos sin hacer.
Qué sabemos realmente de una web que ha ganado un premio
Un premio es una señal de reconocimiento. Puede ayudarnos a descubrir trabajo interesante y decisiones que merece la pena estudiar. Yo no veo ningún motivo para renunciar a eso.
Lo que me cuesta aceptar es el salto siguiente: tratar ese reconocimiento como una garantía para cualquier uso de la web. Que una página destaque visualmente no nos dice, por sí solo, cómo se lee un texto concreto, cómo está declarado un formulario o qué ocurre en las páginas menos visibles.
Además, al escoger una referencia solemos ver una parte muy pequeña. La portada recibe toda nuestra atención. La página de acceso, la recuperación de contraseña o un mensaje de error rara vez acaban en la carpeta de inspiración.
Si el encargo al agente se limita a reproducir lo que nos ha gustado, esas otras partes pueden quedar fuera de la conversación. Y, cuando finalmente aparecen, ya estamos pensando en publicar.
Lo que apareció al medir webs premiadas con UXMachine
Esta pregunta dio lugar a una nota de campo sobre webs premiadas. El punto de partida fueron webs de producto reconocidas con el «Site of the Day» de Awwwards, en ámbitos como SaaS, herramientas para desarrolladores e IA.
Medí doce webs el 18 de octubre de 2026 y publiqué seis casos. Dos bloquearon al robot; otras dos superaron el tiempo de captura; una no declaraba su idioma, un requisito para publicar el caso. Y otra quedó fuera por un defecto de UXMachine: al fallar la lectura de un robots.txt, el informe colocaba una frase interna donde debían ir datos de la web. Ese fallo era nuestro.
UXMachine abre las páginas en un navegador real, a 1280 y 390 píxeles de ancho, y aplica comprobaciones fijas. Estos resultados describen lo capturado aquel día, no el estado actual de esas webs ni toda la experiencia de utilizar cada producto.
En cuatro de los seis casos aparecieron textos con contraste insuficiente. En Made With GSAP, «See how the platform works:» tenía una relación de 2,84:1: gris #999999 sobre blanco, en seis de las nueve páginas leídas. El criterio de contraste mínimo de WCAG establece, con excepciones, 4,5:1 para texto normal y 3:1 para texto grande.
Podemos discutir esa combinación de colores con un dato. No podemos deducir su efecto en las ventas. Y hay un límite especialmente relevante aquí: UXMachine no mide el contraste sobre imágenes o degradados cuando no puede determinar el fondo con fiabilidad.
También aparecieron páginas sin un encabezado principal H1 en cuatro casos. En Cerebrium y Fourmula.ai eran las páginas de acceso, justo las que nadie guarda como referencia; en Made With GSAP, una página de efectos; en Zero, la portada. Puede haber un texto que parezca un título sin estar declarado como H1. La captura y la estructura cuentan cosas diferentes.
En los seis casos se observaron conexiones con dominios externos antes de interactuar. Esa observación tampoco basta para calificarlas de indebidas. Hay que averiguar qué se solicita y para qué. Convertir el dato en una acusación sería repetir el error que intento evitar: hacer que una medida diga más de lo que sabe.
Un informe con pocos hallazgos puede estar casi sin comprobar
El caso que más me interesa es Shift5. El aviso de cookies no se pudo cerrar en ninguna de las diez páginas revisadas y ocho de las trece comprobaciones no pudieron hacerse.
Si uno se queda con la lista de observaciones, puede interpretar que hay poco que revisar. Pero esa lectura pierde precisamente la información que explica el resultado: buena parte del trabajo previsto no se pudo completar.
Tampoco sería correcto concluir lo contrario, que la web es mala porque nuestra herramienta no pudo comprobarla. Lo que tenemos es una limitación de esa medida. Para saber más haría falta revisarla por otra vía.
Esto cambia bastante cómo leo un informe. Ya no me basta con contar lo encontrado. Necesito saber qué se intentó comprobar y qué quedó fuera. Dos informes con una sola observación pueden representar situaciones completamente distintas: uno ha revisado casi todo su alcance; el otro apenas ha podido empezar.
El segundo puede resultar más tranquilizador precisamente porque contiene menos información. Ahí está la trampa.
Qué pedirle a un agente antes de dar una web por terminada
En otro artículo contaba qué ocurre cuando el agente dice que la página está lista. A veces, al preguntar qué ha comprobado, descubro que no ha abierto la versión móvil o que ha dejado partes sin revisar.
Con una referencia premiada puede ocurrir algo parecido. El parecido es fácil de enseñar. Las comprobaciones, en cambio, hay que pedirlas.
Por eso, el encargo debería explicar qué queremos tomar de la referencia: la composición, el tratamiento de las imágenes, la jerarquía. También qué debe comprobarse en nuestra versión, con nuestros textos y nuestras páginas. Copiar una solución no nos ahorra verificarla en el contexto donde acabará funcionando.
Al recibir el trabajo, me parece razonable pedir tres cosas:
- Qué ha comprobado el agente.
- Con qué evidencia.
- Qué sigue sin comprobar.
Si solo ha revisado una captura de escritorio, necesitamos saberlo. Si ha probado un formulario, necesitamos saber hasta dónde llegó la prueba.
Después de un cambio toca volver a comprobar la parte afectada. Y conservar las condiciones de la revisión anterior para poder comparar. Si ahora un aviso impide acceder al contenido, que ya no aparezca un hallazgo anterior no demuestra que lo hayamos corregido.
Nada de esto exige convertir cada entrega en una auditoría interminable. Exige que «terminado» tenga un significado compartido y que podamos decidir si lo pendiente permite publicar.
Medir lo básico tampoco demuestra que el diseño funcione
Hay una tentación bastante evidente en este artículo: utilizar seis casos para descalificar los premios y presentar mi herramienta como quien descubre la verdad. Sería cómodo, sobre todo porque soy quien la construye. También sería una conclusión que estos datos no sostienen.
Seis casos no representan al conjunto de webs premiadas. Las dificultades de captura limitan el ejercicio. Y las comprobaciones mecánicas dejan fuera muchas cosas importantes: entender la propuesta, confiar en quien la ofrece, orientarse o conseguir completar una tarea.
Lo mismo vale para la IA. Un agente puede ayudarnos a verificar lo que construye si dispone de herramientas y de un encargo adecuado. El problema aparece cuando aceptamos su seguridad como prueba suficiente, igual que antes aceptábamos el premio o la buena apariencia.
También hay una responsabilidad en cómo contamos estos ejercicios. Si publico los fallos encontrados pero escondo lo que mi herramienta no pudo revisar, estoy ofreciendo una imagen tan incompleta como la captura que critico. Las limitaciones tienen que acompañar al resultado, aunque estropeen un buen titular.
Me siguen interesando las webs bien diseñadas. Lo que quiero entender mejor es qué merece la pena aprender de cada una y qué estoy dando por supuesto al elegirla. Esa parte del trabajo sigue siendo mía, aunque ahora pueda construir mucho más deprisa.
La próxima vez que le enseñemos una referencia a un agente, quizá merezca la pena dedicar unos minutos a una pregunta previa: ¿qué sabemos de esta web, además de que nos gusta?
