Caso de estudio · 2026—presente
Un sistema de diseño que compila
Un framework de diseño a código asistido por IA para mantener coherentes las decisiones de producto de Figma a SwiftUI.
01 · El problema
Estoy construyendo Corner Coach, un producto iOS de cero a lanzamiento. Para ir rápido, uso agentes de código con IA para implementar el producto. Pero la velocidad trae un problema conocido: la interfaz generada puede ser verosímil sin ser fiel al sistema de diseño.
Un modelo puede reproducir patrones de interfaz comunes. No puede saber de forma confiable qué decisiones son específicas de un producto a menos que esas decisiones estén disponibles de manera estructurada y verificable.
Quería construir un framework que permitiera a quien diseña trabajar con IA sin ceder el control del sistema de diseño.
Un sistema de diseño es más que una colección de colores, estilos de texto y componentes. Es un conjunto de decisiones de producto:
- qué componente debe usarse;
- qué combinaciones están permitidas;
- cómo se comportan los estados y las variantes;
- qué valores son semánticos;
- qué detalles son propios de este producto y no convenciones genéricas de UI.
Cuando esas decisiones viven solo en un archivo de diseño o en un documento escrito, un agente de IA puede pasarlas por alto. El resultado puede compilar, verse razonable y aun así alejarse del sistema.
El desafío pasó a ser:
¿Cómo puede quien diseña usar IA para crear código de producto mantenible manteniendo el sistema de diseño como fuente de verdad?
02 · De la documentación a la aplicación de reglas
Empecé investigando cómo los sistemas de diseño existentes comunican sus reglas a personas y a máquinas. La investigación mostró una progresión:
- Documentar el sistema para que sea más fácil de entender.
- Dar al agente instrucciones explícitas.
- Estructurar el flujo de trabajo para que los errores importantes sean difíciles o imposibles de cometer.
Ese tercer enfoque dio forma al framework.
Al principio lo pensé como un conjunto de barandas de seguridad. Con más precisión, es un arnés de cumplimiento alrededor de un sistema de diseño: un conjunto de exportaciones, referencias generadas, verificaciones y ciclos de retroalimentación que ponen las decisiones de diseño al alcance de un agente de IA y hacen visible la desviación cuando ocurre.
La distinción importa.
Una regla escrita se puede ignorar. Un tipo ausente, una variante de componente no disponible o una verificación fallida son mucho más difíciles de eludir.
03 · El framework
El framework conecta un sistema de diseño en Figma con una aplicación construida en SwiftUI.
Figma es donde se crean las decisiones de diseño. Un plugin exporta el sistema a tokens estructurados, información de componentes y documentación. Un compilador transforma esa información en código Swift, assets y referencias que pueden usar tanto la aplicación como el agente de código.
El framework también mantiene un pequeño conjunto de excepciones explícitas para información que Figma no puede representar. Eso evita que el sistema cree una segunda fuente de verdad: si Figma puede expresar una decisión, pertenece a Figma; si no puede, la excepción debe quedar claramente identificada y mantenerse por separado.
El flujo es:
- Figma
- Plugin de exportación
- Tokens y datos de componentes
- Implementación en SwiftUI
- Verificaciones deterministas
El sistema es deliberadamente unidireccional. Primero se crea en Figma, y todo lo que viene después se genera a partir de eso.
04 · Diseñar para ambos lados del puente
El lado del diseño usa Figma porque resulta familiar para quienes diseñan producto y accesible para desarrolladores y product managers que revisan el trabajo.
No es una fuente perfecta para código. Algunas variables y relaciones entre tokens necesitan interpretación antes de poder usarse en Swift. Esa brecha pasó a ser parte del propósito del framework: traducir la intención de diseño en información que un agente de código pueda usar sin depender de capturas de pantalla, transcripción manual ni conjeturas.
El plugin ahora ayuda con tareas como:
- exportar variables y tokens;
- identificar valores sin vincular;
- encontrar componentes que no forman parte del sistema de diseño;
- comprobar si las pantallas usan los tokens y componentes disponibles;
- exportar descripciones de componentes para usarlas durante la implementación;
- hacer visibles las inconsistencias del lado del diseño antes de que lleguen al código.
El lado de la implementación es hoy Swift y SwiftUI porque Corner Coach es un producto iOS. El framework se está desarrollando pensando en la portabilidad, pero esta versión está deliberadamente anclada en una plataforma real y un producto real.
05 · Probar la idea con un producto real
Empecé con un pequeño sistema de diseño en Figma que contenía tokens, variables y unos pocos componentes básicos. Luego lo usé para construir las primeras pantallas de Corner Coach.
Esas primeras pantallas no eran solo trabajo de producto. Eran pruebas del framework.
Cada implementación dejó al descubierto vacíos:
- tokens que existían visualmente pero no estaban representados de forma semántica;
- variantes de componentes que no se habían definido;
- valores que estaban cerca de la escala pero en realidad no formaban parte de ella;
- decisiones de diseño que eran claras para una persona pero ambiguas para un agente;
- fallos que pasaron la revisión de código porque parecían verosímiles.
Después de cada ronda, actualicé tanto el producto como el framework. El producto le dio al framework restricciones reales; el framework hizo el producto más consistente y más fácil de extender.
06 · Seis verificaciones, seis modos de fallo distintos
El framework no depende de un único gran paso de validación. Usa verificaciones separadas porque distintos fallos requieren distintas formas de verificación.
- El compilador
- Verifica los datos de diseño exportados.
- El verificador de código
- Identifica implementaciones que esquivan el sistema, como colores en bruto, números mágicos, fuentes por defecto o efectos hechos a mano.
- El sistema de tipos
- Limita las combinaciones de componentes inválidas y los tokens no disponibles.
- La verificación en tiempo de ejecución
- Detecta fallos que compilan sin problema pero se renderizan mal, como una fuente personalizada ausente que se sustituye en silencio.
- La auditoría del lado del diseño
- Comprueba si el archivo de Figma respeta sus propios tokens, estilos y reglas de componentes.
- La verificación de contexto
- Comprueba qué se le está pidiendo leer al agente de código, asegurando que las referencias generadas, la documentación y las instrucciones siempre cargadas sigan siendo precisas y acotadas.
El objetivo no es que el modelo sea perfecto. El objetivo es que el trabajo incorrecto sea difícil de aprobar y fácil de diagnosticar.
07 · Lo que cambió el framework
El framework ha cambiado tanto mi forma de diseñar como mi forma de implementar.
Como las pantallas se verifican contra el sistema, no puedo dar una pantalla por completa solo porque se vea terminada. El proceso obliga a preguntas como:
- ¿Qué pasa en cada estado?
- ¿Este componente necesita otra variante?
- ¿Este valor es semántico o simplemente conveniente?
- ¿Qué pasa cuando el contenido es más largo?
- ¿Esta interacción está representada en el sistema de diseño?
- ¿Puede la implementación usar la misma decisión sin inventar una nueva?
Eso ha convertido al framework en una herramienta de diseño además de una herramienta de desarrollo.
También mejoró la eficiencia del flujo de trabajo con IA. Al rastrear en qué se gastaban el contexto y el uso de modelos, separé el trabajo en etapas distintas: planificación con un modelo más capaz, implementación con un modelo más rápido y verificación con herramientas deterministas.
El framework también es independiente del arnés. El mismo repositorio puede ser usado por distintos agentes de código, incluidos Codex y Claude, porque las reglas importantes viven en la estructura del proyecto y en las verificaciones y no en la configuración de un solo agente.
Y lo más importante: lo uso de forma continua mientras construyo Corner Coach. En menos de un trimestre he llevado el producto hasta la mitad del camino hacia el lanzamiento, trabajando en solitario como diseño y construcción, mientras sigo mejorando el sistema que lo sostiene.
08 · Qué afirma, y qué no
El framework no evita que un agente de IA produzca código incorrecto. Hace algo más útil: evita que el código incorrecto pase en silencio por terminado.
No reemplaza a la ingeniería, la revisión de diseño ni el criterio de producto. No aprueba automáticamente los cambios en el archivo de diseño. Cada escritura de vuelta en el sistema de diseño todavía requiere que una persona revise el cambio.
Hoy está probado en un sistema de diseño y un producto iOS. Su arquitectura pretende ser reutilizable, pero esa portabilidad todavía debe probarse en otros sistemas y plataformas.
09 · Lo que aprendí
La lección más importante es que la consistencia no puede depender por completo de la memoria, la documentación o la calidad del modelo.
Si una regla importa, necesita un lugar en el flujo de trabajo donde se pueda verificar. Si una decisión puede representarse como un tipo, un token, una API de componente o una prueba determinista, no debería quedarse solo como prosa.
El framework también me enseñó que cada implementación es una auditoría del sistema de diseño. Construir con el sistema deja al descubierto tokens semánticos faltantes, componentes incompletos, estados poco claros y decisiones que nunca se formalizaron.
En ese sentido, el producto y el framework se mejoran mutuamente:
El producto pone a prueba si el framework es útil. El framework pone a prueba si el sistema de diseño es real.
10 · Hacia dónde lo llevo ahora
Las próximas iteraciones pondrán a prueba qué tan portable es realmente el framework:
- adaptar el flujo de trabajo de SwiftUI a React;
- explorar cómo podría integrarse con Storybook y herramientas similares de documentación de componentes;
- probar Paper como entorno de diseño alternativo;
- admitir un flujo inverso en el que desarrolladores crean o actualizan pantallas en código y las traen de vuelta al sistema de diseño;
- explorar la generación de pantallas nuevas enteramente a partir de componentes existentes del sistema de diseño, y luego llevarlas a Figma para refinarlas.
El objetivo a largo plazo no es simplemente generar interfaces más rápido. Es crear una relación de trabajo confiable entre los sistemas de diseño, quienes diseñan producto y el desarrollo asistido por IA.
Solo método y hallazgos · Sin código fuente ni trabajo de clientes
La progresión documentación → instrucción → estructura de la §02 sigue el planteamiento de Deloumeau-Prigent, K. (2026). State of AI in Design Systems. CC BY 4.0. Datos recopilados en julio de 2026.