He pasado los últimos años construyendo, rompiendo y reconstruyendo sistemas de diseño en Amazon, Western Union y startups. Y si hay una lección que se repite como un loop de error en consola, es esta:
Nos obsesionamos con la superficie y ignoramos la estructura que la sostiene.
No hablo de componentes, ni de tokens, ni de documentación. Hablo de la arquitectura real: la que define cómo se toman decisiones, quién tiene voz, y qué pasa cuando el sistema choca con la realidad del producto.
El mito del "sistema perfecto"
En mi artículo "The Day Our Perfect Prototype Started Lying to Us", conté cómo un prototipo impecable — con interacciones fluidas, estados definidos y lógica aparentemente sólida — se desmoronó en producción porque nadie había cuestionado la API subyacente .El problema no estaba en Figma. Estaba en la brecha entre la ilusión de control del diseño y la complejidad real del sistema.
Eso mismo pasa con los Design Systems.
Creamos bibliotecas hermosas, con variantes para cada caso de uso... pero no diseñamos el protocolo de evolución. No definimos cómo se resuelve un conflicto cuando un equipo necesita algo que el sistema no contempla. No establecemos quién puede romper las reglas... y cuándo.
La verdadera escalabilidad no es técnica. Es política.
Un Design System no escala por tener más componentes. Escala por tener mecanismos claros para la toma de decisiones.- ¿Quién decide que un token cambia de valor?
- ¿Qué pasa cuando un equipo necesita un patrón que contradice el sistema?
¿Cómo se resuelve un trade-off* entre consistencia y innovación?
Estas no son preguntas de diseño. Son preguntas de gobernanza. Y la mayoría de los sistemas las ignoran hasta que es demasiado tarde.
En "Haikus y Tokens", escribí que "los Design Tokens son decisiones de diseño que se propagan a través de un sistema" . Pero nunca dije la parte más incómoda: las decisiones mal gobernadas se propagan como bugs.
Yo también creí que con buenos componentes bastaba... hasta que mi sistema fue ignorado por 3 equipos.
El test de fuego: el primer fork
Todo sistema sano sobrevive su primer fork.El momento en que un equipo, frustrado por la burocracia o la rigidez, decide crear su propia versión del sistema.
Muchos lo ven como una traición. Yo lo veo como una señal.
Porque si tu sistema no permite evolución descentralizada, no es un sistema. Es una cárcel.
La verdadera prueba no es si todos usan tu biblioteca. Es si, cuando alguien la rompe, el sistema aprende en lugar de castigar.
Entonces, ¿qué hacer?
Deja de pensar en tu Design System como un producto.Piénsalo como una infraestructura de coordinación.
- Define reglas claras, pero no rígidas.
Documenta no solo qué hacer, sino cómo decidir*.
- Haz visible el proceso de cambio, no solo el resultado.
Celebra los forks* que aportan valor, no solo la obediencia ciega.
La ironía final
Los mejores Design Systems no son los más usados.Son los que desaparecen.
No porque sean invisibles, sino porque su arquitectura es tan sólida que nadie tiene que pensar en ellas. El equipo se enfoca en resolver problemas reales, no en luchar contra el sistema.
Eso no se logra con más documentación.
Se logra con menos ego y más estructura.
Joan Arbó
UX Engineer @ Western Union | Ex-Amazon Alexa
¿Tu equipo ya hizo un fork de tu Design System? No lo castigues. Pregúntate: ¿qué feedback me está dando?
P.D.: Si tu Design System tiene un "owner" pero no un "protocolo de desacuerdo", ya está roto. Solo falta que alguien lo diga en voz alta.