Diseño de un Design System multimarca, accesible y con una nueva lógica tipográfica

Ese fue el reto del equipo de diseño liderado por Amaya Eguizábal, Digital Assets Design & Development Senior Consultant, que ha trabajado en los últimos meses en el rediseño de un portal del paciente que agrupa distintas marcas bajo una misma base estructural.

Uno de los ejes clave de este proyecto ha sido el diseño de la interfaz de usuario y la creación de un sistema de diseño multimarca: para todas las marcas del grupo, pero con matices visuales específicos según cada identidad.

En este tipo de proyectos, no se trata solo de diseñar pantallas; se trata de rediseñar el pensamiento. De entender cómo un sistema puede ser inclusivo, escalable y, sobre todo, sostenible en el tiempo.

- Amaya Eguizabal, DxP UX Senior Consultant, JAKALA Iberia

Repensar desde cero: accesibilidad, escalabilidad y consistencia

En lugar de adaptar el sistema existente, el equipo optó por reconstruirlo desde cero, con el objetivo de dar respuesta a necesidades actuales y anticiparse al crecimiento futuro del producto. El punto de partida fueron tres preguntas clave:

• ¿Qué pasa si cuestionamos cada convención? 

• ¿Qué sucede si diseñamos un sistema tipográfico que nazca de nuestras propias necesidades, en vez de encajar en moldes ajenos? 

• ¿Y si construimos un lenguaje desde el producto y para el producto? 

Este ejercicio de desaprendizaje, análisis crítico y exploración en equipo permitió revisar cada decisión —desde cómo se nombran los tokens hasta cómo se comportan en cada breakpoint— con un enfoque realista y sostenible. 

Durante el desarrollo del nuevo Design System, el equipo identificó varios puntos de fricción que requerían una revisión profunda del sistema tipográfico: 

• Segmentación rígida entre mobile y desktop 
  La tradicional división por dispositivo resultaba artificial para un producto completamente responsive. Esto trasladaba decisiones de diseño al equipo de desarrollo, complicando la implementación. 

• Nomenclatura estética sin contexto funcional 
  Los estilos tipográficos se nombraban en función de su apariencia visual (como Medium, Bold, 500, 700, etc.), sin reflejar su función dentro de la interfaz. Esta ambigüedad generaba inconsistencias y dificultaba la escalabilidad del sistema. 

• Desconexión entre diseño y desarrollo 
  La organización de los tokens tipográficos en Figma no seguían la misma lógica que el código, lo que obligaba a interpretaciones manuales y generaba incoherencias. 

• Jerarquización basada en tallajes tradicionales (S, M, L) 
  Útil en sistemas pequeños, pero poco flexible para un entorno complejo, con múltiples breakpoints y necesidades específicas de accesibilidad. 

Al analizar estos puntos críticos, el equipo comprendió que no era suficiente con ajustar nombres o mejorar la documentación. Era necesario cuestionar la estructura misma del sistema tipográfico, redefinir sus categorías y construir una lógica más alineada con las necesidades reales del producto y los flujos de trabajo del equipo. 

Desde el inicio del proyecto se definió un doble objetivo claro: 

• Diseñar una estructura de tokens tipográficos completamente nueva, adaptada a un producto flexible, responsive y con requerimientos específicos de accesibilidad y claridad visual. 

• Definir un nuevo sistema de nomenclaturas funcionales y compartidas, alineado con el lenguaje técnico del desarrollo, que permitiera: 

• • Eliminar ambigüedades entre diseño y desarrollo. 

• • Reducir las decisiones interpretativas en cada entrega. 

• • Establecer un lenguaje común que acompañe la evolución del producto sin comprometer su escalabilidad. 

Este enfoque no buscaba innovar por innovar, sino crear una solución que respondiera a las necesidades reales del producto, del equipo y de sus flujos de trabajo. 

En una primera fase, los estilos tipográficos se organizaron por dispositivo (mobile y desktop), pero los nombres seguían una lógica estética. Pronto se evidenció la necesidad de un sistema funcional, coherente con el desarrollo, lo que llevó a una primera iteración del sistema. 

Punto de partida: estructura basada en dispositivos + tallajes + estética

Iteración hacia una nomenclatura más técnica 

En la segunda versión del sistema, el equipo mantuvo la estructura original pero ajustó la nomenclatura de los tokens para alinearla mejor con el lenguaje de desarrollo. Sin embargo, surgieron tres limitaciones importantes: 

• Uso de nomenclatura basada en dispositivos:  términos como mobile y desktop resultaba poco flexible para un entorno con múltiples breakpoints. 

• Jerarquización poco escalable: la nomenclatura basada en tallajes (s, m, l) no ofrecía suficiente escalabilidad. 

• Persistencia de nombres estéticos: pese al esfuerzo por acercarse al lenguaje de desarrollo, los nombres seguían anclados a aspectos estéticos, lo que complicaba su aplicación en un sistema multimarca. 

Primera iteración: nomenclatura más cercana a código

En esta fase, el equipo optó por: 

• Abandonar la clasificación por dispositivo y adoptar una estructura basada en breakpoints, utilizando nomenclaturas comunes en desarrollo como xs, sm, md, lg o xl. La arquitectura del sistema se reorganizó partiendo de la categoría brand (para facilitar la personalización), seguida de font y luego del breakpoint, asegurando así claridad y consistencia. 

• Reestructurar la jerarquía de la tipografía, utilizando una numeración progresiva en lugar de nomenclaturas de tallaje, lo que permitió una mejor escalabilidad. 

• Definir una estructura más clara para las categorías tipográficas, para dejar atrás los nombres estéticos y adoptar una nomenclatura más funcional y alineada con el uso real en el producto. 

Segunda iteración: enfoque basado en “breakpoints” y jerarquización numérica

La estructura final de los tokens fue documentada siguiendo una lógica similar a la de un mapa de arquitectura de la información. Este enfoque permitió jerarquizar y categorizar los estilos de forma clara, escalable y directamente traducible a tokens funcionales. 

La clasificación se construyó en tres niveles: 

1. Colecciones por naturaleza del estilo 
   Se organizaron en tres grandes grupos según su propósito en la interfaz: 

1. 1. Display: para titulares destacados y usos puntuales. 

1. 1. Title: para títulos generales dentro de la interfaz. 

1. 1. Text: para cuerpos de texto y contenido común. 

1. Subgrupos por jerarquía 
   Cada colección contiene subgrupos numerados, donde un número más alto indica mayor relevancia visual dentro de su categoría. 

1. Estilos finales 
   Dentro de cada subgrupo se definen estilos concretos, como Base, que actúa como estilo por defecto dentro de su bloque. 

Variant → Variaciones del estilo base:
↳ Primary → Variante principal.
↳ Secondary → Variante secundaria.

Interactive → Estilos específicos para estados interactivos (botones y enlaces principalmente), clasificados en Primary y Secondary según su relevancia:
↳ Primary → Variante principal.
↳ Secondary → Variante secundaria.

La nueva nomenclatura desarrollada no fue simplemente un cambio de nombres, sino una estrategia clave para permitir la personalización de cada marca sin comprometer la coherencia global del sistema. 

El objetivo era claro: asignar a cada estilo un propósito funcional dentro de la jerarquía visual, alejándose de etiquetas basadas únicamente en la estética (nombres como Medium, Regular, Bold o valores numéricos como 500, 700). Para lograrlo, se trabajó sobre un principio de abstracción: los nombres de los estilos se vincularon a su función, no a su apariencia.  

Esto permitió crear un sistema más flexible, capaz de adaptarse a los cambios visuales o a las necesidades específicas de cada marca, manteniendo al mismo tiempo una estructura común y sólida. 

Ejemplo del antes y el después de la nomenclatura tipográfica

Gracias a esta nueva nomenclatura, el sistema ganó en escalabilidad y control. Cada marca podía conservar su identidad visual sin perder alineación con el conjunto, haciendo que el design system multimarca funcionara como un ecosistema flexible, no como una estructura rígida. 

Como todo sistema vivo, esta solución no se concibe como definitiva. El equipo prevé nuevas iteraciones a medida que el proyecto evolucione, incorporando nuevas categorías o ajustando estilos existentes según las necesidades que puedan surgir. 

Para asegurar una correcta transferencia de los tokens de diseño al entorno de desarrollo, el equipo optó por documentar el sistema en Supernova. Esta elección permitió alcanzar dos objetivos clave: 

1. Centralizar las foundations —tanto las globales (core) como las semánticas— en un entorno agnóstico y accesible para todo el equipo, convirtiéndose en la single source of truth del sistema. 
   
2. Facilitar el trabajo del equipo de desarrollo gracias a la funcionalidad de Code Automation, que permite generar pipelines de exportación personalizados en distintos formatos (CSS, Less, Sass, entre otros).

Ejemplo de repositorio de las foundations globales en Supernova

Ejemplo del “pipeline” de exportación de tokens de Supernova