Lo que aprendí construyendo mi primer sistema de diseño
Contenidos
Cuando me propusieron construir el sistema de diseño para el equipo, pensé que el trabajo era ordenar componentes en Figma. Poner los botones en un lugar, los colores en otro, agregar algunos ejemplos de uso. Tres semanas, listo.
Cuatro meses después, seguía trabajando en él.
Lo que subestimé
El inventario inicial es brutal. Antes de diseñar un solo componente nuevo, tuve que mapear todo lo que ya existía en producción. 47 variantes de botón. 11 colores de texto distintos que en realidad eran 4 intentando ser consistentes. Íconos de tres librerías diferentes mezclados sin criterio.
Ese trabajo de auditoría es aburrido y necesario. Y si te lo saltas, construyes un sistema encima de inconsistencias que ya existen.
Los tokens importan más que los componentes. Me enfoqué primero en los componentes y tuve que rehacerlo todo cuando definimos los tokens. Un sistema sin tokens es solo una librería de componentes — útil, pero frágil. Cada color hard-codeado es una deuda futura.
La documentación no es opcional. Construí componentes hermosos que nadie usó porque no entendían cuándo usarlos. La documentación no es la parte bonita del sistema — es la mitad del trabajo.
Lo que sí funcionó
Empezar por los componentes que más se repiten y tienen más variantes incorrectas en producción. Ahí es donde más duele la inconsistencia y donde más se nota el cambio rápido.
También: involucrar a los devs desde el principio. No para que validen — para que co-construyan. Un sistema de diseño que solo vive en Figma no es un sistema de diseño.
El aprendizaje más grande
Un sistema de diseño no es un proyecto con fecha de entrega. Es un producto interno que necesita mantenimiento, actualización y adopción continua. Si no hay alguien encargada de mantenerlo vivo, muere.
No importa qué tan bien esté construido.