MOB: del sistema de diseño a la fuente de verdad

Construí MOB sin que nadie lo pidiera, con un desarrollador frontend, y pasé meses evangelizando equipos que no creían que hiciera falta. Cinco años después era el estándar oficial de la compañía.

Y entonces apareció el pedido que hace interesante a este caso. Dirección quería modernizar por completo el lenguaje visual de la plataforma. En paralelo, desarrollo estaba reconstruyendo el producto entero sobre una librería de componentes, un trabajo que no podía ni debía frenarse.

Dos pedidos legítimos que, en el tiempo, se contradecían: cada sprint construido sin previsión de cambio visual sumaba costo futuro de retrabajo.

Y el sistema tenía tres representaciones que habían evolucionado por separado: la documentación de diseño, la implementación real y la herramienta de prototipado decían cosas distintas.

Antes de dibujar la estética nueva hice una apuesta estructural: codificar el sistema que ya existía —el viejo, el que estaba por reemplazarse— en una herramienta de prototipado. Reglas de comportamiento, filosofía de diseño, layouts, patrones de composición, mapeo componente a componente.

No un inventario de piezas: el criterio detrás de las piezas, escrito de forma que una máquina pudiera aplicarlo.

Lo validé usándolo. Prototipé con la herramienta durante semanas y la fui corrigiendo con lo que aparecía al usarla: cada vez que una pantalla real revelaba una regla mal escrita, la regla se arreglaba en la fuente, no en la pantalla.

Recién cuando la herramienta fue consistente, y con la dirección visual ya definida, reemplacé los componentes por los de la librería nueva. Los layouts y los patrones no se tocaron.

Ese orden es lo que resolvió la contradicción del encargo. Como los layouts y los patrones eran independientes de la librería, los prototipos que el equipo ya tenía seguían siendo especificaciones válidas: las mismas pantallas, los mismos comportamientos, cambiando solo los componentes.

La auditoría previa confirmó el tamaño de la apuesta. El acoplamiento real con la librería vieja estaba concentrado en tres lugares. Las 990 líneas de especificación de comportamiento tenían apenas dos referencias a la paleta, y siete organismos se mantuvieron uno a uno sin tocar nada. La capa cara de rehacer salía intacta.

Con el lenguaje visual separado de su implementación apareció una decisión que no era técnica sino de rol.

La tentación era pedir la migración a la librería nueva: tenía el argumento armado y la exploración visual funcionaba. En lugar de eso entregué el lenguaje en un formato que cualquier stack puede implementar, y le devolví la decisión al equipo de front con un mecanismo para tomarla con datos. Un spike acotado donde un desarrollador reconstruye una o dos pantallas con el tema generado y se mide cuánto de la estética sale con puro theming.

El criterio quedó escrito de antemano, con un umbral numérico y tres caminos posibles según el resultado. En los tres, los tokens y la especificación son la misma inversión: no se tira nada. Lo único que pedí para el corto plazo fueron dos reglas de higiene de costo casi nulo: que todo estilo salga del tema y que se consuma una capa propia en vez de la librería directa.

El camino terminó decidiéndose por los hechos. Hoy existe una librería de 62 componentes en la estética nueva, viviendo en el repositorio de desarrollo con su propio Storybook y 196 casos de uso documentados. Crece con cada desarrollo que avanza, y los tokens están alineados byte a byte con ese repositorio.

La librería nueva trae once roles de color y nada más: no cubre estados semánticos, ni series de gráficos, ni acentos por módulo. En vez de diseñar tres subsistemas separados los unifiqué en uno, con diez series donde los estados son alias, no colores nuevos. Consecuencia: el rojo de un tag de error y el rojo de una serie de gráfico son el mismo token y no pueden divergir con el tiempo.

Toda la escala neutra deriva del hue del color de marca con chroma baja: cambiar la marca es cambiar una línea y los grises se recalculan solos.

Las reglas salieron de probar, no de un manual. La luminosidad no se toca al tibiar, así el contraste queda intacto. Y el tope es el siete por ciento, porque al diez el gris chocaba con el estado activo.

Dos hallazgos que solo aparecen en una pantalla real. El fondo, el hover y el contenedor caían dentro de 0,004 de luminosidad: el hover de los botones fantasma se fundía con el fondo, y se resolvió empujando el fondo por encima del hover. Y los labels de formulario en monoespaciada se sentían recargados, así que la mono quedó reservada a overline, caption y micro-texto.

El activo más reutilizable no fueron las pantallas: fue la capa. El sistema dejó de ser documentación que alguien consulta y pasó a ser la fuente que consume el equipo de ingeniería —incluidos los agentes de IA con los que están reconstruyendo la plataforma— y se actualiza con cada decisión que se toma.

Y no viajaron solo los componentes. En ese Storybook, al lado de los 62 componentes, hay páginas de filosofía, convenciones, fundamentos y movimiento.

El equipo de producto lo usa sin mí: mi reporte directo, la Directora de Producto, arma artefactos para demos comerciales apoyada en la herramienta, sin pasar por diseño. Y todo lo que la compañía construye hoy sale de la misma librería y los mismos tokens: la reconstrucción del CRM y los dos productos nuevos que avanzan en paralelo.

También cambió la escala de tiempo del prototipado. En uno de los productos nuevos adapté el prototipo de escritorio a iOS y Android en un par de horas, con una auditoría de veinticuatro hallazgos contra las guías de plataforma —priorizados, resueltos y cerrados— y después a webapp en quince minutos.

Y se mantiene solo: cada corrección que aparece diseñando entra por un buzón y se aplica a la fuente con historial versionado. Diez consolidaciones documentadas hasta hoy. Nada se pierde en una conversación.

Lo que me llevo. Separar las reglas de las piezas antes de tocar la estética hizo que el rediseño dejara de ser una apuesta y pasara a ser el reemplazo de una capa. Y devolverle la decisión técnica al equipo de front convirtió una discusión de gustos en un experimento medible.