He visto sistemas de diseño impecablemente ordenados fracasar en su primer contacto con el producto. Ocurre cuando tokens, componentes y estados describen una maqueta, pero no las decisiones que el software necesita ejecutar.
En Buy&Sell quise someter la atomización a una prueba concreta: que cada estado visual pudiera corresponderse con permisos, datos y ciclos de vida reales.
Diseñar contratos, no catálogos
El componente útil no es el que acumula variantes. Es el que expresa un contrato comprensible: qué recibe, qué devuelve, qué estados admite y qué parte puede cambiar sin romper el conjunto.
Figma ayuda a explorar y alinear. El código obliga a precisar. Cuando ambos divergen, no basta con corregir píxeles: hay que revisar el modelo compartido.
El traspaso es una conversación
La documentación no sustituye el trabajo entre diseño y desarrollo. Un sistema resistente incorpora decisiones, ejemplos y límites, pero también un proceso para negociar excepciones.
La fidelidad importante no consiste en que dos capturas coincidan. Consiste en conservar intención, jerarquía y comportamiento cuando el producto recibe datos reales.
Recorrer el sistema de Figma a Angular