El cementerio de design systems
Hemos visto el patrón decenas de veces: un equipo invierte semanas diseñando un sistema de diseño en Figma con tokens, variantes, auto-layout perfecto. Tres meses después, nadie lo usa.
¿Por qué? Porque un design system no es un archivo de Figma. Es un contrato entre diseño y desarrollo.
Qué hace que funcione
1. Empieza por los componentes que ya existen
No diseñes un sistema abstracto. Audita lo que ya tienes en producción. Identifica patrones repetidos. Formalízalos.
Un botón que ya existe en 3 variantes en tu código es mejor punto de partida que un botón teórico con 12 estados que nadie va a implementar.
2. Los tokens son el puente
Design tokens — colores, espaciados, tipografías, sombras — son el idioma compartido entre Figma y código.
/* Tokens, no valores mágicos */
--color-primary: #3245ff;
--space-4: 1rem;
--radius-lg: 0.75rem;
--shadow-card: 0 2px 8px rgba(0,0,0,0.12);Si el diseñador dice “primary” y el desarrollador entiende #3245ff, el sistema funciona.
3. Documentación viva, no PDFs
La documentación de componentes debe ser interactiva. Storybook, Histoire, o incluso una página dentro de tu propia app que muestre cada componente con sus variantes.
Si la documentación no se actualiza sola cuando cambia el código, no sirve.
Los errores que cometimos
Demasiadas variantes demasiado pronto
Un botón con 4 tamaños, 6 colores y 3 estados son 72 combinaciones. ¿Las necesitas todas? Probablemente no.
Empezamos con primary, secondary y ghost. Si necesitamos más, las agregamos cuando hay un caso de uso real.
Ignorar el responsive desde el diseño
Un componente que se ve perfecto en 1440px y se rompe en 375px no es un componente terminado. Diseñamos mobile-first y escalamos hacia arriba.
No involucrar al equipo de desarrollo
Un design system diseñado sin input del equipo que lo va a implementar está condenado. Los desarrolladores detectan inconsistencias, limitaciones técnicas y oportunidades de reutilización que no son obvias desde Figma.
Nuestro stack para design systems
- Figma — Diseño y prototipado. Variables para tokens.
- Tailwind CSS — Implementación de tokens en código. Clases utilitarias como lenguaje compartido.
- Storybook — Documentación viva de componentes.
- Chromatic — Visual regression testing. Detecta cambios visuales no intencionales.
La regla de oro
Si un componente existe en Figma pero no en código (o viceversa), el sistema está roto. La paridad es todo.
