Puntos clave
- Un sistema de diseño es un motor de decisiones, no un inventario de componentes: la intención es la capa que importa.
- La madurez no es el número de componentes, sino con qué fiabilidad tu equipo llega a la misma decisión sin una reunión.
- La IA puede copiar tus componentes pero no tu razonamiento: documenta la intención como reglas explícitas y legibles por máquinas.
- Sincroniza código y diseño en una única fuente de verdad para que ninguno se desvíe y las herramientas puedan razonar contra ella.
- Los sistemas centrados en la intención entregan más rápido, incorporan más ágilmente y delegan trabajo en la IA de forma segura.
La mayoría de los equipos piensa que un sistema de diseño es una biblioteca de Figma más un conjunto ordenado de componentes programados. Eso es el artefacto, no el sistema. El verdadero sistema es el conjunto de decisiones, restricciones y razonamiento que explica por qué un botón luce como luce, cuándo usarlo y qué compensaciones se aceptaron en el camino. Quítale eso y te quedas con un kit de estilos que se desvía en cuanto tu equipo escala o una herramienta de IA empieza a generar pantallas en tu nombre.
Esta distinción ha pasado de ser filosófica a ser urgente. Google, Atlassian y Figma ahora están publicando archivos que capturan la intención detrás de un diseño, no solo los tokens y las especificaciones. La razón es simple: los componentes te dicen qué existe, pero solo la intención le dice a un humano o a una máquina qué hacer a continuación.
Por qué los componentes nunca fueron el punto
Un componente es una respuesta congelada a una pregunta que ya se formuló. La pregunta —«¿cómo deberían los usuarios confirmar una acción destructiva?»— es donde vive el valor. Cuando la pregunta no está documentada, cada nuevo diseñador, desarrollador y ahora cada LLM la responde desde cero, a menudo de forma inconsistente.
Vemos esto constantemente en las auditorías. Un cliente tiene 1.200 componentes y cero gobernanza. Existen cuatro variaciones de la misma tarjeta porque nadie registró la justificación de la primera. La biblioteca parece madura; el sistema está prácticamente muerto. La madurez no es el tamaño de tu inventario de componentes, sino con qué fiabilidad tu equipo llega a la misma decisión sin una reunión.
Las tres capas de un sistema que de verdad se sostiene
- Fundamentos: tokens, espaciado, tipografía, color: la gramática en bruto.
- Componentes: las oraciones reutilizables construidas a partir de esa gramática.
- Intención: las reglas, principios y compensaciones que deciden qué oración decir y cuándo.
Casi todos invierten en las dos primeras y descuidan la tercera. Esa tercera capa es lo que hace que un sistema sea defendible, enseñable y —fundamentalmente— legible por máquinas.
El cambio de la IA: las máquinas necesitan tu razonamiento, no tus píxeles
Esta es la verdad incómoda sobre el diseño y el desarrollo asistidos por IA: un modelo puede copiar tus componentes de forma impecable y aun así producir algo que no encaja con la marca, porque no tiene acceso a tu razonamiento. Sabe cómo se ve tu botón principal. No sabe que lo reservas para la acción más importante de cada pantalla.
Por eso importa la práctica emergente de hacer que los sistemas estén «listos para la IA». Protocolos como MCP (Model Context Protocol) están empezando a conectar código, Figma y documentación para que las herramientas puedan consultar no solo los recursos, sino también las restricciones. Un sistema bien estructurado se convierte en una fuente de verdad contra la que una IA puede razonar, convirtiendo «genera una página de pago» en algo que respeta tus reglas reales en lugar de una suposición de apariencia plausible.
La misma lógica aplica al construir fundamentos de marca con herramientas como Claude. La IA acelera el trabajo pesado —nombrar escalas, redactar documentación de uso, generar variantes—, pero solo si le proporcionas barreras de protección. Sin intención documentada, la IA simplemente industrializa tu inconsistencia.
Cómo reconstruir tu sistema en torno a la intención
No necesitas quemarlo todo. Necesitas superponer significado sobre lo que ya tienes.
- Documenta decisiones, no solo especificaciones. Para cada componente central, registra el problema que resuelve, cuándo usarlo, cuándo no, y la compensación que aceptaste. Un párrafo supera a un PDF de 40 páginas que nadie lee.
- Haz que las reglas sean consumibles por máquinas. Estructura las pautas de uso como restricciones explícitas («botón principal: máximo uno por vista») en lugar de prosa. Tanto los diseñadores junior como los LLM interpretan mejor las reglas que las sensaciones.
- Conecta código y diseño como una sola fuente. Si tu Figma y tu base de código no coinciden, ninguno es confiable. Sincronízalos —manualmente o mediante herramientas tipo MCP— para que haya un único estado canónico.
- Trata la gobernanza como un producto. Asigna responsabilidad, versiona el sistema y mide la adopción. Un sistema sin mantenedor es un pasivo con fecha de vencimiento.
El argumento de negocio para sistemas centrados en la intención
Esto no es higiene estética, es apalancamiento operativo. Los equipos que documentan la intención entregan más rápido porque se vuelven a litigar menos decisiones. Incorporan a diseñadores y desarrolladores en días, no en meses. Y están posicionados para delegar trabajo real en la IA sin que colapse la calidad, porque su sistema puede explicarse realmente a una máquina.
Las agencias y los equipos de producto que ganen en los próximos años no serán los que tengan las bibliotecas de componentes más bonitas. Serán aquellos cuyos sistemas codifiquen el criterio, de modo que, ya sea que la próxima pantalla la construya un diseñador sénior, un recién contratado o un modelo, salga correcta. Replantea tu sistema como un motor de decisiones y los componentes por fin harán lo que siempre debieron hacer: seguir las reglas.
Fuentes
- Cómo construir un fundamento de marca con IA sin perder tu oficio — UX Collective
- Cómo construir una biblioteca de sistema de diseño lista para la IA: Código → Figma con MCP. — UX Collective
- Tu sistema de diseño nunca fue sobre los componentes — UX Collective
- El estado de un sistema — UX Collective
