Los design tokens son útiles cuando evitan decisiones duplicadas y mantienen consistencia. Si solo añaden otra capa de complejidad, el sistema se resiente.
Los design tokens prometen conectar diseño y desarrollo con una sola fuente de verdad. Y pueden hacerlo. Pero solo si el sistema está realmente pensado para esa traducción y no se convierte en una capa abstracta imposible de mantener.
Generan valor cuando un mismo criterio tiene que vivirse en varias superficies: Figma, CSS, componentes, documentación y temas de un CMS. Ahí sí evitan duplicidad y mejoran coherencia.
Colores, espaciados, radios, sombras o escalas tipográficas son buenos candidatos, siempre que el naming sea claro y el equipo entienda cómo usarlos.
Se vuelven problemáticos cuando intentan cubrirlo todo o cuando su estructura es tan abstracta que nadie sabe qué token debe tocar para cambiar una decisión concreta.
Otro error común es pensar que por tener tokens ya existe un sistema. Los tokens no sustituyen la dirección visual ni las reglas de uso.
Compensa especialmente en productos que evolucionan, equipos que comparten componentes y proyectos donde diseño y desarrollo necesitan estar mucho más conectados.
Si el sistema es pequeño o muy artesanal, quizá no hace falta montar una maquinaria tan grande.
Un token útil aclara decisiones. Uno malo solo las esconde.
