DESIGN.md: el framework de diseño con IA oculto a plena vista
Tenía un sábado reservado para rediseñar tres productos que envío bajo diferentes marcas. Sitio de marketing para uno. Pantallas de aplicaciones móviles para otro. Una presentación para el tercero. Tres estéticas diferentes. Tres públicos diferentes. Tres pilas diferentes. El año pasado, este habría sido un proyecto de cuatro semanas. El mes pasado, con Claude Code y un montón de habilidades, fueron tres días de trabajo. Esta semana lo hice antes del almuerzo.
Lo que cambió fue un solo archivo. Seiscientas doce líneas de rebajas situadas en la raíz de cada proyecto. Un nombre que había estado viendo aparecer en mi cuenta de Twitter durante semanas pero que no me había molestado en usarlo. DESIGN.md. O, según la transcripción que lea, design.mmd. Mismo archivo. Diferentes teclas en un mismo instrumento.
Me equivoqué durante casi un mes. Pensé que era otro YAML de token de diseño envuelto en un ciclo de publicidad. Pensé "genial, otra especificación que memorizar, otro estándar que abandonar cuando se envíe el próximo en seis semanas". Me senté sobre mis manos y vi subir las estrellas GitHub. El repositorio oficial de google-labs-code/design.md cruzó las 10,000 estrellas ocho días después de que Google abriera la especificación el 21 de abril de 2026. La colección VoltAgent/awesome-design-md impulsada por la comunidad superó las 68,000 en la misma ventana y ahora se encuentra en algún lugar al norte de 71k a partir de esta semana. Números como ese, en un mercado tan saturado, no ocurren con un archivo YAML.
Lo que me perdí fue que DESIGN.md no es realmente un formato de archivo. Es un protocolo. Una forma de enseñarle a un extraño su marca en aproximadamente el tiempo que lleva servir un café, donde el extraño resulta ser cada agente de codificación que utilizará. Una vez que hice clic, todo mi flujo de trabajo de diseño AI se reestructuró en torno a él. Este artículo es la versión de la explicación que desearía que alguien me hubiera dado cuatro semanas antes.
Déjame mostrarte lo que realmente sucede cuando dejas de luchar contra ello.
Por qué "simplemente indicar al modelo" dejó de ser suficiente
Este es el modo de falla que todo edificio de diseño con AI en 2026 ha experimentado al menos una vez.
Pones en marcha un nuevo proyecto. Le indica a Claude Code o Cursor o Codex algo razonable: "constrúyame una sección principal del tablero para una aplicación fintech, moderna y limpia". El modelo se pone a trabajar. Produce algo. Lo que produce está bien. En realidad, está más que bien: es técnicamente correcto, utiliza valores predeterminados sensatos, el espaciado es uniforme y la escala tipográfica tiene sentido. Y, sin embargo, echas un vistazo y ya puedes sentir la suciedad.
No puedes señalarlo ni por un segundo. Entonces puedes. La sombra está mal. No está mal en el sentido de que esté roto, está mal en el sentido de que todos los demás paneles generados por AI en Internet tienen exactamente esta sombra. El azul es el mismo azul que usa Vercel, que es el mismo azul que usó el antiguo diseño de Stripe, que es el mismo azul que usó cada sitio de marketing de la compañía YC en 2024. Estás viendo una media estadística usando un disfraz de marca.
Esto es sobre lo que nadie te advierte cuando te venden herramientas de diseño AI. La modelo no está tomando una decisión creativa. Es un promedio. Está promediando su mensaje vago con todas las demás interfaces que sus datos de entrenamiento hayan mostrado alguna vez, y el resultado llega directamente a la parte superior de la mediana. Mediana UI. Espaciado mediano. Marca mediana. La razón por la que parece genérico es porque lo es.
Los diseñadores han estado denunciando este problema exacto durante la mayor parte del año. Hay un término flotando ahora: "Claude slop", "Cursor slop", elija su modelo, y es más feo que el diseño en sí. Te dice algo cierto: el cuello de botella ya no es el modelo. El cuello de botella es si el modelo tiene alguna idea de cómo se supone que debe ser tu gusto.
Ese es el vacío que llena DESIGN.md. No por ser más inteligente que el modelo. Al ser un contrato, el modelo realmente puede seguirse.
Entraremos en el formato en sí en un momento. Pero primero necesito contarles sobre el momento en que dejé de ser escéptico.
La primera vez que lo vi funcionar realmente
Tenía un sitio de marketing para un producto secundario. Ambiente de fundador en solitario: una de esas páginas de destino minimalistas con un héroe, tres bloques de funciones, prueba social, precios y preguntas frecuentes. Tenía la marca esbozada en Figma pero aún no había implementado nada. Estaba a punto de hacer lo que siempre hago: codificar manualmente la primera pasada y luego entregársela a Claude Code para que la refine.
En lugar de eso, probé la ruta DESIGN.md. Escribí un archivo de 412 líneas que describe cada decisión de marca en un lenguaje sencillo. Fichas de colores con una oración cada una cuando correspondan. Escala de tipografía con la justificación de cada paso. Sistema de espaciado atado a una base de 4px. Voz y tono. Una sección dedicada a "Antipatrones" que enumera los ocho errores que ningún agente nunca debería cometer en este proyecto. Dejé el archivo en la raíz del proyecto. Luego abrí Claude Code y escribí exactamente esto:
Leer DESIGN.md. Luego, constrúyeme una página de destino de marketing utilizando solo los tokens, componentes y reglas definidos allí. Hero, tres bloques de funciones, tira de prueba social, precios, preguntas frecuentes.
Lo que volvió cuarenta y cinco segundos después no era un borrador. Era la página. Píxel cercano a lo que había esbozado en Figma sin siquiera abrir Figma. El héroe usó mi título serif personalizado en el tamaño correcto. La tarjeta de precios utilizó mi estilo de superficie "elevado" (el correcto, no el modal) porque había descrito en el archivo cuándo se aplicaba cada superficie. El estado de desplazamiento del botón fue el cambio de tono correcto, con el tiempo de transición correcto, porque ese tiempo existía en la sección de movimiento.
Me quedé allí sentado durante unos treinta segundos procesándolo. Luego intenté romperlo. Le pedí que agregara una sección de testimonios. Usó el estilo de tarjeta correcto. Pedí una tabla comparativa con tres competidores. Eligió la variante de densidad de mesa adecuada. Pedí un modo oscuro. Volvió a aplicar cada token correctamente sin que yo tuviera que recordarle los fondos teñidos de marca que había definido para el contenido promocionado.
Todo esto me llevó cuarenta minutos. El archivo DESIGN.md me llevó unas tres horas escribirlo correctamente. Cuarenta minutos para la página. Tres horas para el archivo que ahora genera infinitas páginas consistentes. Esa matemática es el punto.
Desde entonces, envié ese flujo de trabajo en cuatro productos separados, cada uno con su propio DESIGN.md. La composición se vuelve ridícula después del segundo proyecto. Para el proyecto tres, tenía una plantilla que copio, pego y modifico y el archivo está listo en veinte minutos.
Pero nada de esto funciona si el archivo está descuidado. Déjame mostrarte lo que realmente contiene el archivo.
¿Qué hay dentro de un archivo DESIGN.md, sección por sección?
El formato de código abierto Google tiene una estructura específica. No es un ensayo de forma libre. La especificación actual define un cuerpo de rebajas con secciones predefinidas, material frontal YAML opcional en la parte superior para tokens legibles por máquina y una regla de orden estricta: las secciones se pueden omitir, pero las presentes deben aparecer en el orden de especificación.
Aquí están las nueve secciones que exige la especificación, y cómo uso realmente cada una:
1. Versión y Nombre. Dos líneas. La etiqueta de versión es actualmente alpha y existe para que las herramientas futuras sepan a qué edición de especificaciones se dirige el archivo. El nombre es el nombre del proyecto. Pensarás que se trata de metadatos desechables. No lo es. Cuando bifurca un DESIGN.md de un proyecto hermano y se olvida de cambiarle el nombre, cada agente en su cadena de herramientas termina construyendo con confianza UI "AcmeBank" para una marca de bienestar. He visto esto suceder.
2. Descripción. Un solo párrafo que describe el posicionamiento y la personalidad del producto. Esta es la sección del "alma" de la que la comunidad fuente sigue hablando. El mío se parece más a un resumen creativo que a una especificación: tres oraciones sobre para quién es el producto, dos oraciones sobre qué sentimiento debería producir, una oración que enumera lo que no es en absoluto. El modelo utiliza esto para romper vínculos en cada decisión ambigua posterior. Si se salta esta sección, espere que sea insípido.
3. Descripción general. Un párrafo holístico sobre la apariencia. Cuando la descripción trata sobre el posicionamiento, la descripción general trata sobre el carácter visual. ¿Este producto es cálido o frío? ¿Denso o aireado? ¿Alto o sobrio? ¿Editorial o utilitario? Esta es la sección donde vive tu gusto en forma de lenguaje. Mantengo el mío específico: "Editorial silencioso. Neutrales cálidos, uso de acento restringido, espacios en blanco generosos. Los titulares hacen el trabajo pesado; el texto de apoyo retrocede. Sin degradados en el primer plano. Sin efectos de vidrio. Sin movimiento gratuito".
4. Colores. Valores hexadecimales asignados a nombres semánticos. El truco que me llevó tres proyectos aprender: no nombrar los colores según su apariencia. Nómbralos según su trabajo. surface-base no gray-50. action-primary no indigo-600. status-warning-subtle no amber-100. Cada token recibe una descripción de una oración sobre cuándo usarlo. Las descripciones son las que impiden que el modelo agarre el azul equivocado a las 2 a.m.
5. Tipografía. Familias de fuentes, escala, pesos, alturas de línea, espacio entre letras. Lo típico es de doce a quince fichas. El mío tiene trece: pantalla, encabezado-xl, encabezado-l, encabezado-m, encabezado-s, cuerpo-l, cuerpo, cuerpo-s, título, código, botón, etiqueta, ceja. Cada uno con reglas explícitas sobre dónde aparece.
6. Diseño. Cuadrículas, puntos de interrupción, escala de espaciado base. Ya sea que utilice 4px u 8px como unidad. Qué densa es tu página típica. Ya sea que sus canalones escale con un punto de interrupción o permanezcan fijos. Aquí es donde se codifica el ritmo de la marca.
7. Elevación y profundidad. Sombras, capas de índice z, las reglas de estratificación visual del sistema. Esta es la sección que la mayoría de los equipos olvidan que existe. Importa más de lo que piensas: la mitad de la pendiente que ves en AI generado por UI proviene del modelo que selecciona valores de sombra de los promedios de datos de entrenamiento. Si su archivo no especifica la elevación, el modelo adivinará y la suposición se verá como cualquier otro panel generado.
8. Componentes. Patrones para botones, tarjetas, formularios, navegación, con todas las variantes y estados. Aquí es donde el archivo se vuelve largo. Para un proyecto serio, describo aproximadamente entre quince y veinte componentes primitivos, cada uno con sus accesorios y la regla de uso para cada variante.
9. Qué hacer y qué no hacer. Reglas explícitas. "Nunca uses gris sin formato para el cuerpo del texto; usa siempre un token de contenido". "Nunca animes más de 240 ms en primer plano UI". "Evite imágenes sin bordes en el sitio de marketing; en su lugar, utilice el componente multimedia enmarcado". Esta sección es su última línea de defensa contra el promedio. El modelo las trata como restricciones estrictas. Cuanto más tengas, más sobrevive tu marca.
Esa es la estructura. La especificación completa está documentada en el repositorio google-labs-code/design.md y es fácil de leer de principio a fin en unos veinte minutos, mucho menos tiempo del que se ha dedicado a luchar contra los malos resultados.
Hay una cosa más que la especificación insinúa pero que no aborda completamente, y es donde mucha gente se queda estancada. Déjame mostrarte lo que tuve que descubrir de la manera más difícil.
La tensión entre tokens y prosa de la que nadie te advierte
Aquí está la parte de DESIGN.md que me llevó más tiempo internalizar. El formato tiene dos voces. El YAML en la parte superior es para máquinas. La siguiente prosa es para humanos y modelos de lenguaje. Necesitas ambos y necesitas que estén de acuerdo.
La mayoría de los equipos se equivocan en una de dos direcciones.
El primer modo de fracaso: demasiado YAML, poca prosa. Su archivo parece una configuración de Tailwind. Cada token tiene un nombre y un valor. No hay descripción circundante. El modelo lee el archivo, trata los tokens como datos sin procesar y termina cometiendo los mismos errores de promedio que habría cometido sin ningún archivo. Las fichas son el qué. Sin el cuándo, el modelo todavía está adivinando.
El segundo modo de fracaso: demasiada prosa, pocas fichas. Su archivo se lee como un PDF de libro de marca. Hermosas frases sobre el alma del producto. No hay valores legibles por máquina. El modelo capta la vibra, pero en realidad no puede precisar qué código hexadecimal exacto va en un botón principal. Termina con un resultado que se siente correcto y rompe todas las comprobaciones de accesibilidad.
El truco es el matrimonio. Fichas con frases. Oraciones que se resuelven en fichas. Cada valor tiene una descripción de trabajo. Cada descripción de trabajo apunta a un valor.
Yo escribo el mío en tablas. Aquí hay una parte real de mis tokens de superficie, extraídos de uno de mis proyectos en vivo con los detalles de la marca intercambiados:
| Token | Hex | Dark | When to use |
|--------------------|----------|----------|-------------------------------------------------|
| surface-base | #FAF9F6 | #0E0E10 | The page background. Nothing sits behind this. |
| surface-raised | #FFFFFF | #161618 | Cards, list rows — one layer above base. |
| surface-elevated | #FFFFFF | #1C1C20 | Modals, popovers, menus. Floating UI only. |
| surface-sunken | #F2F1ED | #08080A | Input fields, inset wells, read-only regions. |
| surface-brand | #F4EFE8 | #221C12 | Brand-tinted backgrounds for promoted content. |
Esa cuarta columna es la que hace que el archivo funcione. Un modelo que diga "usar superficie elevada solo para UI flotante" nunca puede usarlo accidentalmente como fondo de página. El token es un valor. La oración es la restricción. Juntos son una instrucción.
Este patrón se alinea con las recomendaciones del W3C Design Token Community Group a las que hace referencia la especificación Google y se asigna claramente a las herramientas existentes: exportaciones style-dictionary, el complemento de tokens de diseño de Tailwind, el formato de exportación DTCG que se encuentra en la CLI design.md. Nada de esto es nuevo. Lo nuevo es tener un único archivo canónico donde los tokens y la lógica conviven, controlados por la versión, ingeridos por cada agente de codificación que toca el proyecto.
Si ha leído mi artículo anterior sobre el flujo de trabajo del sistema de diseño AI con Claude y Figma MCP, ya ha visto el patrón de token de cuatro columnas. DESIGN.md es el formato que finalmente lo estandariza. El formato que estaba buscando es el formato que Google terminó enviando.
Hasta ahora hemos hablado del archivo. Ahora déjame hablar de la parte que convierte el archivo en un foso.
Habilidades, paquetes de remezclas y la combinación del gusto
El gran avance no fue solo DESIGN.md. El avance fue DESIGN.md más la capa que creció encima de él dentro de los cuarenta y cinco días posteriores a la caída de la especificación.
La comunidad se movió rápido. A principios de mayo de 2026, tres cosas habían entrado en producción:
La colección awesome-design-md. Un repositorio seleccionado por la comunidad en VoltAgent/awesome-design-md que envía más de cincuenta archivos DESIGN.md extraídos de marcas del mundo real: Stripe, Vercel, Notion, Supabase, Linear, NVIDIA, Apple, x.ai. La colección pasó de cero a 35.000 estrellas en diez días, luego a 68.000 a finales de abril y luego a más de 71.000. La relación de bifurcación está por encima del 12 por ciento, lo cual es una locura; para el contexto, awesome-go está en el 7,8 por ciento, awesome-python en el 9,5 por ciento. La gente no sólo marca estos archivos como favoritos. Los están involucrando en proyectos.
La integración de Claude Design. Cuando Anthropic envió Claude Design el 17 de abril de 2026, cuatro días antes de que Google abriera el formato, aterrizó con una profunda compatibilidad con DESIGN.md. Puede colocar un archivo DESIGN.md en Claude Design y obtener un andamio UI completo de una sola vez. Fichas, escala tipográfica, botones, tarjetas, navegación, kit de vista previa de trabajo. Cubrí el primer vistazo en mi revisión de diseño de Claude: la integración con DESIGN.md es la parte que mejor ha envejecido.
Remezcla basada en habilidades. Aquí es donde las cosas se ponen interesantes. La comunidad comenzó a enviar "habilidades": pequeños complementos de rebajas enfocados que se superponen a un DESIGN.md para impulsarlo en una dirección específica. Tratamientos superficiales esqueuomorfos. Efectos de acento estilo láser. Reglas de composición editorial-impresa. Patrones de interacción 3D basados en WebGL. A principios de mayo había más de sesenta habilidades públicas disponibles y el número aumenta semanalmente.
El flujo de trabajo resultante es algo a lo que todavía me estoy adaptando. Escribes tu base DESIGN.md una vez. Aplicas habilidades como superposiciones. Las habilidades no reemplazan tus tokens: los amplían, agregando capas modulares que el agente puede componer con tu base. Eliges dos familias estéticas que no deberían funcionar juntas. Dejas que el modelo los remezcle a través de la capa de habilidades. Iteras sobre el resultado.
Este es el ciclo que la comunidad fuente sigue describiendo como "iteración versus remezcla". La iteración es el refinamiento lento de una única dirección de diseño: mover un botón dos píxeles, ajustar un párrafo, ajustar un estado de desplazamiento. Remix está creando una dirección completamente nueva al combinar dos archivos DESIGN.md no relacionados o superponer una habilidad sobre una existente. Ambos importan. La iteración produce pulido. Remix produce nuevas categorías.
Aquí está lo que nadie te cuenta en el texto de marketing. Los productos maduros ejecutan miles de iteraciones. No estoy exagerando. Los equipos con los que he hablado que utilizan esta pila en serio informan de 4000 a 10 000 iteraciones impulsadas por aviso por área de superficie pulida antes de enviarse. El costo es real: en términos de fichas, de tiempo y de atención. El resultado, cuando se hace correctamente, es el tipo de calidad de diseño que antes necesitaba un estudio de seis personas para producir.
Si eso suena caro, lo es. Si suena más lento que aplicar una plantilla a un proyecto, también lo es. Lo que cambió es el techo. Con un DESIGN.md y una biblioteca de habilidades sensata, un operador en solitario ahora puede alcanzar la calidad del diseño de producción en tantos productos como su criterio pueda soportar.
Cuál es la verdadera conversación. Déjame hacerlo.
El gusto es el nuevo foso, y casi nadie lo cree todavía
Si eres diseñador y estás leyendo esto y estás nervioso por tu trabajo, quiero darte la versión del futuro en la que realmente creo.
La manipulación de píxeles ha desaparecido. El trabajo de documentación exhaustiva (cada token descrito, cada variante de componente catalogada, cada estado redactado a mano) ese trabajo es ahora un costo único pagado en un archivo de rebajas. La línea de pedido "20 horas de mantenimiento del sistema de diseño por semana" que solía estar en la hoja de ruta de cada equipo de producto está cayendo a cero. Los equipos reales informan reducciones del 60 al 80 por ciento en el mantenimiento del sistema de diseño durante el primer trimestre de adoptar DESIGN.md correctamente.
Lo que no desaparece (lo que se vuelve más valioso, no menos) es el juicio que decide qué debería estar en el expediente en primer lugar.
El DESIGN.md que escribes es la cosa. Es el foso. ¿El archivo de 412 líneas en la raíz de mi proyecto de marketing? Ese archivo es la marca del producto. Cada variación, cada página, cada correo electrónico, cada pantalla que el modelo genera se remonta a él. El archivo está aguas arriba de todo. Y el archivo es exactamente tan bueno como el gusto de quien lo escribió.
Esta es la parte que aún no ha llegado a la mayoría de la gente. Observan el diseño del AI y ven democratización: ahora cualquiera puede enviar un UI pulido. Esa parte es cierta. Pero la democratización es un nivelador en la parte inferior de la curva, no en la superior. La parte inferior de la curva mejora dramáticamente. La parte superior de la curva también mejora, es más rápida y se mantiene diferenciada, porque las personas en la parte superior son aquellas cuyo gusto está lo suficientemente informado como para escribir un DESIGN.md que produce algo que la mediana no puede.
El futuro del trabajo de diseño, tal como lo leo desde dentro del flujo de trabajo, es más o menos esto:
Más juicio por minuto. Pasarás menos tiempo empujando píxeles y más tiempo decidiendo qué debería existir. La unidad de trabajo pasa de "producir" a "decidir".
La saturación de referencias como práctica real. Necesitas un segundo cerebro para el diseño. Una biblioteca de referencias (capturas de pantalla, películas, folletos de revistas, empaques, estudios de movimiento) que usted realmente ha internalizado, no solo marcado como favorito. Los agentes harán la síntesis. Su trabajo es saber qué vale la pena sintetizar en primer lugar.
Gusto auténtico de nicho sobre dominio genérico. Un diseñador con un gusto profundo en una estética específica (Y2K, suizo, minimalismo japonés, web brutalista, Memphis, editorial) superará a un generalista usando las mismas herramientas. Los agentes se inclinan hacia el promedio. El DESIGN.md que escribes es lo que los aleja de él.
Operadores individuales que ejecutan múltiples productos. Conozco a tres personas que ahora ejecutan de cuatro a siete productos en paralelo como fundadores individuales, cada uno con su propio DESIGN.md, cada uno con su propia marca. Ninguno de ellos hacía eso hace dos años. El cuello de botella solía ser la producción. El cuello de botella es ahora la gestión de carteras.
El marketing como una extensión del criterio de diseño. Cuando el archivo genera páginas de destino, creatividades publicitarias, tarjetas sociales, presentaciones, todo desde la misma fuente de verdad, la línea entre "diseñar el producto" y "comercializar el producto" colapsa. El mismo gusto que escribió el DESIGN.md es el gusto que da forma a cada punto de contacto con el cliente.
Quiero ser honesto acerca de la parte en la que todavía estoy equivocado. Todavía no sé si las agencias se adaptarán. Todavía no sé si la educación en diseño se pondrá al día. Todavía no sé si la especificación en sí se mantendrá: la especificación de Google está en alpha, y ya hay al menos tres formatos competidores en el ecosistema (la variante de Anthropic, la versión del equipo Cursor, un par de las primeras alternativas BYOK locales). Uno de ellos probablemente se consolidará. Hoy apostaría por Google, porque el impulso del código abierto y el liderazgo en herramientas están demasiado lejos para que una bifurcación los alcance. Pero ya me he equivocado antes con este tipo de apuestas.
En lo que no me equivoco es en la dirección. Si pasas tu tiempo empujando píxeles manualmente en 2026, estás haciendo el trabajo que los archivos Markdown ahora hacen de forma gratuita.
Cómo empezar realmente, sin quemar un fin de semana
Quiero dejaros con la versión de "empezando" que ojalá alguien me hubiera pasado hace un mes. Omita los largos tutoriales de incorporación. Esto es lo que debe hacer esta semana.
Día uno, noche. Elige el proyecto en vivo más pequeño que tengas. Sitio de mercadeo. Producto secundario. Incluso una sola página de destino. Lea tres archivos DESIGN.md reales de VoltAgent/awesome-design-md: lineal, rayado y uno cuya estética realmente coincida con la suya. Léalos atentamente. El formato resultará evidente en unos veinte minutos.
Día dos. Escribe tu propio DESIGN.md desde cero, a mano, en un editor de texto sin formato. No utilice un generador. El objetivo del archivo es que te obliga a tomar decisiones explícitas a nivel de gusto. Un generador esconde esas decisiones. Apunta a entre 300 y 600 líneas. Dedique más tiempo a las secciones Descripción, Descripción general y Qué hacer y qué no hacer. Estas son las secciones que utiliza el modelo para romper empates.
Día tres. Suelta el archivo en la raíz de tu proyecto. Abra Claude Code, Cursor, Codex o cualquier agente que esté utilizando. Dígale que lea DESIGN.md y reconstruya una sola página o componente utilizando solo los tokens y las reglas definidas allí. Mira lo que regresa. Tenga en cuenta dónde se equivoca: esos errores apuntan a espacios en su archivo, no al modelo.
Día cuatro en adelante. Iterar sobre el archivo. Cada vez que el agente se equivoque en algo que usted no esperaba, pregúntele por qué. Casi siempre la respuesta es que su expediente no lo especificaba. Añade la regla. El archivo mejora con cada corrección. Al cabo de dos semanas de uso regular, se estabiliza; en ese momento, la producción del agente comienza a sentirse claramente tuya, no genérica.
Si desea una rampa de acceso más rápida, el sitio getdesign.md enumera guías de instalación para Claude Code, Cursor, Kiro, Windsurf y Stitch. La especificación oficial se encuentra en github.com/google-labs-code/design.md. La CLI para validación, diferenciación y exportación a Tailwind o DTCG se encuentra en el mismo repositorio. Nada de esto está cerrado detrás de un muro de pago. La especificación es Apache 2.0. Los archivos de la comunidad son de código abierto. La capa de habilidades es mayoritariamente gratuita.
Tengo una confesión que dejarles. El sábado que describí al principio de este artículo (los tres productos en tres horas) ya estaba trabajando desde una base de tres meses con este formato. La primera vez que intenté escribir un DESIGN.md me llevó una tarde entera y el resultado fue mediocre. El segundo tardó tres horas y se pudo utilizar. El quinto duró veinte minutos y fue excelente.
El formato es simple. El sabor necesario para llenarlo bien no lo es. Esa es la parte que no se democratiza. Esa es la parte que se vuelve más valiosa, no menos, cuanto mejores se vuelven estos agentes.
Escribe tu archivo. Tome su tiempo. La próxima década de trabajo de diseño será posterior a la rebaja que escriba esta semana.
Preguntas frecuentes
¿Cuál es la diferencia entre DESIGN.md y design.mmd?
Se refieren al mismo formato. DESIGN.md es el nombre de archivo canónico Google que se incluye en la especificación github.com/google-labs-code/design.md. La ortografía design.mmd aparece en algunos videos y artículos de la comunidad como una transcripción alternativa. El contenido del archivo es idéntico: cuerpo de rebajas con texto preliminar del token YAML opcional, secciones en orden de especificaciones. Utilice DESIGN.md para compatibilidad con las herramientas oficiales.
¿Necesito un diseñador para escribir un archivo DESIGN.md?
No, pero necesitas gusto. El archivo obliga a que cada decisión de marca se adopte en un lenguaje explícito: justificación del color, jerarquía tipográfica, lógica de espaciado, reglas de uso de componentes. Si no puede responder esas preguntas usted mismo, el archivo que escriba producirá una salida genérica independientemente del agente que lo lea. Un no diseñador con un gusto fuerte y saturación de referencias vencerá a un diseñador que copia una plantilla. Consulte la sección anterior "El gusto es el nuevo foso" para conocer el argumento completo.
¿Qué agentes AI admiten actualmente DESIGN.md?
Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, Kiro, Windsurf y Anthropic's Claude Design, todos leen DESIGN.md de forma nativa. La mayoría lee el archivo como una simple rebaja, no se requiere ningún complemento. La herramienta Stitch Google era la propietaria del formato original y todavía tiene la integración más profunda. Algunos agentes también admiten la exportación de token YAML opcional que genera la CLI design.md.
¿Cuánto tiempo lleva escribir un DESIGN.md utilizable?
De tres a seis horas para una primera versión seria de un proyecto real. De veinte a cuarenta minutos para proyectos posteriores una vez que tengas tu propia plantilla. Las secciones Descripción, Descripción general y Qué hacer y qué no hacer toman la mayor parte del tiempo y son las partes de mayor apalancamiento del archivo: invierta allí antes de obsesionarse con el recuento de tokens.
¿DESIGN.md reemplazará a Figma?
No. DESIGN.md reemplaza el documento de transferencia entre el diseño y el código, y la capa de datos de capacitación entre su marca y un agente. Figma sigue siendo el lugar para la exploración visual, la creación de prototipos de movimiento y la revisión de diseños. El patrón en el que convergen la mayoría de los equipos a partir de mayo de 2026: explorar en Figma, codificar en DESIGN.md, realizar andamiaje con un agente, perfeccionar el código. El archivo es la fuente de verdad que viaja entre cada herramienta.
Trabajemos juntos
¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Cartera: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y marca): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
