Design systems como catálogos de capacidades, no de componentes
Un catálogo de capacidades en el design system describe lo que la UI puede hacer — no solo cómo se ve. Cuando agentes de AI componen interfaces, el sistema que codifica intención, restricciones y reglas de accesibilidad gana sobre el que solo entrega componentes y tokens.
Una librería de componentes le dice al desarrollador qué botón renderizar. No le dice a un agente de AI si ese botón debería existir en una pantalla dada, qué acción autoriza, qué confirmación requiere, o qué sucede cuando la acción falla. La brecha entre "aquí hay un componente estilizado" y "esto es lo que esta interfaz puede hacer" es donde la mayoría de los design systems se detienen — y donde las interfaces generadas por AI se rompen. Un catálogo de capacidades en el design system cierra esa brecha codificando intención, restricciones y comportamiento permitido junto a las primitivas visuales.
AI rompe los design systems que solo definen componentes
Las librerías de componentes definen apariencia: tokens de color, escalas de espaciado, rampas tipográficas, props de variante. Responden la pregunta "¿cómo se ve esto?" con precisión. No responden "¿cuándo debería aparecer?", "¿qué datos requiere?", "¿qué permisos debe tener el usuario?", ni "¿qué pasa si la operación falla?"
Cuando un desarrollador humano compone una pantalla, esas respuestas viven en conocimiento tribal, design reviews y convenciones no escritas. Cuando un agente de AI compone una pantalla, esas respuestas no existen a menos que el sistema las codifique explícitamente. Un agente generando un formulario no puede inferir que la recolección de método de pago requiere aislamiento de campos PCI-compliant, copy de error específico para tarjetas rechazadas, y un paso de confirmación — a menos que el design system declare que "recolectar método de pago" es una capacidad con esas restricciones adjuntas.
El modo de falla no es UI fea. Es UI insegura, inaccesible o engañosa. Un AI que genera una acción destructiva sin diálogo de confirmación no ha violado una guía de estilo. Ha violado una restricción de comportamiento que nunca fue formalizada.
Un catálogo de capacidades describe intención, no solo apariencia
Una capacidad es una unidad de comportamiento de producto que la interfaz tiene permitido expresar. Se ubica por encima de los componentes y por debajo de los features. Donde un componente dice "renderiza un modal con estos props," una capacidad dice "solicita confirmación del usuario antes de una acción irreversible, usando un modal con path de cancelación explícito, focus trap accesible, y copy de acción con calidad de auditoría."
La distinción importa porque una capacidad codifica:
- Intención — qué objetivo de producto sirve esta UI (recolectar consentimiento, confirmar eliminación, solicitar escalación).
- Restricciones — qué debe ser verdadero para que esta UI aparezca (permisos del usuario, estado de datos, feature flag).
- Reglas de composición — qué componentes y patrones están aprobados para esta intención, y cuáles están prohibidos.
- Contrato de accesibilidad — qué roles ARIA, comportamiento de foco, interacciones de teclado y anuncios de screen reader requiere la capacidad independientemente de la implementación visual.
- Estados de error y recuperación — qué pasa cuando el happy path falla, incluyendo copy de fallback y comportamiento de retry.
Un catálogo de capacidades hace estas declaraciones legibles por máquina. Un agente de AI o un generador de código consultando el catálogo recibe no solo una lista de componentes sino un contrato semántico describiendo lo que la interfaz puede hacer, bajo qué condiciones, con qué salvaguardas.
Las restricciones son el verdadero producto del design system
La mayoría de los equipos de design systems miden éxito por tasa de adopción y cobertura de componentes. El promedio de la industria cuenta la historia: solo alrededor de uno de cada cinco design systems alcanza 80% de cobertura de adopción, y durante cinco años consecutivos, impulsar la adopción se ha mantenido como el desafío principal. La percepción faltante es que la adopción se estanca no porque los componentes estén mal construidos, sino porque el sistema no codifica las restricciones que hacen a los componentes seguros de usar sin supervisión.
Un catálogo de restricciones transforma el design system de una capa de estilizado a una capa de gobernanza:
| Capa | Qué define | A quién sirve |
|---|---|---|
| Tokens | Colores, espaciado, tipografía, curvas de motion | Consistencia visual |
| Componentes | Primitivas interactivas (botones, inputs, modals, cards) | Velocidad de implementación |
| Patrones | Composiciones recurrentes (layouts de formulario, tablas de datos, navegación) | Consistencia estructural |
| Capacidades | Intención + restricciones + accesibilidad + manejo de errores | Seguridad de comportamiento |
La capa de capacidades es lo que hace a un design system útil para agentes de AI, generadores de código y desarrolladores junior que carecen del conocimiento tribal para componer interfaces de forma segura. Sin ella, el sistema es una paleta — estéticamente consistente pero semánticamente vacío.
La accesibilidad debe codificarse, no recordarse
El análisis de 158 design systems públicos revela un patrón claro: 89% entregan ejemplos de código, pero solo 21% documentan requerimientos de accesibilidad. El 79% restante depende de que los desarrolladores recuerden agregar atributos ARIA, gestionar foco, manejar navegación por teclado y proveer anuncios de screen reader — requerimientos que son invisibles en un preview de componente pero críticos en producción.
Un catálogo de capacidades cambia esto adjuntando contratos de accesibilidad a cada declaración de capacidad:
const capability = {
id: "confirm-destructive-action",
intent: "Solicitar confirmación explícita del usuario antes de una operación irreversible",
components: ["ConfirmationDialog", "DestructiveButton"],
accessibility: {
focusTrap: true,
initialFocus: "cancel-button",
ariaLabelledBy: "dialog-title",
keyboardDismiss: "Escape",
screenReaderAnnouncement: "Confirmación requerida: {descripción de la acción}",
},
constraints: {
requiresPermission: "write",
requiresExplicitCancel: true,
destructiveActionCopy: "debe nombrar el recurso siendo eliminado",
},
errorStates: {
networkFailure: "Mostrar retry inline con contexto original preservado",
permissionRevoked: "Redirigir a vista de acceso denegado",
},
}Cuando un agente de AI compone esta capacidad, no puede saltarse el focus trap. No puede poner el foco por defecto en el botón destructivo. No puede omitir el path de dismiss por teclado. Las restricciones no son documentación — son el contrato de la interfaz.
La arquitectura frontend se convierte en una capa de gobernanza de diseño
El cambio de librería de componentes a catálogo de capacidades tiene consecuencias arquitecturales. El design system ya no es una dependencia que entrega componentes React estilizados. Se convierte en un registry que expone metadatos legibles por máquina junto a la implementación.
Una arquitectura registry-first separa tres concerns:
- El registry — un catálogo estructurado de capacidades, sus restricciones, componentes aprobados y contratos de accesibilidad. Consultable por agentes de AI, generadores de código, linters y herramientas de documentación.
- La implementación — los componentes React (o específicos del framework) que satisfacen los contratos del registry. Estos siguen viviendo en un package, siguen usando tokens, siguen renderizando al DOM.
- La capa de validación — reglas de lint, checks de CI y assertions runtime que verifican que las interfaces compuestas cumplen con las restricciones del registry. Un formulario que recolecta información de pago pero omite el aislamiento de campos PCI-required falla la validación antes de llegar a producción.
Esta arquitectura hace a los design systems útiles para AI de la misma forma que los sistemas de tipos hacen al código útil para los compiladores. El registry describe lo que es válido. La implementación provee lo que es posible. La capa de validación enforce la frontera entre ambos.
El enfoque se alinea con cómo los equipos ya gestionan la calibración de confianza en interfaces generadas por AI: el sistema define guardrails que previenen que el output de AI exceda su alcance autorizado, y luego deja al agente componer libremente dentro de esos límites.
¿Preguntas frecuentes sobre design system como catálogo de capacidades?
Distinciones prácticas emergen cuando los equipos evalúan si su sistema actual está listo para interfaces compuestas por AI.
¿Un catálogo de capacidades reemplaza los componentes?
Un catálogo de capacidades no reemplaza componentes — se ubica como capa por encima de ellos. Los componentes siguen siendo las primitivas de renderizado. Las capacidades describen cuándo y cómo esos componentes pueden componerse, bajo qué restricciones, y con qué comportamiento obligatorio. Un equipo puede adoptar descripciones de capacidades incrementalmente, comenzando con las intenciones de producto de mayor riesgo (pago, eliminación, cambios de permisos) y expandiendo a medida que la cobertura madura.
¿Qué hace a una capacidad legible por máquina para agentes de AI?
Una capacidad debe declarar su intención en lenguaje natural, listar componentes aprobados, especificar requerimientos de accesibilidad como contratos estructurados (no documentación en prosa), definir estados de error y recuperación, y exponer predicados de restricción que un agente pueda evaluar antes de componer. JSON Schema, interfaces TypeScript, o APIs de registry funcionan — el formato importa menos que la completitud del contrato.
¿Cómo previenen las restricciones que AI genere UI insegura?
Las restricciones actúan como reglas de validación pre-composición. Antes de que un agente de AI renderice una capacidad "recolectar método de pago", verifica si el aislamiento de campos PCI-compliant está presente, si existe copy de error para tarjetas rechazadas, y si el paso de confirmación está incluido. Restricciones faltantes bloquean la generación de la misma forma que un type check fallido bloquea la compilación — la interfaz no puede componerse hasta que el contrato se satisface.
Una visión opuesta
Un argumento recurrente sostiene que los design systems ya luchan con la adopción a nivel de componentes — agregar una capa de capacidades introduce abstracción que los equipos no van a usar. Si solo el 22% de los sistemas alcanzan alta cobertura con componentes solos, el argumento dice, agregar declaraciones de intención y contratos legibles por máquina hará al sistema más pesado, más lento de mantener, y más difícil de justificar ante liderazgo.
El argumento identifica un riesgo real: abstracción prematura. Un equipo con diez componentes y sin interfaces compuestas por AI no necesita un catálogo de capacidades. Pero el argumento no ve por qué la adopción se estanca en primer lugar. Los sistemas fallan no porque sean demasiado complejos, sino porque proveen componentes sin contexto — el desarrollador aún necesita descifrar cuándo, por qué y cómo usarlos. Un catálogo de capacidades es la capa de contexto. Responde las preguntas que la documentación faltante nunca respondió, en un formato que tanto humanos como máquinas pueden consumir.
Lo que importa recordar
- Una librería de componentes define apariencia; un catálogo de capacidades define comportamiento permitido, intención y restricciones.
- Los agentes de AI no pueden inferir accesibilidad, permisos ni manejo de errores solo de los props de componentes — deben declararse como contratos legibles por máquina.
- Las declaraciones de capacidades se ubican por encima de los componentes, no los reemplazan — comenzar con las intenciones de producto de mayor riesgo y expandir incrementalmente.
- Solo el 21% de los design systems analizados documentan accesibilidad — codificarla como contrato en la capa de capacidades cierra la brecha para humanos y máquinas.
- La arquitectura frontend debe dividirse en registry (lo que es válido), implementación (lo que es posible) y validación (lo que se enforce).
- El catálogo de restricciones es lo que hace a un design system listo para interfaces compuestas por AI — sin él, el sistema solo gobierna estética.
Conclusión
El design system que solo describe cómo se ven las cosas ya está atrasado. Los agentes de AI componen UI hoy — generando formularios, sugiriendo workflows, adaptando layouts. Cada interfaz compuesta sin restricciones explícitas es un pasivo esperando que un usuario encuentre un diálogo de confirmación faltante, un modal inaccesible, o una acción destructiva sin path de recuperación. La próxima inversión en design systems no es más componentes. Es la capa semántica que le dice a cualquier compositor — humano o máquina — qué puede hacer la interfaz, bajo qué condiciones, y qué nunca debe saltarse.
