01 · Sistema de diseño · Producto B2B para bancos
Tres cambios de sistema sin rehacer una sola pantalla.
Cuatro años de un sistema de diseño en un producto en desarrollo continuo: de archivos duplicados a una librería compartida, de una librería propia a una estándar, y de Figma a prototipos en código. La parte difícil nunca fue armarlo. Fue cambiarlo sin frenar a nadie.
El punto de partida
Cuando entré, el diseño vivía en archivos de Adobe XD que se duplicaban y se pasaban entre diseñadores. Éramos tres. El problema no era la herramienta: era que el estado real del diseño no existía en ningún lado. Cada uno trabajaba sobre una copia que ya estaba vieja, y la única forma de saber cómo era un componente era preguntarle a quien lo había tocado último.
En un producto que se implementa con la marca de cada cliente, eso no escala. Cada inconsistencia que entra en un prototipo se multiplica después por cada implementación.
Primer cambio: una fuente compartida
Propuse pasar a Figma. No estaba en los planes y no lo usaba nadie en el equipo, así que la propuesta incluía hacerme cargo de la migración.
Repliqué el sistema que existía en XD componente por componente, con auto layout y variantes, y después variables y tokens. No fue una copia: lo rearmé a nivel atómico, de forma que un componente se pudiera adaptar a casi cualquier pantalla sin romperlo ni duplicarlo. Con el tiempo lo expandí hasta más que duplicar el inventario original.
A los quince días ya había componentes usables en los prototipos que estaban en curso, y al mes el sistema estaba razonablemente terminado, trabajando en paralelo con otros proyectos. Eso fue deliberado: un sistema que exige que todos paren hasta que esté listo no se adopta.
Lo que cambió no fue la herramienta. Fue que un cambio dejó de ser una conversación y pasó a ser un commit.
Estandarizar organismos aceleró el maquetado y el prototipado, pero el resultado real fue otro: un cambio atómico en un componente impacta en todos los prototipos, de todos los módulos, de todos los diseñadores. Los prototipos dejaron de envejecer.
Cuatro años manteniéndolo
La parte del trabajo que no se ve es esta. El sistema se fue expandiendo cada vez que el producto sumaba algo nuevo, y se fue actualizando a medida que la herramienta incorporaba capacidades: auto layout, variables, variantes, grid.
La regla que me impuse fue que ninguna actualización podía obligar a rehacer pantallas. Cada vez que cambiaba algo estructural, lo resolvía para que el impacto quedara contenido: en algunos casos hubo que reemplazar componentes, pero el objetivo siempre fue que eso fuera la excepción y no el costo normal de mantener el sistema al día.
Un sistema que cada seis meses obliga al equipo a migrar pantallas no es un sistema: es una deuda con mejor presentación.
Segundo cambio: resignar identidad para ganar entrega
A los cuatro años el equipo de front seguía sin tener un toolkit propio. Veníamos de una librería personalizada a la marca, y esa personalización era parte del costo: mientras el diseño exigiera componentes hechos a medida, armar el toolkit seguía siendo un proyecto que nunca empezaba.
La decisión fue bajar el nivel de personalización a propósito y pasar a una librería estándar, con la adaptación de marca resuelta por color en lugar de por componente. Diseño resignó identidad visual; desarrollo ganó la posibilidad de tomar la librería casi tal cual.
Funcionó: tres meses después el toolkit existía. Es la decisión de la que menos me enorgullezco estéticamente y la que más sirvió.
Tercer cambio: el sistema fuera de Figma
Con la IA metida en el flujo, el prototipado se movió al código: hoy se prototipa en HTML, con resultados muy cercanos a lo que el usuario ve al final. El riesgo era obvio: si lo que genera la IA no sale del sistema, en seis meses tenés una cuarta versión del sistema conviviendo con las otras tres.
Para evitarlo, armamos con el líder de diseño el sistema como skill, de modo que la IA trabajara sobre él.
El problema apareció después. La herramienta de diseño sí tenía conexión directa con sistemas de diseño, pero el entorno de código no, y era el entorno de código el que servía para prototipar en serio. Con la IA adapté el skill y escribí un comando que sincroniza los tokens del toolkit que usa desarrollo, de modo que se pudiera prototipar directamente en código sin pasar por el otro entorno.
El resultado
El sistema sobrevivió a tres cambios de contexto (de herramienta, de librería y de medio de prototipado) sin que el equipo tuviera que parar a rehacer trabajo existente. Los prototipos se mantienen actualizados solos, la marca de cada cliente se resuelve por configuración y no por rediseño, y lo que prototipa la IA sale del mismo sistema que usa desarrollo.
Lo que todavía no cerró
La sincronización de tokens entre el toolkit de desarrollo y el entorno de diseño sigue siendo manual: un comando que alguien tiene que correr. Funciona, pero depende de que alguien se acuerde, y un sistema que depende de que alguien se acuerde tiene fecha de vencimiento.
Hay una parte que ya se resolvió sola: las herramientas incorporaron nativamente buena parte de lo que yo había tenido que puentear. Es el destino razonable de cualquier workaround y no me parece una pérdida; el puente existió mientras hizo falta, y lo que queda es el criterio de haber decidido que el sistema tenía que estar donde se prototipa.
En la primera migración di por hecho que una herramienta mejor se adopta sola. No se adoptó: hubo demoras que no eran de la herramienta sino de que nadie sabía usarla, y las resolví recién cuando armé una capacitación corta y me puse disponible para las dudas. Desde entonces, cuando propongo un cambio de herramienta, el plan de adopción es parte de la propuesta y no algo que se arregla después.