Tokens primero, componentes después
Por qué mi proceso cambió al revés y qué gané al diseñar primero las variables, no los píxeles.
Las primeras tres semanas las dediqué a diseñar componentes. Botones, inputs, cards. Todo en Figma, todo “pixel perfect”, todo bonito. Cuando los devs abrieron el archivo, usaron dos de los catorce componentes que había diseñado.
No porque fueran feos. Sino porque no sabían cuándo usarlos.
El error que casi me cuesta el proyecto
Pensé que el sistema era la librería de componentes. Resulta que el sistema es el lenguaje que los componentes hablan. Si el lenguaje no está claro, los componentes son ruido.
Lo entendí leyendo sobre Design Tokens
y mirando cómo equipos grandes (GitHub Primer, Shopify Polaris) lo resuelven:
los tokens van primero, los componentes después. Siempre.
El pivote: cambiar el orden
En lugar de entregar componentes terminados, entregué primero los tokens:
tres archivos JSON con colores, espacios y radios. Los devs podían usarlos
inmediatamente, sin tener que decidir entre Button/Primary o
Button/PrimaryLarge.
La diferencia fue inmediata. Engineering empezó a usar los tokens sin pedirme permiso. Y cuando finalmente entregué los componentes, ya conocían el lenguaje.
/* tokens.css */
:root {
--color-bg-canvas: #F8FAFC;
--color-fg-default: #0F172A;
--color-brand-600: #6125E7;
--space-1: 4px;
--space-2: 8px;
--space-4: 16px;
--radius-md: 8px;
}Lo que aprendí
Tres cosas que me llevo de ese proyecto:
- Tokens primero, componentes después. El sistema es el lenguaje, no la librería.
- Los componentes son consecuencia. Si el lenguaje es claro, los componentes se eligen solos.
- El primer entregable útil no se ve. Es un JSON que el equipo consume en silencio.
Si tuviera que hacerlo de nuevo, arrancaría por ahí. Y no esperaría tres semanas para darme cuenta.