La mayoría de los equipos piensan que un sistema de diseño es un archivo de Figma y una librería de componentes. Esos son artefactos de un sistema de diseño, no el sistema en sí. El sistema real es el conjunto de decisiones — escala de espaciado, lógica de color, reglas de movimiento, cuándo usar qué patrón — que permiten que un producto se mantenga coherente a medida que más personas, en más equipos, tocan más partes de él.
El modo de falla que vemos con más frecuencia no es una librería de componentes faltante. Son componentes que existen pero cuyas decisiones subyacentes nunca se documentaron, así que cada nuevo colaborador reinventa el razonamiento desde cero, y el sistema se desvía un poco con cada adición.
Lo que construimos para los clientes en cambio es un conjunto pequeño de primitivas con reglas explícitas adjuntas — no solo cómo se ve el botón, sino cuándo usarías un botón versus un enlace de texto versus un CTA magnetizado, y por qué. Los componentes importan menos que las reglas que los generaron, porque las reglas se generalizan a casos que nadie diseñó todavía.
La prueba de un buen sistema de diseño no es si se ve pulido en el archivo. Es si un nuevo ingeniero, seis meses después, puede construir una pantalla que nadie ha diseñado todavía y que se sienta como si perteneciera.