Sergio Hurtado

01 Proyectos

Murex

Design system

2019–2025 · Mercados financieros · Design system

Construcción de un design system desde cero, para cientos de aplicaciones repartidas en dos bases técnicas que hasta entonces no compartían ningún lenguaje común.

El punto de partida

Cientos de aplicaciones y miles de pantallas convivían sobre dos bases técnicas: un software histórico en Java Swing y nuevas aplicaciones web en Angular. No existía ninguna fuente de verdad común. Cada equipo rehacía sus componentes, los dos mundos se separaban visualmente y el paso del diseño al desarrollo se pagaba en cada proyecto.

Análisis

Realicé 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 pueden hacer igual. Entrevistas con diseñadores, desarrolladores y product managers completaron el cuadro.

  • lo que se reutilizaba realmente de un proyecto a otro;
  • lo que se rehacía por no poder encontrarlo;
  • 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: una decisión de diseño se toma una vez y se resuelve tanto en Swing como en Angular. En Figma eso se convierte en una biblioteca compartida — 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. Es la referencia común de diseñadores y desarrolladores — el punto donde una duda se resuelve sin reunión.

Gobernanza e iteración

Un design system que nadie cuida vuelve pronto a ser una biblioteca muerta. Puse en marcha un proceso de contribución, el versionado de la biblioteca y un changelog. Los patterns más exigentes — tablas de datos densas, 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.