Racionalització Radical a Western Union
De 146 a 10 components. Un sistema. 40 mercats. Experiència consistent entre marques, plataformes i regions.
Repte
Empresa global de serveis financers amb ~40 mercats executant propietats web, app i POS de retail desconnectades. El design system havia crescut orgànicament fins a 146 components inconnexos. Cada release requeria reconciliació manual entre regions.
Solució
Auditoria exhaustiva dels 146 components a tots els productes. Identificació dels 10 generadors atòmics que poden produir tota la resta. Disseny del model de governança federada per a 40 mercats. Implementació de l'arquitectura de tokens W3C DTCG. Lideratge del canvi cultural.
Arquitectura
Arquitectura de tokens de 3 nivells (referència, sistema, component). Pipeline Style Dictionary. Figma Variables sincronitzades via API. Governança federada amb auditoria trimestral.
Tecnologies
- Style Dictionary
- W3C DTCG
- Figma Variables
- React
- TypeScript
- Theming multi-marca
Els números
40 mercats unificats sota un sol sistema. 146 components consolidats a 10 generadors atòmics, una reducció del 93%. Arquitectura de tokens de 3 nivells (referència, sistema, component). Una font de la veritat per a web, app i retail POS.
El repte
Western Union opera en uns 40 mercats amb propietats web, app mòbil i punts de venda retail. Durant una dècada, el design system va créixer orgànicament fins a 146 components desconnectats. Cada mercat mantenia els seus propis forks. Cada producte tenia el seu propi tema. Els enginyers copiaven i divergien quan el sistema no els servia. Cada release requeria reconciliació manual entre regions, un impost que s’acumulava amb cada nou mercat i cada cicle trimestral.
El problema no era mal disseny. El problema era que no hi havia arquitectura. Els components s’havien construït de baix a dalt, un a un, en resposta a necessitats immediates. Ningú havia dibuixat mai el graf de dependències.
Descobriment: L’inventari
El primer artefacte que vaig produir no va ser un roadmap. Va ser un inventari.
Vaig catalogar els 146 components a mà durant tres setmanes: cada fork, cada divergència, cada override silenciós que un equip local havia introduït sense documentació. Vaig dibuixar el graf de dependències en una paret. El que va emergir no era caos. Era un patró.
El 93% de les variacions es podia rastrejar fins a 10 generadors atòmics. El 7% restant era soroll: components morts, experiments aïllats, prototips abandonats que ningú havia esborrat.
Deixa de pensar en components. Comença a pensar en generadors. Un component és el que veus. Un generador és el que el produeix. Consolida a la capa del generador i els components col·lapsen sols.
El concepte de generador és el que fa possible la reducció de 146 a 10 sense perdre expressivitat. Un generador és una primitiva paramètrica: un conjunt de restriccions (espaiat, color, tipografia, interacció) que pot produir una família de components. Un generador de botó produeix botons primaris, secundaris, ghost, amb icona, en càrrega. Tots són el mateix amb diferent configuració.
Estratègia: Tokens primer, components després
L’enfocament convencional hauria estat redissenyar la biblioteca de components. Vam fer el contrari.
Vam unificar la capa de tokens primer, començant per color i espaiat. Després tipografia. Després l’escala de moviment. Només quan la capa de tokens va ser estable vam tocar els components.
Arquitectura de tokens (W3C DTCG)
Tokens de referència són valors crus de paleta. Groc de marca, escala de grisos, escala de blaus. Són agnòstics de plataforma i mai els consumeixen els components directament.
Tokens de sistema són àlies semàntics. surface.primary, text.secondary, border.default. Són el que els components realment consumeixen. Porten intenció, no valors de color.
Tokens de component són overrides específics. button.primary.background, field.border.focus. Són escassos per disseny. La majoria de components hereten tot de la capa de sistema.
El dark mode no és una funcionalitat construïda dins dels components. És una qüestió de configuració: un fitxer JSON que remapeja surface.primary de blanc a grey.95, text.primary de negre a blanc. El codi del component és idèntic en ambdós modes.
Per què importa aquest ordre
La majoria d’equips comencen pels components perquè són visibles. Però un redisseny de botó sense arquitectura de tokens a sota és un canvi cosmètic. Començar per tokens és més difícil d’explicar, més lent de mostrar progrés, i políticament ingrat. Però significa que cada component que construeixes a sobre hereta l’arquitectura gratis.
Governança: Federada, no central
Quaranta mercats significa quaranta equips locals, cadascun amb propietat regional, restriccions legals i timelines de producte. Un comitè centralitzat hauria estat rebutjat en un trimestre.
Vam construir un model federat:
L’equip core posseeix els generadors i l’arquitectura de tokens.
Els equips locals posseeixen els seus temes de mercat i poden proposar extensions.
Les propostes pugen, les reviews baixen. Els equips locals envien propostes. L’equip core revisa la consistència arquitectònica.
Auditories trimestrals mantenen el loop honest. La desviació de cada mercat es mesura i es justifica o es reconcilia.
Els design systems són polítics abans que tècnics. El framework ha de ser adoptat, no imposat. Si un equip local sent propietat, manté la qualitat. Si sent control, forkeja.
El canvi cultural va ser més difícil que el tècnic. L’estratègia d’adopció es va basar en demostració, no en mandat: triar un mercat, consolidar-lo a la nova arquitectura, mesurar els resultats, i deixar que aquests resultats fessin la feina de venda.
El pipeline de build
Format W3C DTCG com a font de la veritat. Tots els tokens viuen en fitxers JSON amb estructura estàndard de la indústria.
Style Dictionary transforma aquests JSON en cada output de plataforma: CSS custom properties per a web, variables SCSS per a superfícies legacy, constants TypeScript per a React, valors Swift per a iOS, Kotlin per a Android.
Figma Variables sincronitzades via API. Els dissenyadors treballen amb els mateixos tokens que els enginyers consumeixen.
El framework: Racionalització Radical
Pas 1: Inventari. Cataloga tot. Cada fork, cada override, cada divergència silenciosa. No pots racionalitzar el que no has mesurat.
Pas 2: Troba els generadors. Darrere la variació hi ha patrons. Identifica els productors atòmics que generen tot el rang de variació que necessites.
Pas 3: Consolida a la capa de tokens. No redissenyes components. Redissenyes les decisions a sota d’ells.
Pas 4: Federa la governança. Propietat central de l’arquitectura. Propietat distribuïda de l’expressió.
Pas 5: Audita trimestralment. Els sistemes deriven. El mesurament prevé l’entropia.
La majoria del bloat de design systems no és un problema de components. És un problema d’arquitectura de decisions. Arregla les decisions i els components s’arreglen sols.
Resultats clau
Reducció del 93%: de 146 components desconnectats a 10 generadors atòmics.
Una font de la veritat de tokens consumida per web, mòbil i retail als 40 mercats.
Dark mode aconseguit mitjançant configuració de tokens, no reescriptura de components.
40 mercats operant sota governança federada amb cadència trimestral d’auditoria.
Pipeline de build que genera outputs específics per plataforma des d’un sol JSON.
El que vaig aprendre
Sobre arquitectura: La capa de tokens és el producte real. Els components són només l’expressió visible.
Sobre governança: El federat guanya al centralitzat sempre a escala. La governança central funciona fins que el segon equip discrepa. La federada funciona perquè el desacord està incorporat en el procés.
Sobre adopció: Demostra, no manes. Un mercat migrat amb resultats mesurables convenç més que cent presentacions.
Sobre mesurament: Si no mesures la desviació, no pots prevenir l’entropia. Els sistemes no es mantenen consistents per defecte. Es mantenen consistents perquè algú comprova.