Diseñado, desarrollado y en producción. En solitario.
MDDS. Memoria Digital Design System. Ahora con más de 110 instancias en producción, una cuarta parte implementadas por otros devs.
Tres generaciones de iconos, componentes sin dirección. Cero sistema.
MDDS es el design system que construí para el producto de Archivo y Preservación de ODILO. Antes de esto, cada pantalla definía sus propios botones, avisos e iconos: tres generaciones de iconografía conviviendo, colores escritos a mano en cada hoja de estilos, sin un lenguaje visual compartido entre módulos. MDDS reemplaza eso por una capa de tokens, componentes reutilizables y una librería de iconos unificada, hoy en producción.
Pero el cambio más importante no se ve en una pantalla: es una nueva forma de trabajar. Con cimientos sólidos, cada decisión de diseño deja de resolverse pantalla a pantalla y empieza a resolverse una vez, en la capa correcta. Eso nos permite ir atando el producto con más consistencia para nuestros clientes, sin repetir el mismo trabajo en cada módulo.
Tokens primero, pantallas después
El orden importa tanto como el resultado. En vez de crear componentes y ajustarlos después a un sistema de tokens, seguí la secuencia inversa: tokens primero, componente después, documentación en paralelo, migración al final.
Por qué ese orden.
Crear un componente antes de tener tokens obliga a reescribirlo en cuanto cambia el sistema de color o tipografía. Empezar por los tokens fuerza a resolver antes las preguntas difíciles: qué es primitivo, qué es semántico, qué depende del contexto de uso. Eso hace que el componente nazca consumiendo variables, no valores sueltos.
El puente entre Figma y código.
Una parte del trabajo que no se ve en ninguna pantalla fue conectar el nombre de cada token en Figma con su equivalente en CSS, para que dejaran de mantenerse a mano en dos sitios distintos. Lo que se decide en diseño llega a código con el mismo nombre, sin traducción manual ni margen de error entre herramientas.
Cómo pensé cada componente.
No diseñé pantallas, diseñé piezas que el resto del equipo pudiera usar sin pedirme ayuda. Eso significó accesibilidad y soporte a los seis idiomas de la aplicación integrados desde el primer commit de cada componente, no añadidos después como parche. Y significó documentar cada variante en un playground interno, la referencia de trabajo del equipo hoy, evolucionando hacia un producto interno compartible a medida que crece el set de componentes.
De Figma a producción, sin traducción manual
El pipeline extrae las variables de Figma y las procesa para generar automáticamente las tres capas de tokens en CSS. Lo que Figma no resuelve bien (casos de borde, ajustes finos) se gestiona directamente en código, sin forzar la herramienta de diseño a hacer algo para lo que no está pensada.
Cuatro componentes construidos desde cero con variantes, estados y accesibilidad resueltos dentro del propio componente, no como capa añadida. Una librería de más de 190 iconos unificada en una sola fuente tipográfica, reemplazando tres generaciones distintas de iconografía. En producción, usado por clientes de sector privado y público con requisitos altos de accesibilidad.
Documentación como sesión de trabajo
El playground no es documentación escrita después del hecho. Se construye en pairing continuo con el ingeniero frontend senior de la empresa (y mentor): qué variantes necesita un componente, cómo maneja los casos límite, cómo viaja una decisión desde Figma al código sin perder la intención. Esa revisión compartida es lo que hace que el sistema sea seguro para que otros devs construyan sobre él sin preguntar primero. Ahora lo estamos extendiendo con skills y workflows agénticos, para que consumir un token o componente sea aún más simple para el resto del equipo.
Dónde estaba la fricción
Lo más difícil no fue lo técnico. Esta vertical de producto nunca había tenido una función de diseño. Al principio, eso significó definir criterios de aceptación y handoffs desde cero, iterándolos con ingeniería sobre la marcha. Como design engineer, la fricción se movió hacia abajo: hacer que cada componente fuera lo bastante robusto para soportar cada variante que una pantalla real le lanza, trabajado directamente con el ingeniero frontend senior antes de que el código llegue a producción. El valor que aporto ahora vive en producción, no en un handoff.
El trabajo que se multiplica solo
De las 110 instancias de estos componentes vivas hoy en el producto, una de cada cuatro las colocó otra persona del equipo de frontend, usando componentes que no construyó. Una vez el componente existe y está documentado, la interfaz sigue mejorando sin que yo intervenga en cada pantalla nueva. Ese es el efecto que busca un design system: que el trabajo se multiplique solo.
Impacto cuantificable
440
tokens de diseño (color, interfaz, tipografía)
190+
iconos en librería unificada, 60% de autoría propia
110
instancias vivas de +4 componentes de producción
24%
de esas instancias construidas por el resto del equipo, sin intervención directa
Lo que viene después
Un cambio de marca o de paleta ahora ocurre en la capa de tokens, no pantalla por pantalla. Cada componente nuevo se apoya en lo que ya existe, así que el siguiente sale más rápido y más ligero que el anterior. Tabla, navegación y formularios son los próximos: heredan tokens, iconos y un patrón de migración ya probado en producción. Cada migración también elimina deuda técnica real, con un impacto directo tanto en la velocidad del producto como en el resultado del negocio. El sistema no está terminado. Se sigue multiplicando.