[🤖] El diseño del resultado cambiaba constantemente: por qué necesitaba DESIGN.md

✨ Resumen de GPT-5.6 Sol

El folleto salía distinto cada vez y por eso busqué DESIGN.md, pero ya llevaba tiempo sintiendo la necesidad de mantener una identidad visual coherente y aplicándola a mi manera en otros proyectos personales. Este es el registro de cómo conecté aquellos criterios dispersos en un formato que la IA puede consultar continuamente.

El diseño cambiaba cada vez que hacía un folleto

Después de volver de unas vacaciones largas, seguí trabajando en la producción de un folleto en mi empresa actual. Tras dedicarme a gestionar coordinadores y workers hasta no poder terminar el folleto a tiempo, reduje la forma de trabajar, pero el diseño todavía me preocupaba. Incluso dentro del mismo PPT, el ambiente cambiaba de una página a otra, y cada nueva versión parecía generar un diseño diferente.

En los demás proyectos pasaba algo parecido. Intenté crear coherencia haciendo que la IA buscara referencias y buenos ejemplos de diseño, o compartiéndolos yo mismo. A veces simplemente esperaba que la tirada aleatoria de la gacha saliera bien. Lo único que recibí fueron resultados de categoría D, sin coherencia y con un olor a IA tremendo.

Yo no quería generar una pantalla más o menos atractiva cada vez. Quería que los mismos colores, la misma jerarquía tipográfica, los mismos espacios y la misma sensibilidad de componentes continuaran en la página y la versión siguientes. Pero el folleto no tenía esos criterios. Cada vez que la IA recibía una referencia, volvía a adivinar el ambiente desde cero.

No era la primera vez que detectaba este problema

Mirándolo atrás, esta no era la primera vez que sentía la necesidad de mantener la coherencia del diseño. En julio de 2025 ya había dejado un registro sobre cómo crear un sistema de diseño para el vibe coding. Entonces ya pensaba en un flujo que consistía en diseñar con Figma AI, guardar pantallas y código como referencias, organizar la tipografía y la paleta de colores, y comparar todo con el resultado real.

En Tadak Bible no me quedé solo en la idea. Desde enero de 2026 empecé a reunir colores, tipografía y temas en un solo lugar. Documenté direcciones como el azul pastel y el lavanda, una atmósfera tranquila y cálida, y la legibilidad de la pantalla de escritura bíblica. Después creé BibleColors, BibleTypography y tokens de espaciado, esquinas, iconos y movimiento, y los apliqué en varias pantallas. También añadí comprobaciones para impedir que una pantalla nueva volviera a inventar colores y tamaños de letra arbitrarios.

Es decir, ya sabía por qué era necesario un sistema de diseño. Dentro de Tadak Bible había avanzado bastante en la tarea de unir los colores, las tipografías y los componentes comunes del producto mediante código y documentación.

El problema era que esa experiencia no llegaba a otros proyectos ni a otros resultados. Los criterios de Tadak Bible estaban repartidos entre sus documentos, el código Flutter y las comprobaciones. No existía un formato común que una IA pudiera leer al empezar un nuevo proyecto web o PPT para continuar con la misma sensibilidad. En cada proyecto volvía a buscar referencias, volvía a lanzar ejemplos y volvía a esperar un buen resultado.

Intenté conectar los criterios dispersos con DESIGN.md

Entonces encontré el catálogo ko/design.md, que organiza los sistemas de diseño de servicios coreanos como contexto para LLM,¹ y el repositorio DESIGN.md de Google Labs Code.²

Por el nombre y los ejemplos entendí más o menos qué clase de archivo era. Parecía un lugar donde anotar colores, tipografías, espacios, componentes y la atmósfera general para que la IA pudiera consultarlos cada vez que diseñara. Pensé que podía trasladar los criterios que ya había creado para Tadak Bible a una forma que un Agent pudiera leer continuamente y administrar otros proyectos del mismo modo.

El problema fue que aquí también me conformé con una idea aproximada. Le pedí a la IA que averiguara qué era DESIGN.md, revisara los ejemplos y creara algo parecido. Después lo di por hecho: seguro que lo había investigado lo suficiente y seguro que lo había aplicado bien. No comprobé personalmente el alcance descrito por la documentación oficial, si el archivo generado respetaba ese alcance ni si el resultado real había adquirido coherencia visual.

Que la IA leyera un enlace y produjera un archivo convincente no significaba que yo ya tuviera los criterios de diseño que quería. No comprobar esa diferencia fue culpa mía.

Estuve a punto de meter toda la planificación del producto en DESIGN.md

Sin haber comprobado bien el alcance de DESIGN.md, intenté organizar en ese archivo todas las pantallas y flujos por usuario, los estados, los permisos y la recuperación del siguiente producto. Codex amplió mis palabras tal como estaban y empezó a crear DESIGN.md por rol y reglas separadas.

Algo no encajaba. Parecía que no estaba tratando bien la UI, así que volví a decirle que empezara por revisar el ejemplo de Google Labs Code que yo había señalado como el más importante.

Después de leer el material original, el límite quedó mucho más claro. DESIGN.md de Google Labs Code es un formato que comunica de forma continua la identidad visual de un producto a un Agent de programación. El YAML puede contener tokens de diseño precisos, mientras que el cuerpo en Markdown explica por qué se usan esos colores, tipografías y formas, y cómo debe verse, sentirse y comportarse el diseño completo.³

La palabra comportarse no significaba absorber toda la planificación del producto. Los roles, recorridos, permisos, excepciones, recuperación, estructura de pantallas y verificación debían seguir tratándose en la documentación habitual del producto. Los detalles por rol que intenté crear al principio no eran contenido desechable; simplemente pertenecían a docs/, no a algo llamado DESIGN.md.

Seguir el formato no es copiar el diseño

Una vez corregido el límite, quedaba otra cosa por comprobar. Tomar Google Labs Code como referencia no significaba copiar el diseño de ejemplo de su repositorio y aplicarlo a todos los proyectos.

Google proporcionó el formato DESIGN.md y una forma de interpretarlo, no el contenido del diseño. Los colores, tipografías y ambientes de los ejemplos solo representan la identidad visual de esos ejemplos. El DESIGN.md de un proyecto real debe incluir criterios visuales derivados de sus usuarios, su entorno, su marca y las referencias que yo elija. El catálogo ko/design.md también sirve para consultar y comparar; copiar cualquier diseño no lo convierte automáticamente en la identidad de nuestro producto.

Por eso corregí las reglas comunes y el Skill de planificación de productos. DESIGN.md se crearía solo cuando la identidad visual formara parte real del alcance, mientras que los roles, recorridos, permisos, recuperación y diseño detallado de pantallas permanecerían en la documentación normal del producto. Eliminé la dirección de DESIGN.md por rol que había inventado al principio, y la plantilla final superó la validación oficial de Google.

Esta vez encontré DESIGN.md para reducir la gacha del diseño, pero también dejé el significado de DESIGN.md en manos de la gacha de la IA. Si entrego un enlace, digo “investiga y aplícalo” y confío solo porque apareció un archivo, la IA rellena a su manera todos los huecos que yo no comprobé.

Un archivo DESIGN.md no genera automáticamente un buen diseño. En un PPT, sobre todo, todavía hay que crear patrones de diapositivas y muestras de diseño reales, y revisar el resultado renderizado para comprobar si respeta los criterios. Pero si dejo como fuente canónica en DESIGN.md los criterios visuales que he aceptado para cada producto, al menos disminuirán las ocasiones en que la IA vuelve a sacar una atmósfera desde una pantalla en blanco.

Llevaba mucho tiempo entendiendo la necesidad de mantener la coherencia visual. Ya estaba construyendo un sistema de diseño en Tadak Bible. Solo ahora encontré un formato legible por un Agent que podía llevar esa experiencia a otros proyectos y resultados, y por fin lo conecté con el nombre DESIGN.md.

Referencias

1. ko/design.md, catálogo de sistemas de diseño de servicios coreanos. Ofrece los diseños característicos de servicios coreanos como contexto para LLM. ↩

2. Google Labs Code, DESIGN.md. Presenta un formato de identidad visual que los Agents de programación pueden consultar continuamente. ↩

3. Google Labs Code, especificación de DESIGN.md. Define la estructura, las secciones estándar y las reglas de validación de los tokens de diseño en YAML y sus fundamentos en Markdown. ↩