Sergio Hurtado

06 · Proyectos

Murex

Murex – Design system en dos tecnologías

2019–2025 · Mercados financieros · Design system

La solicitud

En Murex, cientos de aplicaciones y miles de pantallas convivían en dos bases técnicas, Java Swing y Angular, sin una fuente de verdad común. Cada equipo recreaba sus componentes, y el paso del diseño al desarrollo se pagaba en cada proyecto.

La solución

Empecé con una auditoría de interfaz y entrevistas con diseñadores, desarrolladores y product managers. Después construí el design system desde cero, durante cuatro años: atomic design guiado por design tokens independientes de la tecnología, biblioteca de Figma con variables y modos, accesibilidad WCAG en los cimientos, documentación en zeroheight, proceso de contribución y versionado.

Análisis

Empecé por una auditoría de interfaz a gran escala: inventario de componentes, recuento de colores y estilos de texto duplicados, y después un mapa de lo que Swing y Angular saben hacer, y de lo que no hacen igual. Lo completé con entrevistas a diseñadores, desarrolladores y product managers.

  • lo que se reutilizaba realmente de un proyecto a otro;
  • lo que se rehacía porque nadie lo encontraba;
  • las restricciones que cada tecnología impone al diseño.

Diseño

La arquitectura sigue el atomic design, guiada por design tokens independientes de la tecnología: se toma una decisión una vez y se resuelve tanto en Swing como en Angular. En Figma eso da una biblioteca compartida con componentes en auto layout, variants y component properties, y después variables con modos para tema y densidad. La accesibilidad WCAG está en los cimientos, no añadida después.

Design tokensColor, tipografía, espacioBiblioteca FigmaComponentes, patternszeroheightGuidelines documentadasJava SwingSoftware históricoWeb AngularNuevas aplicacionesCientos de aplicaciones, miles de pantallas
Una decisión tomada en los tokens desciende hasta las dos tecnologías, pasando por la biblioteca Figma y la documentación.

El problema real no era dibujar componentes, sino lograr que una misma decisión se sostenga en dos tecnologías que no se parecen en nada.

Documentación

Varias decenas de componentes y patterns están documentados en zeroheight: anatomía, estados, reglas de uso, do and don't y specs de entrega al desarrollo. Se convirtió en la referencia común de diseñadores y desarrolladores, el sitio donde una duda se resuelve sin necesidad de una reunión.

Gobernanza e iteración

Un design system que nadie cuida vuelve pronto a ser una biblioteca muerta. Así que puse en marcha un proceso de contribución, el versionado de la biblioteca y un changelog. Los patterns más exigentes, las tablas de datos densas y los formularios complejos, se retomaron de forma continua a partir de los comentarios de los equipos.

Año 1Auditoría, tokensAño 2ComponentesAño 3Patterns, docAño 4Variables, modos
Cuatro años de construcción: primero los cimientos, después la documentación, y luego las variables y los modos.