DESIGN.md y Open Design: un flujo abierto para sistemas de diseño asistidos por agentes
Qué define la especificación DESIGN.md, cómo la utiliza Open Design y qué debe validar un equipo antes de llevar este flujo a producción.
DESIGN.md no es una herramienta de diseño ni un modelo. Es una especificación para describir una identidad visual de forma que una persona y un agente de programación puedan leerla. El repositorio oficial combina tokens en YAML con explicaciones en Markdown. Los tokens fijan valores; el texto explica por qué existen y cómo usarlos.
Open Design es un proyecto distinto que consume ese tipo de archivos dentro de un entorno local. Su repositorio documenta una aplicación, una CLI, vistas previas aisladas, sistemas de diseño y complementos portátiles. Conviene mantener esa separación: una especificación describe el contrato visual; la aplicación ejecuta un flujo de producción alrededor de ese contrato.
Qué debe contener el contrato visual
Un archivo útil necesita más que una paleta. Debe fijar tipografía, escalas, espaciado, radios, jerarquía, comportamiento de componentes y límites de uso. La parte narrativa es igual de importante: explica qué decisiones expresan la marca y qué patrones deben evitarse.
Para un sitio editorial o de SEO, yo incluiría:
- colores con función, no solo nombres;
- jerarquía de títulos y ancho máximo de lectura;
- reglas para tablas, citas, llamadas y bloques de código;
- estados de foco y contraste mínimo;
- tratamiento de capturas y datos;
- formatos de imagen por canal;
- ejemplos aprobados y anti-ejemplos;
- una lista explícita de zonas que el agente no puede modificar.
Ese último punto evita que una tarea visual cambie navegación, formularios, medición o componentes protegidos.
Método de adopción
1. Extraer, no imaginar
Comienzo con el producto actual. Mido colores, fuentes, espaciados y componentes repetidos. Después documento las inconsistencias como decisiones pendientes. El agente no debe inventar una marca nueva bajo el pretexto de completar el archivo.
2. Probar con un artefacto pequeño
Uso una página o una diapositiva representativa. Comparo el resultado con una referencia aprobada y registro desviaciones de jerarquía, legibilidad, contraste y tono. Un render atractivo no es suficiente si ignora el contenido o rompe la interacción.
3. Versionar el contrato
DESIGN.md debe vivir junto al proyecto y revisarse como código. Cada cambio necesita un motivo y un ejemplo. Así el equipo puede saber si una diferencia proviene del modelo, de una instrucción o de una modificación deliberada del sistema.
4. Verificar la salida real
La revisión incluye escritorio y móvil, navegación por teclado, contenido largo, tablas, enlaces y exportación. En proyectos web también compruebo que el HTML y los assets finales existan, no solo que la vista previa se vea bien.
Dónde encaja Open Design
Según su documentación, Open Design permite trabajar con varios agentes, sistemas y formatos de salida. Eso reduce el acoplamiento a una sola interfaz, pero no elimina el trabajo editorial. Los complementos y habilidades también son código y deben revisarse antes de concederles acceso a archivos o servicios.
La ventaja real no es «diseño ilimitado». Es conservar el contrato, los artefactos y el historial en un entorno que el equipo puede inspeccionar. El coste sigue existiendo en modelos, revisión, infraestructura y tiempo de diseño.
Fuentes primarias
- Google Labs: especificación DESIGN.md
- Open Design: repositorio y documentación
- Open Design: especificación de complementos