Arquitectura de Design Tokens y componentes reutilizables integrados con Nuxt UI y Tailwind, el sistema que hizo posible todo lo demás.
Sin un sistema compartido, diseño e ingeniería hablaban idiomas distintos. En producción, cada componente existía en tres versiones simultáneas.
El producto de GroWrk funcionaba sobre una base frágil. Los diseños originales habían nacido en PowerPoint y Google Slides. Había una paleta de colores en Figma, pero no un sistema. Cada feature nueva obligaba a reinventar decisiones ya tomadas.
El problema se volvió crítico al tercer año, durante la actualización de identidad visual. En producción convivían decenas de versiones del mismo botón, cada developer lo había resuelto a su manera. El Design System de Figma existía, pero ingeniería no lo implementaba: eran dos mundos paralelos.
El objetivo quedó claro: una sola fuente de verdad, compartida por diseño e ingeniería, construida sin detener el producto.
Un Design System no se construye de una vez. Se cultiva.
El sistema pasó por dos iteraciones sobre una misma base y, finalmente, un rearranque tecnológico. Cada etapa resolvió el límite de la anterior.
La capa atómica del sistema.
Definí más de 300 tokens de color, tipografía, espaciado, radios y sombras, organizados en una nomenclatura compartida por diseño e ingeniería. Un cambio en un token se propaga a todo el producto sin editar una sola pantalla a mano.
Los tokens de color se estructuraron en primitivos (valores base del brand) mapeados a tokens semánticos. Esto eliminó los overrides manuales entre temas y redujo el riesgo de error humano en diseños listos para producción. El espaciado y los radios se estandarizaron en escalas fijas, y los breakpoints se definieron como variables para automatizar el comportamiento responsivo.
Del token al componente compuesto.
Sobre los tokens se construyó la librería: 40 componentes documentados en Figma y código, cada uno con sus variantes y estados. El objetivo del refactor fue reducir variantes duplicadas y componer en lugar de multiplicar.
button
From this file
Un componente sin documentación es una sugerencia, no un estándar.
Toda la fuente de verdad vive en Notion, conectada a Figma y al código. Cada componente tiene su propia entrada con la misma estructura, para que cualquier persona (diseño, ingeniería o alguien que acaba de entrar) sepa exactamente cómo y cuándo usarlo sin preguntar.
Cada entrada documenta:
El histórico es la pieza que mantiene vivo el sistema. Ningún componente cambia por decisión unilateral: cada ajuste queda documentado y se consulta con el equipo. Eso evita que el DS se fragmente con el tiempo, que es exactamente el problema del que partimos.
La documentación no es el final del trabajo de diseño. Es lo que lo vuelve reutilizable.
Un Design System es una serie de decisiones sobre cómo quieres que un equipo trabaje.
Al inicio el sistema era mi proyecto: lo construía y lo mantenía solo. Cambié el proceso e introduje workshops por componente antes de publicarlo, con decisiones colectivas sobre funcionalidad, variantes y estados. La adopción dejó de ser una imposición: quien participa en definir, adopta. La diseñadora Jr. pasó de usar el sistema a proponer mejoras que retroalimentaron cada versión.
NUXT UI resolvía los componentes estándar, pero las cards de producto de GroWrk requerían lógica que UTable o UCard no cubrían de forma nativa. Construí el ProductCard combinando múltiples componentes NUXT en uno reutilizable. Las necesidades nuevas se integran como variante, no como componente nuevo. Menos deuda de consistencia, más velocidad de implementación.
El DS custom de Figma estaba bien construido, pero el responsivo exigía mantenimiento en código que diseño no controlaba. La migración fue iniciativa de ingeniería y decidí abrazarla en lugar de defender el sistema propio. Adapté NUXT al lenguaje visual de GroWrk y documenté cada ajuste en Figma y código. El responsivo dejó de ser un conflicto y el sistema bilingüe cerró un gap de tres años.
La librería había acumulado 330 iconos en dos años, muchos redundantes o sin uso en producción. Una auditoría completa de uso real eliminó redundancias, homologó estilos y dejó 234 iconos activos con nomenclatura consistente. El equipo dejó de perder tiempo eligiendo entre tres versiones del mismo icono.
¿Y si el Design System pudiera diseñar contigo?
Con el sistema maduro y la documentación centralizada, las reglas ya estaban escritas y ordenadas. El siguiente paso fue convertirlas en contexto para que una IA generara UI fiel al sistema desde el primer prompt.
Esa exploración se volvió un proyecto por derecho propio. El Design System fue la base que lo hizo posible: sin tokens, componentes y reglas bien definidas, no habría contexto que darle a la IA.