Un sistema de diseño en código, construido desde los tokens
El lenguaje visual de Airtm vivía en Figma. Construí el sistema en código desde cero: primero los tokens, después 35 componentes React, un Storybook y un sitio de documentación, y seis verificaciones que comparan Figma, el código y lo que la app entrega. Después prototipé con él.
Airtm · 2026 · En uso, may–sep 2026
Ficha del proyecto
- Lo lideré
- Equipo de diseño, 1 PM, ingenieros
- 1 mes hasta la primera versión
Fue una iniciativa del equipo de diseño, y yo la impulsé: llevar el sistema de Figma al código, correr Storybook y auditar qué coincidía con Figma y qué no. Lo construí con herramientas de IA y revisé cada decisión que registra.
- Problema
- El diseño de Airtm vivía en tres lugares que no coincidían: varias bibliotecas en Figma, la biblioteca de componentes de producción y la memoria de cada diseñador sobre ambas.
- Decisión
- Hacer del código la referencia de trabajo, y dejar que scripts, y no opiniones, digan dónde Figma y producción se alejan de él.
- Resultado
- 35 componentes más 6 módulos del kit de prototipos, con Storybook y sitio de documentación, seis verificaciones automáticas, y 52 de 56 colores primitivos coincidiendo con producción en la primera corrida.
Pruébalo
El Button de la biblioteca, transcrito para esta página. Cambia la intención, el énfasis, el tamaño, el estado y el tema; el panel sigue cada color hasta su token y mide el contraste. El predeterminado ya muestra un hallazgo: blanco sobre el azul de la marca da 4,49:1, justo debajo de AA. Es uno de los 30 pares que encontró la verificación.
Intención
Énfasis
Tamaño
Estado
Tema
<Button intent="primary" emphasis="solid" size="md">De dónde vienen los colores
Contraste
4.49:1
El Button de la biblioteca de Airtm, transcrito. Cada color es un token; el contraste se mide como lo mide la verificación de la biblioteca.
Nada podía parar
Figma seguía siendo la herramienta de los diseñadores, producción seguía entregando su propia biblioteca, y nadie tenía tiempo para reescribir todo. Lo que construyera tenía que convivir con ambos, y ser útil desde la primera semana.
Por qué tenía que ser código
Dos motivos. El equipo necesitaba ver el sistema funcionando: Storybook, todos los estados y una auditoría honesta de qué coincidía con Figma. Y yo quería prototipar más rápido, con componentes 100% fieles a los diseños de Figma. Los prototipos hechos con componentes reales generan valor antes, son más fáciles de compartir con stakeholders y mejoran las pruebas con usuarios, porque la gente reacciona al producto y no a un dibujo de él.
Cómo está construido
Tres capas. Las primitivas son los valores crudos de las fundaciones de Figma. Los tokens semánticos dicen para qué sirve un color, un fondo o un estado, y los componentes solo usan esos, nunca un hex. Cada componente expone las decisiones que un diseñador realmente toma: el Button tiene tres intenciones, tres énfasis y tres tamaños, además de cargando y deshabilitado, con los espaciados del auto layout de Figma. Esa estructura es lo que permite que una verificación siga cualquier color hasta su origen.
El código como referencia
Rehice el sistema en React, primero los tokens y después cada componente con sus estados. Los prototipos importan estos mismos componentes, así que prototipo y sistema no se separan sin que nadie lo note.
Las verificaciones deciden
Seis scripts corren juntos. Comparan los tokens con Figma, los tokens con producción, los componentes con sus fuentes en Figma, la navegación con su taxonomía, y cada par de texto y fondo con el contraste WCAG en los dos temas. Una diferencia se vuelve una línea en un reporte que cualquiera puede revisar.
Producción como tercera fuente
Cuando llegó la biblioteca de producción, entró como un snapshot y empezó a compararse también. 52 de 56 colores primitivos coincidieron en la primera corrida. Los cuatro que no coincidieron eran hallazgos reales, entre ellos un gris que estaba mal en las foundations impresas desde hacía meses.
Los hallazgos van a personas
Las verificaciones no corrigen nada solas. Cuando código y producción no coinciden, la decisión es del equipo de diseño. Las verificaciones pusieron en cola 14 de esas decisiones, y cada una tiene su registro.
Cómo usé IA
Lo construí con herramientas de IA para código. Yo definí la estructura y lo que cada verificación tenía que probar, y revisé cada decisión que el sistema registra. Así la primera versión salió en un mes. Lo que el sistema debía ser siguió siendo una decisión mía y del equipo de diseño.
Una sola fuente de verdad
Siguen siendo tres fuentes de verdad: Figma para el diseño, el código para la intención, producción para lo que ve el usuario. Dejé de intentar unirlas e hice visibles las diferencias. El costo es mantenimiento: alguien tiene que mantener los snapshots al día.
Lo que construyó y lo que encontró
- Construido
- 35 componentes y 6 módulos del kit de prototipos, Storybook, sitio de documentación y un inventario de los 156 módulos de la biblioteca de producción, en una sola página.
- Encontrado
- 30 pares de color por debajo de WCAG AA, los dos blancos detrás de una inconsistencia antigua, y nombres de componentes publicados dos veces en Figma.
- Usado
- Mis prototipos y handoffs en Airtm salieron de él, de mayo a septiembre de 2026. Producción mantuvo su propia biblioteca; las verificaciones miden la distancia.
Siguiente paso: las verificaciones en CI
Correr las verificaciones en CI con cada cambio del sistema de diseño, y llevar los 30 pares de contraste a triage con el equipo. Esa lista es el trabajo de accesibilidad más directo que le queda al sistema.