Sistemas de Diseño: De la UI a la Ingeniería

La mayoría de los equipos de producto confunden una librería de componentes con un sistema de diseño. Esa confusión genera fricción operativa que se acumula sprint tras sprint hasta que el producto se convierte en un mosaico de decisiones visuales contradictorias. Un botón tiene cuatro variantes en producción, ninguna documentada, y cada desarrollador elige la que encuentra primero en el codebase.

Un sistema de diseño auténtico funciona como un contrato técnico entre el equipo de diseño y el equipo de ingeniería. Ese contrato establece que un token de color llamado --color-cyan siempre renderiza #00e5ff, que el espaciado entre elementos sigue una escala de 4px, y que un componente de botón primario tiene exactamente tres estados: default, hover y disabled. No hay espacio para interpretaciones.

Mi metodología para construir estos sistemas parte de los tokens, no de los componentes. Los tokens — colores, tipografías, espaciados, sombras, bordes — son las unidades atómicas del lenguaje visual. Cuando estos valores se definen como variables CSS o constantes de Tailwind, el diseñador y el desarrollador trabajan con el mismo vocabulario. La ambigüedad desaparece porque ambos referencian el mismo origen de verdad.

// Tokens → Componentes → Patrones → Páginas
// Nivel 1: Tokens primitivos
--spacing-unit: 4px;
--radius-sm: 2px;
--color-action: var(--color-cyan);

// Nivel 2: Tokens semánticos
--button-padding: calc(var(--spacing-unit) * 3);
--button-bg: var(--color-action);
--button-radius: var(--radius-sm);

Los componentes se construyen sobre estos tokens como abstracciones de segundo nivel. Un no define su propio color — consume --button-bg. Si el equipo de marca decide cambiar el color primario, un único cambio en los tokens propaga la actualización a toda la aplicación sin tocar un solo componente.

La documentación del sistema es tan importante como su implementación. Un token sin documentación es una deuda técnica latente. En mis proyectos, cada componente incluye su especificación de uso, sus variantes permitidas y sus restricciones explícitas. Esta documentación no vive en un wiki externo — está embebida en el código como comentarios estructurados y en Storybook como ejemplos interactivos.

El resultado de esta arquitectura es previsible: los equipos iteran más rápido porque no necesitan tomar decisiones visuales en cada feature. La consistencia del producto mejora porque las decisiones ya están tomadas y codificadas. Y la escala deja de ser un problema porque el sistema se extiende de forma modular, no mediante copiar y pegar. // SYSTEM_SYNC: 100%