Racionalización Radical en Western Union
De 146 a 10 componentes. Un sistema. 40 mercados. Experiencia consistente entre marcas, plataformas y regiones.
Reto
Compañía global de servicios financieros con ~40 mercados ejecutando propiedades web, app y POS de retail desconectadas. El design system había crecido orgánicamente hasta 146 componentes inconexos. Cada release requería reconciliación manual entre regiones.
Solución
Auditoría exhaustiva de los 146 componentes en todos los productos. Identificación de los 10 generadores atómicos que pueden producir todo lo demás. Diseño del modelo de gobernanza federada para 40 mercados. Implementación de arquitectura de tokens W3C DTCG. Liderazgo del cambio cultural.
Arquitectura
Arquitectura de tokens de 3 niveles (referencia, sistema, componente). Pipeline Style Dictionary. Figma Variables sincronizadas vía API. Gobernanza federada con auditoría trimestral.
Tecnologías
- Style Dictionary
- W3C DTCG
- Figma Variables
- React
- TypeScript
- Theming multi-marca
Los números
40 mercados unificados bajo un solo sistema. 146 componentes consolidados a 10 generadores atómicos, una reducción del 93%. Arquitectura de tokens de 3 niveles (referencia, sistema, componente). Una fuente de la verdad para web, app y retail POS.
El reto
Western Union opera en unos 40 mercados con propiedades web, app móvil y puntos de venta retail. Durante una década, el design system creció orgánicamente hasta 146 componentes desconectados. Cada mercado mantenía sus propios forks. Cada producto tenía su propio tema. Los ingenieros copiaban y divergían cuando el sistema no les servía. Cada release requería reconciliación manual entre regiones, un impuesto que se acumulaba con cada nuevo mercado y cada ciclo trimestral.
El problema no era mal diseño. El problema era que no había arquitectura. Los componentes se habían construido de abajo arriba, uno a uno, en respuesta a necesidades inmediatas. Nadie había dibujado nunca el grafo de dependencias.
Descubrimiento: El inventario
El primer artefacto que produje no fue un roadmap. Fue un inventario.
Catalogué los 146 componentes a mano durante tres semanas: cada fork, cada divergencia, cada override silencioso que un equipo local había introducido sin documentación. Dibujé el grafo de dependencias en una pared. Lo que emergió no era caos. Era un patrón.
El 93% de las variaciones podía rastrearse hasta 10 generadores atómicos. El 7% restante era ruido: componentes muertos, experimentos aislados, prototipos abandonados que nadie había borrado.
Deja de pensar en componentes. Empieza a pensar en generadores. Un componente es lo que ves. Un generador es lo que lo produce. Consolida en la capa del generador y los componentes colapsan solos.
El concepto de generador es lo que hace posible la reducción de 146 a 10 sin perder expresividad. Un generador es una primitiva paramétrica: un conjunto de restricciones (espaciado, color, tipografía, interacción) que puede producir una familia de componentes. Un generador de botón, por ejemplo, produce botones primarios, secundarios, ghost, con icono, en carga. Todos son lo mismo con diferente configuración. Nunca fueron componentes separados. Eran instancias separadas de una misma decisión.
Estrategia: Tokens primero, componentes después
El enfoque convencional habría sido rediseñar la librería de componentes. Hicimos lo contrario.
Unificamos la capa de tokens primero, empezando por color y espaciado. Luego tipografía. Luego la escala de movimiento. Solo cuando la capa de tokens fue estable tocamos los componentes. Para entonces, la mayoría de las decisiones ya se habían tomado un nivel más abajo.
Arquitectura de tokens (W3C DTCG)
Tokens de referencia son valores crudos de paleta. Amarillo de marca, escala de grises, escala de azules. Son agnósticos de plataforma y nunca los consumen los componentes directamente.
Tokens de sistema son alias semánticos. surface.primary, text.secondary, border.default. Son lo que los componentes realmente consumen. Llevan intención, no valores de color.
Tokens de componente son overrides específicos. button.primary.background, field.border.focus. Son escasos por diseño. La mayoría de componentes heredan todo de la capa de sistema.
El dark mode no es una funcionalidad construida dentro de los componentes. Es una cuestión de configuración: un archivo JSON que remapea surface.primary de blanco a grey.95, text.primary de negro a blanco. El código del componente es idéntico en ambos modos. Sin lógica condicional, sin flags isDarkMode, sin bloques de estilo duplicados. El mismo principio aplica a multi-marca: una nueva marca es un nuevo archivo de override de tokens, no una nueva librería de componentes.
Por qué importa este orden
La mayoría de equipos empiezan por los componentes porque son visibles. Puedes enseñar un botón rediseñado en una sprint review. Pero un rediseño de botón sin arquitectura de tokens debajo es un cambio cosmético. La próxima vez que alguien necesite una nueva marca o un nuevo tema, forkea el botón de nuevo.
Empezar por tokens es más difícil de explicar, más lento de mostrar progreso, y políticamente ingrato. Pero significa que cada componente que construyes encima hereda la arquitectura gratis.
Gobernanza: Federada, no central
Cuarenta mercados significa cuarenta equipos locales, cada uno con propiedad regional, restricciones legales y timelines de producto. Un comité centralizado habría sido rechazado en un trimestre.
En su lugar, construimos un modelo federado:
El equipo core posee los generadores y la arquitectura de tokens. Cualquier cambio pasa por el equipo core.
Los equipos locales poseen sus temas de mercado y pueden proponer extensiones. Un mercado que necesita un componente regulatorio específico no pide permiso. Lo construye localmente siguiendo la arquitectura de tokens.
Las propuestas suben, las reviews bajan. Los equipos locales envían propuestas. El equipo core revisa la consistencia arquitectónica.
Auditorías trimestrales mantienen el loop honesto. La desviación de cada mercado respecto al core se mide y se justifica o se reconcilia.
Los design systems son políticos antes que técnicos. El framework tiene que ser adoptado, no impuesto. Si un equipo local siente propiedad, mantiene la calidad. Si siente control, forkea.
El cambio cultural fue más difícil que el técnico. La estrategia de adopción se basó en demostración, no en mandato: elegir un mercado, consolidarlo a la nueva arquitectura, medir los resultados, y dejar que esos resultados hicieran el trabajo de venta.
El pipeline de build
Formato W3C DTCG como fuente de la verdad. Todos los tokens viven en archivos JSON con estructura estándar de la industria.
Style Dictionary transforma esos JSON en cada output de plataforma: CSS custom properties para web, variables SCSS para superficies legacy, constantes TypeScript para React, valores Swift para iOS, Kotlin para Android. Una fuente, múltiples salidas.
Figma Variables sincronizadas vía API. Los diseñadores trabajan con los mismos tokens que los ingenieros consumen. No hay paso de traducción.
El framework: Racionalización Radical
Este trabajo cristalizó en un framework repetible:
Paso 1: Inventario. Cataloga todo. Cada fork, cada override, cada divergencia silenciosa. No puedes racionalizar lo que no has medido.
Paso 2: Encuentra los generadores. Detrás de la variación hay patrones. Identifica los productores atómicos que, con los parámetros correctos, generan todo el rango de variación que necesitas.
Paso 3: Consolida en la capa de tokens. No rediseñes componentes. Rediseña las decisiones debajo de ellos.
Paso 4: Federa la gobernanza. Propiedad central de la arquitectura. Propiedad distribuida de la expresión.
Paso 5: Audita trimestralmente. Los sistemas derivan. La medición previene la entropía.
La mayoría del bloat de design systems no es un problema de componentes. Es un problema de arquitectura de decisiones. Arregla las decisiones y los componentes se arreglan solos.
Resultados clave
Reducción del 93%: de 146 componentes desconectados a 10 generadores atómicos.
Una fuente de la verdad de tokens consumida por web, móvil y retail en los 40 mercados.
Dark mode logrado mediante configuración de tokens, no reescritura de componentes.
40 mercados operando bajo gobernanza federada con cadencia trimestral de auditoría.
Pipeline de build que genera outputs específicos por plataforma (CSS, SCSS, TypeScript, Swift, Kotlin) desde un solo JSON.
Lo que aprendí
Sobre arquitectura: La capa de tokens es el producto real. Los componentes son solo la expresión visible. Si aciertas con los tokens, los componentes casi se construyen solos.
Sobre gobernanza: Lo federado gana a lo centralizado siempre a escala. La gobernanza central funciona hasta que el segundo equipo discrepa. La federada funciona porque el desacuerdo está incorporado en el proceso.
Sobre adopción: Demuestra, no mandes. Un mercado migrado con resultados medibles convence más que cien presentaciones.
Sobre medición: Si no mides la desviación, no puedes prevenir la entropía. Los sistemas no se mantienen consistentes por defecto. Se mantienen consistentes porque alguien comprueba.