Para Schneider Electric
Construimos Zeigo Activate desde cero. En vez de construir un producto, construimos un design system y dejamos que el producto saliera de ahí. Eso es Zeus: unos 45 component sets en Figma, 22 componentes documentados, 8 familias de tokens, mantenidos en Figma y en código al mismo tiempo. Cuando Zeigo HUB llegó dos años después, la mayoría de sus pantallas ya estaban diseñadas.
Lo único que heredamos fue una paleta. 118 valores de color en 9 grupos, nombrados por el único lugar donde se usaba cada uno: dark-gray-410 textbox normal state, dark-gray-510 textbox hover state. La Shared Library todavía la documenta como Original Colors, al lado de lo que la reemplazó.
Un equipo chico, 2 a 3 diseñadores y 4 a 6 front-end engineers, y cada pantalla volviendo a decidir lo básico: qué gris, qué radio, qué espaciado. Dos o tres rondas de review por pantalla en cosas que debían haberse decidido una vez. El camino habitual es construir el producto primero y extraer el sistema después. Así es como llegás a 118 grises.
La decisión fue hacer de los tokens el contrato entre Figma y código, no de los componentes. Tokens semánticos de superficie y texto, background-page, layer-01 a layer-03, text-standard, text-subdued, text-inverse, más tokens de escala para espaciado, tipografía, radio y elevación. Nombrados una vez, publicados como variables de Figma y como CSS custom properties, consumidos por todos los componentes de los dos lados.
Nombrar un sistema de capas para que sobreviva como CSS es un constraint de ingeniería. Prefijo más escala, reglas de orden como layer-02 siempre sobre layer-01. Un diseñador solo se lo pierde, y la paleta se queda en 118 valores nombrados a mano. La jerarquía en sí, la regla de evitar anidamiento profundo, el contraste accesible para pantallas densas de emisiones, eso viene de diseño. Un ingeniero solo entrega una paleta plana y un div con sombra.
Tres productos tenían que salir sobre un solo set de componentes, así que la marca no podía vivir en los componentes. Vivió en tokens y en un solo componente de logo con una variante por producto: Zeigo, Power, Network, Activate, Hub. Eso es lo que hizo posible integrar después HUB y Network sin forkear.
Qué se rompió cuando Zeus pasó de Activate a HUB: el color de marca y el logo por producto, y un puñado de tamaños de card para tablas densas. Exactamente lo que se volvió el componente de logo y los tokens de capa.
Antes de que un componente entrara a Zeus lo prototipaba en código, para exponer los estados que Figma no podía: hover, loading, vacío, error, contenido largo, formatos por locale. Site Card es el ejemplo. Figma tenía dos estados. El prototipo en código, alimentado con datos reales de suppliers, necesitaba combinaciones de created, selected y hover que cambiaban el layout. El set de Figma creció a siete estados a partir de lo que mostró el prototipo, no al revés.
Los reviews con diseño pasaban en Storybook en vez de en Figma, así el review era sobre estados reales. Branches de Figma para cambios de diseño, branches de Git para cambios de código, merge en los dos. La Shared Library lleva un badge Complete o In progress por página, para que nadie consumiera un componente sin terminar por accidente.
Lo que no funcionó: 15 de los 22 componentes documentados siguen en In progress. La documentación quedó atrás del código cuando HUB empezó a tomar el tiempo del equipo. Si lo hiciera de nuevo documentaría al mismo ritmo que codeo. Lo que quedó: Zeus V.2, el set de tokens, la library, el Storybook. Tres productos siguen saliendo sobre eso.
“Working with X has been great. He is reliable and fast. The solutions he designs are creative and empathetic to the end-user experience!”
Exelobaiza | Design Engineer