Zombie UI: Cómo evitar que la IA construya la interfaz que todos los demás lanzan

Etiquetas: diseño con IA, sistemas de diseño, Zombie UI, diseño de producto, oficio del diseño

Ahora, equipos de tres personas pueden hacer lo que antes requería equipos de treinta. Este artículo enseña las cuatro jugadas para contraatacar: tener un punto de vista, estándares codificados en la máquina, un editor que se niega a confundir lo terminado con lo bueno, y un presupuesto para lo inusual.

El segundo boom de la construcción y cómo un estilo se convierte en zombis

Justo después de la Segunda Guerra Mundial se produjo un boom de la construcción, el mayor de la historia según la charla. Sus constructores recurrieron al modernismo de los años 20: geometrías simples, superficies limpias y desnudas, paletas monocromáticas, sin adornos. Ante la urgencia de construir y con los nuevos métodos de construcción, ese estilo se copió una y otra vez sin intencionalidad. El nombre que la charla da al resultado es edificios zombis, estructuras que se mantienen en pie y funcionan, pero en las que nada las diferencia entre sí.

Un estilo es un conjunto de respuestas a problemas específicos, y copiarlo sin tener en cuenta esos problemas hace que solo se conserve la superficie. Al copiarse de esta manera, los patrones dejaron de encajar con los lugares y las personas para las que fueron construidos.

La víctima más famosa de aquella época demuestra por qué hay que tomarse esta lección con cuidado. El complejo Pruitt-Igoe en San Luis fue proclamado por el Architectural Forum como el mejor gran bloque de apartamentos de 1951; su demolición comenzó en 1972, y sigue citándose habitualmente como el ejemplo de los fracasos del diseño modernista. Charles Jencks fue más allá y fechó la muerte de la arquitectura moderna el 15 de julio de 1972, con la demolición con dinamita de sus bloques de losas. Desde entonces, los historiadores han argumentado que su construcción y gestión estuvieron moldeadas por condiciones económicas y políticas profundamente arraigadas, y que culpar a los diseñadores desvía la atención de esas causas institucionales.

La afirmación central de la charla es que ahora nos encontramos en otro boom de la construcción, el boom de la IA. Hoy en día, una empresa puede desarrollar 20 ideas en una semana. La Zombie UI es el gemelo digital del edificio zombi: una interfaz ensamblada a partir de los patrones más probables, competente en la superficie e intercambiable con cualquier otro producto construido de la misma manera. La investigación sobre las interfaces generadas por IA ya muestra su perfil: herramientas que alcanzan el cumplimiento básico de accesibilidad mientras se basan en patrones de diseño homogeneizados.

La tendencia a la media (drift to the mean): los grandes modelos de lenguaje (LLMs) son muy buenos diciéndote la respuesta más probable, y la interfaz más probable es la promedio. La tendencia a darlo por terminado (drift to done): la IA hace que las cosas parezcan terminadas muy rápido, y con demasiada frecuencia de forma prematura. La tendencia a lo desechable (drift to disposable): el trabajo es tan rápido que parece desechable y, lo que es peor, se trata como tal.

Cada una de estas tendencias necesita su propio contrapeso, y la charla plantea el resultado como una elección: este boom puede saltarse a los zombis digitales y convertirse en un Renacimiento creativo.

Por qué los resultados de la IA tienden al promedio y por qué unos mejores prompts no lo solucionarán

Figura 1. Las tres tendencias estructurales que empujan los resultados de la IA hacia una Zombie UI, cada una requiriendo su propio contrapeso.

Un modelo de lenguaje grande, o LLM, está entrenado para predecir lo que viene a continuación, por lo que aprende a asignar una alta probabilidad a las continuaciones que ha visto con mayor frecuencia. Este es exactamente el sentido en el que los modelos son realmente buenos diciéndote la respuesta más probable.

Los investigadores denominan a esta reducción monocultivo generativo: una caída significativa en la diversidad de los resultados en relación con los datos de entrenamiento, como producir solo reseñas positivas para libros que tuvieron una recepción mixta. Otra línea de investigación atribuye parte de esta causa al sesgo de tipicidad: las personas que evalúan los resultados del modelo favorecen sistemáticamente el texto familiar. Las plantillas de formato añaden su propia presión, y un estudio descubrió que el colapso de diversidad resultante persiste incluso bajo un muestreo de alta temperatura. A lo largo de 14 modelos de lenguaje, otro equipo descubrió que la masa de probabilidad se concentra excesivamente en unas pocas continuaciones válidas.

Una revisión sistemática de los LLMs en el diseño UI y UX señala la dependencia de patrones genéricos o conservadores y advierte que los diseñadores pueden anclarse en las sugerencias de la IA demasiado pronto, limitando su ideación. Una evaluación de pantallas creadas con IA encontró un atractivo acabado visual junto a palabras incorrectas, etiquetas ilegibles y falta de feedback interactivo. Los profesionales que probaron una herramienta generativa de UI informaron de que tenía dificultades para mantener el tejido conectivo entre pantallas: estilos coherentes, un layout compartido y un flujo coherente.

El segundo mecanismo es la brecha entre lo que quieres decir y lo que escribes. El equipo de diseño de Stripe lo vio de primera mano: tres personas diferentes podían introducir el mismo prompt y obtener tres resultados distintos.

El tercer mecanismo recae en el revisor, no en el modelo. La imagen que usa la charla es la de un burrito de microondas: 90 segundos desde que tienes hambre hasta que comes, y la velocidad hace que estés dispuesto a pasar por alto que apenas es comestible. Eso es la tendencia a darlo por terminado en miniatura.

Lo que funciona es estructurar en tres puntos: un punto de vista en el origen (upstream), estándares codificados en las herramientas por las que debe pasar el modelo, y un editor responsable al final (downstream). El flujo a continuación traza el método que enseña el resto de este artículo.

Paso uno: construir un punto de vista a través de la observación

El primer paso ocurre antes de abrir cualquier modelo: define tu marca, lo que es para ti y lo que es para tus usuarios.

El punto de vista de Stripe es el optimismo, y el equipo lo plasma en todos los detalles, grandes y pequeños. En la charla, ese valor se refleja en los colores, la redacción, la temática y los productos lanzados para apoyar a los emprendedores.

Un punto de vista no se inventa en un taller; se construye prestando atención. Fíjate en lo que tus usuarios necesitan y lo que quieren, no solo en lo que dicen. Observa también el mundo en general, ya que los productos, el arte y la ciencia emiten señales de lo que se percibe como bueno, excepcional o mediocre.

Figura 2. La arquitectura de tokens de tres capas que hace que los agentes de IA obedezcan estándares basados en la intención en lugar de adivinar a partir de nombres basados en la apariencia.

Plantilla para adaptar: Somos [lo que eres] para [quién]. Creemos en [la creencia]. Por lo tanto, siempre [comportamiento visible] y nunca [el comportamiento probable por defecto que rechazamos].

Paso dos: codificar tus estándares en la máquina

La tesis de mayor impacto de la charla es que el objeto del diseño ya no es la pantalla; es el sistema en sí. De ahí el segundo paso: codifica tus estándares en la máquina.

El suyo leía la documentación de diseño, y no era lo suficientemente específico: tres personas con el mismo prompt seguían obteniendo tres resultados diferentes. Así que el equipo construyó una CLI (interfaz de línea de comandos) sobre su sistema de diseño, y esta funciona como un arnés que hace que la IA sea mucho más obediente.

Una guía de gobernanza de sistemas de diseño expone el principio sin rodeos: un agent no puede leer una página de la wiki y decidir seguir la convención de nomenclatura; necesita reglas expresadas como datos estructurados con condiciones, restricciones y consecuencias explícitas.

La composición es exactamente el punto más débil de las herramientas generativas, tal y como descubrieron los profesionales cuando una herramienta tuvo dificultades para mantener la coherencia de estilos y flujos entre pantallas.

Las directrices actuales los dividen en capas: las primitivas contienen valores brutos, la semántica contiene el significado y los componentes consumen la capa semántica. Nombra por intención, no por apariencia: color.blue.500 obliga a adivinar entre distintos tonos de azul, mientras que color.action.primary declara la intención de forma directa. En el formato de Design Tokens del W3C, el campo $description es lo que indica a un agent cuándo usar un token en lugar de otro de aspecto similar. Un sistema de diseño agéntico de código abierto redacta su regla absoluta de esta manera: las primitivas nunca se utilizan directamente en los componentes.

Si tu fuente de diseño es Figma, sus propias directrices dicen que conectar los componentes al código con Code Connect es la forma más eficaz de conseguir que un agent reutilice tus componentes reales; sin él, el agent tiene que adivinar. La misma guía pide variables para el espaciado, el color, el radio de las esquinas y la tipografía, nombres de capas que describan el propósito y auto layout en lugar de posicionamiento absoluto.

Uno expone un chequeo de cumplimiento que valida un fragmento de código frente a las reglas de diseño y devuelve las infracciones. Otro mantiene un archivo de contrato junto a cada componente y bloquea la desviación del sistema de diseño (drift) en la integración continua. El relato de un creador sobre un agent de sistema de diseño convirtió la CLI en el único punto de entrada e integró barreras de seguridad estrictas: una allowlist de escritura, nada de comandos de shell, y ninguna dependencia nueva.

La codificación tiene un límite, y la charla lo nombra con una frase de Christopher Alexander: un sistema puede cumplir todas las reglas y aun así estar muerto. Las investigaciones sobre las organizaciones de diseño comparten esta preocupación: a los líderes temen que los sistemas que estructuran el diseño como un ensamblaje de componentes predefinidos puedan estar reduciendo la variedad de habilidades que ven a la hora de contratar. En otro estudio, los profesionales consideraron que tales críticas a menudo carecían de contexto, reafirmaron el valor de los sistemas de diseño y pidieron una mejor colaboración en torno a ellos.

Paso tres: editar con rigor y negarse a confundir lo terminado con lo bueno

El tercer paso tiene un lema digno de colgarse en la pared: negarse a confundir lo terminado con lo bueno. Detrás de él se esconden dos hábitos que todo equipo debe desaprender: que construido significa terminado, y que terminado significa bueno.

El rol que reemplaza al antiguo filtro es el editor. Un editor asume la responsabilidad de cada decisión, lo que en muchos sentidos significa cada píxel. El editor juzga el resultado de principio a fin de la forma en que lo percibe un usuario, no pantalla por pantalla tal y como se ha generado.

En Stripe, una sesión de crítica (crit) sobre un anuncio creado con la ayuda de IA terminó con 17 puntos de mejora.

Recorre el flujo como un usuario, desde el primer punto de entrada hasta la última confirmación, y anota dónde se rompe el recorrido en lugar de fijarte simplemente en qué pantalla se ve mal. Abre cada estado que los modelos rara vez dibujan bien: vacío, de carga, de error, datos parciales, el nombre más largo, la pantalla más pequeña. Lee cada palabra, ya que las evaluaciones de pantallas hechas por IA no dejan de encontrar palabras incorrectas y etiquetas ilegibles tras layouts atractivos. Después, compara el resultado con tu punto de vista: si se quitara el logo, ¿alguien que conozca la marca lo reconocería como tuyo?

Plantilla para adaptar: En [ubicación], veo [observación], lo cual rompe el [principio], así que cámbialo por [instrucción específica].

La edición solo funciona si el editor puede detener el trabajo que ya está construido. Nombra a un editor por superficie, dale a esa persona el derecho explícito a bloquear un lanzamiento, y haz que bloquear sea algo rutinario para que se entienda como una práctica en lugar de un veto personal.

El paso que la mayoría de los equipos se saltan es cerrar el ciclo entre la edición y la codificación. Cada nota que aparece en dos sesiones de crítica es una regla que espera ser escrita en el sistema, de modo que el juicio del editor se acumula en lugar de gastarse repetidamente en cada pantalla. Las directrices de gobernanza hacen el mismo movimiento desde el otro lado: haz un inventario de las reglas que ya existen en las guías de contribución, en las configuraciones del linter, en las checklists de revisión y en los registros de decisiones; luego, expresa cada una de ellas como una restricción verificable por la máquina. Con el tiempo, el arnés absorbe los juicios rutinarios y libera al editor para aquellas decisiones que solo el buen gusto puede tomar.

🛠 Cómo hacerlo — Construir un estándar de diseño que un agent de IA obedezca, y un filtro de edición que bloquee lo terminado-pero-no-bueno

1. Haz un inventario de las reglas que ya existen y dónde residen: guías de contribución, configuraciones del linter, convenciones de nomenclatura de Figma, notas de uso de tokens, checklists de pull requests y registros de decisiones.
2. Reestructura los tokens en una capa primitiva de valores brutos y una capa semántica nombrada por intención, apunta cada componente a la capa semántica y dale a cada token semántico una descripción de una frase sobre cuándo usarlo.
3. Conecta tus componentes de Figma al código con Code Connect para que el agent reutilice componentes reales en lugar de adivinar.
4. Si adoptas una capa de contrato prediseñada, inicialízala en tu repositorio; Fragments, por ejemplo, detecta tu framework y escribe el contrato en un solo comando. npx @usefragments/cli init
5. Controla la desviación del sistema de diseño en la integración continua para que el output que se salga del sistema falle antes de llegar a revisión. fragments check --changed --ci

Paso cuatro: gastar los ahorros en lo inusual

Como dice la charla, la IA puede ayudarnos a fabricar monotonía, pero también es el mayor catalizador creativo que hayamos tenido jamás. Su lema es proteger lo extraño: la IA reduce el coste de crear, por lo que parte de lo que ahorra debería destinarse a trabajos inusuales.

Cuando cada intento es caro, los equipos recortan racionalmente la idea más rara primero, porque su beneficio es incierto y su coste es seguro. Cuando los intentos se vuelven baratos, la misma lógica se invierte: la varianza es asequible, y la opción inusual se gana un lugar en cada ronda.

El propio ejemplo de la charla es la animación de apertura de un evento.

El obstáculo para lograr esa extrañeza no es solo el modelo, sino la fijación de las personas que lo usan, un fenómeno que los investigadores describen como aún poco explorado en la IA generativa.

Así que pídele al modelo un abanico de opciones (spread), no solo una respuesta. El muestreo verbalizado (verbalized sampling), una estrategia de prompt que no requiere entrenamiento, pide al modelo varias respuestas con sus respectivas probabilidades, lo que alivia la presión de producir una única respuesta típica. En la escritura creativa, esto aumentó la diversidad entre 1,6 y 2,1 veces en comparación con el prompt directo.

Plantilla para adaptar: Dame cinco direcciones para esta pantalla de onboarding, cada una con la probabilidad de que un equipo de producto típico la lanzara, y haz que al menos dos de ellas sean enfoques que un equipo típico nunca elegiría.

Figura 3. Las 290 variantes de tipos de Gutenberg y las columnas sin repetición de Ruskin comparten el mismo principio: la variación significativa está integrada en el sistema, no se deja al azar.

La tensión con el paso dos es real: un arnés construido para que la IA sea obediente tira en la dirección opuesta a una vía construida para hacerla extraña. Llamemos a esta resolución "dos vías": una vía del sistema donde el arnés gobierna la navegación, los formularios, la configuración y todos los flujos que los usuarios necesitan que sean predecibles, y una vía de expresión donde la marca habla, sujeta al punto de vista y al criterio del editor en lugar de a las plantillas. Un estudio sobre sistemas de diseño señala que sus límites a la creatividad también pueden ser una ventaja, permitiendo a los diseñadores ser más creativos con los problemas que el sistema no resuelve.

Lecciones de oficio de Gutenberg y Ruskin: dónde reside la variación

La invención de la imprenta suele contarse como una historia de velocidad, pero la parte más útil para cualquiera que construya con IA es el sistema que Gutenberg construyó alrededor de su máquina. Su motor de escalado era un molde de mano que permitía fundir cientos o miles de piezas de tipos a partir de una única matriz.

Para su Biblia, Gutenberg creó 290 caracteres únicos, incluyendo diferentes anchuras, abreviaturas y ligaduras. Aproximadamente 60 tipos habrían sido suficientes para componer el texto si evitar los espacios anchos entre palabras no hubiera sido el objetivo. El diseñador tipográfico Hermann Zapf identificó más tarde el secreto como columnas grises uniformes, sin huecos perturbadoramente anchos entre las palabras.

El detalle importa: la mayoría de esos tipos adicionales eran ligaduras y abreviaturas, mientras que el número de caracteres individuales con anchuras variables era pequeño. Incluso para una misma letra, fundió varias piezas, cada una con un diseño ligeramente diferente.

John Ruskin abordó el mismo problema desde el lado opuesto, escribiendo en 1850 sobre la calidad y la artesanía y erigiendo la arquitectura gótica como el paradigma de la grandeza. Se dio cuenta de que ningún edificio gótico era igual a otro, y de que ni siquiera una columna coincidía con otra. A la pregunta de si se podía construir en estilo gótico cubriendo los edificios con tréboles, respondió que no, de la misma manera que un niño no puede escribir en latín copiando palabras al azar de Cicerón.

En The Nature of Gothic, Ruskin clasificó los elementos morales del estilo como Salvajismo, Mutabilidad, Naturalismo, Grotesco, Rigidez y Redundancia. Vistos desde el lado del constructor, los reformuló como Rudeza, Amor por el Cambio, Amor por la Naturaleza, Imaginación Perturbada, Obstinación y Generosidad.

Errores que convierten a un buen sistema en una fábrica de zombis

El primer error es tener un estándar separado y más bajo para el trabajo de la IA. La pregunta que un colaborador interfuncional, ansioso por lanzar rápido, planteó una vez fue: ¿cuál es el estándar de calidad para algo hecho con IA? La respuesta que prevalece es que lo que importa al final del día es el output: a los usuarios les importa si es bueno, y a los creadores también debería importarles.

El segundo error es tratar el cumplimiento de las reglas como si fuera calidad, algo contra lo que advirtió Christopher Alexander cuando dijo que un sistema puede cumplir todas las reglas y aun así estar muerto. Un estudio de noventa interfaces generadas por dos herramientas de IA en tres dominios de aplicación muestra la trampa en la práctica. Las herramientas lograron constantemente el cumplimiento básico de accesibilidad, sin embargo, se basaron en patrones de diseño homogeneizados que limitaron lo bien que satisfacían las necesidades especializadas de los usuarios.

Los investigadores contaron 178 casos de participantes que aceptaron los requisitos sin cuestionarlos y 41 casos de parejas que rechazaron nuevas ideas porque divergían de las iniciales.

Los profesionales entrevistados sobre esa crítica la consideraron a menudo equivocada o carente de contexto, y reafirmaron el valor de los sistemas de diseño. Otro estudio señala que esta limitación puede ser una ventaja, ya que libera a los diseñadores para que sean más creativos con los problemas que el sistema no resuelve. Los líderes de diseño siguen describiendo una tensión real: dependen de personas que trabajan dentro de las restricciones del sistema, pero al contratar valoran a aquellos que desafían las suposiciones y proponen soluciones inesperadas.

Figura 4. Los dos finales posibles para el boom de la construcción con IA, y los cuatro hábitos visibles que distinguen a un equipo renacentista de una fábrica de zombis.

Pruitt-Igoe, el proyecto de viviendas de San Luis a menudo citado como el fracaso del diseño modernista, fue aclamado por Architectural Forum como el mejor gran bloque de apartamentos de 1951, y su demolición comenzó en 1972. Los historiadores sostienen que no fue principalmente un fracaso de diseño: las condiciones económicas y políticas, las políticas públicas y el declive de la ciudad marcaron su destino.

Plantilla para adaptar: antes de lanzar nada, el editor responde por escrito a tres preguntas: ¿preferiría un usuario esto a la mejor alternativa elaborada a mano?, ¿qué hay aquí que solo podría venir de nosotros?, y ¿quién será el responsable dentro de seis meses? Si alguna respuesta queda en blanco, el trabajo está construido, pero no terminado.

Elegir un Renacimiento creativo en lugar de la Zombie UI

Estamos en otro boom de la construcción, el boom de la construcción con IA, y la elección en este caso es si crear el equivalente digital a los edificios zombis o un Renacimiento creativo. La historia ofrece ambos desenlaces, lo que hace que la elección sea real y no retórica.

El objeto del diseño ya no es la pantalla, sino el sistema en sí. Por eso la elección se hace en el origen (upstream), en el punto de vista y en los estándares codificados, mucho antes de que nadie revise una sola pantalla.

La protección en el otro extremo es una frase: negarse a confundir lo terminado con lo bueno. Funciona porque le da al editor permiso para detener el trabajo que ya parece terminado, que es exactamente el momento que la IA hace más tentador saltarse.

Un equipo que elige el Renacimiento tiene cuatro hábitos visibles: un punto de vista escrito, un sistema que lanza plantillas y flujos en lugar de piezas individuales, un editor con la autoridad para decir "todavía no", y un presupuesto protegido para el trabajo inusual. Gutenberg gastó sus ahorros en los tipos que hicieron que las páginas a máquina fueran dignas de las hechas a mano, y Ruskin elogió a los constructores cuyas columnas se negaban a repetirse.

Puntos clave

• El boom de la construcción con IA repite el patrón de posguerra: las formas copiadas sin intención producen la Zombie UI.
• Define un punto de vista, construido mediante la observación del comportamiento, antes de que cualquier modelo toque el trabajo.
• Diseña el sistema, no la pantalla: codifica tokens, plantillas y flujos en un arnés por el que la IA debe pasar obligatoriamente.
• Construido no es terminado y terminado no es bueno: un solo editor asume la responsabilidad de cada decisión, hasta el último píxel.
• Invierte parte de lo que la IA te ahorra en trabajo inusual, en su propio carril, sujeto al mismo nivel de exigencia editorial.

Plan de acción

1. Ejecuta la prueba de coherencia: tres personas, un prompt, tu configuración actual de IA, y luego compara los resultados (outputs) lado a lado.
2. Elige una regla escrita de tus directrices y codifícala como una restricción verificable por máquina que ejecute tu CI o tu agent.
3. Renombra tus tokens semánticos por su intención y dale a cada uno una descripción de una frase sobre cuándo utilizarlo.
4. Nombra a un editor para tu próximo lanzamiento construido por IA, otórgale el derecho de bloquearlo y realiza una sesión de crítica que termine con instrucciones por escrito.

Ponte a prueba

P. ¿Por qué no se puede arreglar un resultado genérico de la IA simplemente subiendo la temperatura o reformulando el prompt?
R. La investigación descubre que el colapso de diversidad persiste incluso bajo muestreo de alta temperatura y que los simples cambios de muestreo o prompt son insuficientes, porque el estrechamiento probablemente tiene sus raíces en el alignment del modelo.

P. ¿Cuál es la diferencia entre documentar una regla de diseño y codificarla?
R. La documentación explica la intención en palabras que un agent podría no seguir; la codificación expresa la regla como datos estructurados con condiciones, restricciones y consecuencias que los agents, linters y la CI pueden comprobar.

P. ¿Por qué nombrar a un token color.action.primary en lugar de color.blue.500?
R. Un agent lee el nombre antes de elegir un token: un nombre basado en la intención indica para qué sirve el token, mientras que un nombre de apariencia obliga a adivinar entre opciones parecidas.

P. ¿De qué advierte a los equipos de producto la historia del complejo Pruitt-Igoe?
R. De culpar únicamente a la forma: los historiadores sostienen que su fracaso estuvo determinado por condiciones económicas, políticas e institucionales, siendo el diseño modernista solo un factor más entre varios.

Preguntas abiertas

• ¿Quién debería ocupar el rol de editor en una organización, y con qué autoridad para detener el trabajo que ya está construido?
• ¿Cómo pueden equipos de tres personas encontrar tiempo para la artesanía meticulosa cuando la velocidad es la razón por la que pueden competir?
• ¿Quién mantiene el gran volumen de productos creados rápidamente y generados por IA a largo plazo?
• ¿Cómo se puede conciliar la protección de lo inusual con la coherencia de marca que impone un arnés de sistema de diseño?
• Si el estrechamiento de los outputs del modelo tiene su raíz en el alignment, ¿llegarán métodos de fine-tuning que preserven la diversidad, y qué cambiarán para el trabajo de diseño?
• ¿Están los sistemas de diseño reduciendo las habilidades creativas que desarrolla la profesión del diseño, tal como temen algunos líderes del sector?

Para profundizar

1. Good Accessibility, Handcuffed Creativity: AI-Generated UIs Between Accessibility Guidelines and Practitioners’ Expectations | Proceedings of the 2025 ACM Designing Interactive Systems Conference — Un estudio de noventa interfaces generadas por IA que muestra el cumplimiento de la accesibilidad junto a patrones de diseño homogeneizados.
2. Verbalized Sampling: How to Mitigate Mode Collapse and Unlock LLM Diversity — El documento sobre el muestreo verbalizado: por qué los modelos alineados colapsan en respuestas típicas y un prompt sin entrenamiento que restaura la diversidad.
3. skills/governance-encoder/SKILL.md — Una skill paso a paso para convertir las reglas de gobernanza del sistema de diseño en restricciones verificables por la máquina para agents de IA.
4. How to structure your design system for AI: tokens, naming, LLM-readable docs | DesignSystems.one — Directrices concretas sobre cómo estructurar los tokens en capas, nombrarlos por su intención y redactar descripciones sobre las que un agent pueda actuar.
5. MCP server best practices – Figma Learn - Help Center — Las mejores prácticas de Figma para estructurar archivos de manera que un agent reutilice tus componentes y variables reales.
6. InDesign, the hz-program and Gutenberg's secret — Cómo Gutenberg utilizó 290 tipos, en su mayoría ligaduras y abreviaturas, para lograr su justificación uniforme.
7. The Nature of Gothic and Modern Oblivion | Church Life Journal | University of Notre Dame — La propia lista de Ruskin de los elementos característicos del gótico, desde el salvajismo hasta la redundancia.
8. Why Did Pruitt-Igoe Fail? — Un breve relato de por qué fracasó Pruitt-Igoe, más allá de la historia popular que culpa a su arquitectura modernista.