Caso de estudio 01 · Insignia · Prensa Ibérica · 2023—2026
42DS — De unos fundamentos compartidos a un design system operable por IA.
Prensa Ibérica necesitaba un sistema capaz de soportar distintas marcas, tecnologías y necesidades editoriales sin congelar el negocio. 42DS se convirtió en la arquitectura compartida que conectó diseño, front-end, desarrollo y, más adelante, flujos asistidos por IA.
- Rol
- Product Designer & Front-End Engineer
- De qué me ocupo
- Arquitectura de design tokens (Figma → JSON → Style Dictionary) · WCAG 2.1 AA · la línea entre el core compartido y la configuración de marca
- Equipo
- Cuatro personas principales · 6.637 de 11.622 commits son míos
- Sistema
- Figma · SCSS · HTML · JS · Storybook · entrega a Vue
La historia de 42DS es una progresión
- Estandarizar los fundamentos.
- Componer patrones de producto reutilizables.
- Hacer el sistema comprensible para las personas y para la IA.
- Familias de componentes
- 134
- Niveles de composición
- 3
- Modos de IA especializados
- 13
Quién lo construyó
Un equipo interno pequeño, y una parte que se puede contar.
42DS lo construye y lo mantiene un equipo interno pequeño. No es el sistema de una sola persona, y leer el resto de este caso como si lo fuera sería un error. Entré sobre todo como perfil de diseño y front-end dentro de una arquitectura que otros ya habían empezado, y mi parte creció con ella: a agosto de 2026, 6.637 de los 11.622 commits del repositorio desde febrero de 2023 son míos. Es la forma más honesta que tengo de decir cuánto de esto es trabajo mío y cuánto no. Debajo están las personas con las que más trabajé, y el recuento de commits mide código: no todo el que decidió sobre el sistema aparece en él.
- Juan Francisco MolineraProduct Design LeadLinkedIn ↗
- Susana CabadoDesign System EngineerLinkedIn ↗
- Jorge HerreroChief Product OfficerLinkedIn ↗
Acto 01
Lo que había que decidir
El problema de negocio
Unificar sin parar la compañía.
Prensa Ibérica había crecido hasta convertirse en un ecosistema multimarca con distintas tecnologías, identidades y decisiones heredadas. La unificación tenía que ocurrir mientras el trabajo del día a día —correcciones, patrocinios, cambios visuales y peticiones editoriales— seguía adelante.
Así que el primer trabajo no fue «diseñar el sistema nuevo». Fue entender el que ya existía: auditar el rendimiento y la complejidad del CSS, aprender el legacy e identificar qué podía pasar a ser compartido.
Qué contaba como éxito
Un arreglo, todas las marcas.
El listón era un comportamiento y no un número, y conviene decir sus dos mitades.
- Qué significaba que saliera bien
- Que una corrección hecha una vez llegara a todas las cabeceras, y que una marca nueva entrara como configuración y no como código. Si el mismo arreglo seguía habiendo que repetirlo cabecera por cabecera, el sistema no había hecho su trabajo por bien que se viera.
- Lo que nadie midió
- Nadie escribió ese listón ni lo siguió contra una línea base. Esto era el día a día del negocio con un sistema creciendo dentro, así que la evidencia es estructural —el reparto entre core y marca, y los catorce setups— y no un antes y un después.
Fundamentos
Separar lo global de lo específico de cada marca.
Tracé la línea por lo que una marca puede redefinir, no por dónde vive el código. Cuatro de las cinco capas son compartidas. Solo cambia la configuración de marca. Medido hoy, el reparto es 97 % de SCSS compartido frente a 3 % de configuración de marca: catorce setups, seis de web y ocho de AMP.
Compartido por todas las marcas
Por marca
Acto 02
Cómo está construido el sistema
La arquitectura de un vistazo
Un único núcleo. Varias capas de composición y entrega.
42DS se entiende mejor como un sistema de relaciones: los fundamentos alimentan los componentes reutilizables, la configuración de marca cambia la expresión y los destinos de producción consumen la misma lógica compartida.
Jerarquía de composición
Primitivas pequeñas que se convierten en productos editoriales.
La jerarquía comunica la escala sin tratar Atomic Design como un dogma. Las primitivas de nivel más bajo se componen en patrones de producto cada vez más contextuales.
05Patrones de producto
04Organismos
03Moléculas
02Átomos
01Fundamentos
Acto 03
El sistema en producción
Fundamentos de diseño · reconstruidos en código
Enseñar el sistema, no la portada de Figma.
En lugar de mostrar miniaturas de archivos, el portfolio reconstruye las decisiones de diseño subyacentes como piezas front-end funcionando: tokens, controles, formularios y navegación.
Fundamentos · sistema funcionando
Los tokens definen la identidad. La rejilla define el ritmo.
Estas piezas están reconstruidas a partir de la arquitectura SCSS de 42DS: custom properties de CSS para el contexto de marca y una rejilla responsive de 12 columnas con breakpoints y reglas de espaciado reales.
Una única API semántica, distintas marcas.
--color-primary
#f53036
--color-primary#f53036--color-black#000 / compartido--color-white#fff / compartido--font-stackstack sans-serif del sistema--font-primarycontexto de marca--font-size-basis1.6rem--font-height-basis2rem$max-width-grid1680px$max-width-grid-p-less1920pxcolumna8.333333%Estructura compartida. El contexto de marca cambia la expresión.
El componente no necesita una reescritura específica por marca.
12 columnas. Cuatro contextos responsive.
Anatomía de un componente
Un componente es un contrato, no solo un dibujo.
Cada pieza conecta la intención de diseño, la estructura reutilizable y el comportamiento de la implementación. Así la entrega resulta comprensible tanto para diseñadores como para desarrolladores.
El texto de apoyo opcional vive dentro del mismo componente semántico.
firma / horaComposición
Reutilizar antes que crear.
La regla útil no era la etiqueta de Atomic Design. Era el modelo de decisión: reutilizar primero, extender cuando la estructura sigue siendo compatible y crear un componente nuevo solo cuando la semántica o la arquitectura cambian de verdad.
Tres niveles de composición hacen que el inventario sea más fácil de razonar y de reutilizar.
Multimarca
Un único núcleo. Distintas identidades.
Las configuraciones de marca controlan la tipografía, el color, los helpers y el comportamiento específico. Los componentes consumen ese contexto en lugar de duplicar toda la implementación.
Caso de uso · cabeceras
Una estructura. Muchas identidades.
La cabecera fue una prueba de esfuerzo exigente: una única arquitectura de información y estructura semántica, y después la expresión de marca a través de logos, tipografía, color y variantes seleccionadas.
Acto 04
Lo que costó llevarlo a producción
La realidad de producción
Un design system construido para restricciones imperfectas.
42DS tenía que soportar puntos de entrada AMP en paralelo, bundles por marca, variantes de paywall y compatibilidad con el legacy. La arquitectura se diseñó para un negocio en marcha, no para una reconstrucción en laboratorio. AMP es la más dura de esas restricciones: limita el CSS inline a 75 KB por página, y los ocho cores AMP de marca se sirven en torno a 33 KB, menos de la mitad del techo.
Diseño ↔ ingeniería
La entrega forma parte del sistema.
Un componente no estaba terminado cuando se veía bien en Figma. También necesitaba una implementación canónica, documentación y un camino claro hacia Vue.
Acto 05
Y luego lo tuvo que leer la IA
Arquitectura operable por IA
Después, el sistema tenía que volverse comprensible para la IA.
Lo que empezó como apoyo de IA para tareas aisladas de JavaScript acabó siendo un mind-system portable. Cada modo se ocupa de un dominio; la gobernanza define el orden de ejecución y la resolución de conflictos, de modo que la IA pueda trabajar con las reglas reales de 42DS en vez de inventárselas.
Qué permite la arquitectura
Un sistema, varios tipos de trabajo.
Qué cambió
La arquitectura creció. Mi rol creció con ella.
Mi papel se movió hacia el diseño de producto de principio a fin y la ejecución asistida por IA a medida que el sistema crecía. Lo que no anticipé es que el trabajo decisivo iba a ser documental y no visual: la línea entre lo que se comparte y lo que es de una marca aguanta porque está escrita y se hace cumplir, no porque se trazara bien una vez.
La evolución más importante no fue añadir más componentes. Fue convertir el conocimiento implícito en un sistema explícito: primero para las personas y, con el tiempo, para la IA.