FLAGSHIP CASE · PRENSA IBÉRICA · 2023—2026
42DS — From shared foundations to an AI-operable design system.
Prensa Ibérica needed one system that could support different brands, technologies and editorial needs without freezing the business. 42DS became the shared architecture that connected design, front-end, development and, later, AI-assisted workflows.
- My role
- Product Designer & Front-End Engineer
- What I own
- Design-token architecture (Figma → JSON → Style Dictionary) · WCAG 2.1 AA · CSS performance and technical-debt reduction
- System
- Figma · SCSS · HTML · JS · Storybook · Vue hand-off
The story of 42DS is a progression
- Standardise the foundations.
- Compose reusable product patterns.
- Make the system understandable to people and AI.
- Component families
- 134
- Composition levels
- 3
- Specialised AI modes
- 13
Act 01
How the system is built
Architecture at a glance
One core. Multiple layers of composition and delivery.
42DS is easier to understand as a system of relationships: foundations feed reusable components, brand configuration changes expression, and production targets consume the same shared logic.
Composition hierarchy
Small primitives become editorial products.
The hierarchy communicates scale without treating Atomic Design as dogma. Lower-level primitives are composed into increasingly contextual product patterns.
05Product patterns
04Organisms
03Molecules
02Atoms
01Foundations
Act 02
What had to be decided
The business problem
Unify without stopping the company.
Prensa Ibérica had grown into a multi-brand ecosystem with different technologies, identities and legacy decisions. Unification had to happen while BAU work — fixes, sponsorships, visual changes and editorial requests — continued.
So the first job was not “design the new system”. It was understand the existing one: audit performance and CSS complexity, learn the legacy and identify what could become shared.
Foundations
Separate what is global from what is brand-specific.
I drew the line by what a brand can redefine, not by where the code lives. Four of the five layers are shared. Only the brand setup changes.
Shared by every brand
Per brand
Act 03
The system in production
Design foundations · rebuilt in code
Show the system, not the Figma cover.
Instead of showing file thumbnails, the portfolio reconstructs the underlying design decisions as live front-end visuals: tokens, controls, forms and navigation.
Foundations · live system
Tokens define the identity. The grid defines the rhythm.
These visuals are reconstructed from the 42DS SCSS architecture: CSS custom properties for brand context and a 12-column responsive grid with real breakpoints and spacing rules.
One semantic API, different brands.
--color-primary
#f53036
--color-primary#f53036--color-black#000 / shared--color-white#fff / shared--font-stacksystem sans-serif stack--font-primarybrand context--font-size-basis1.6rem--font-height-basis2rem$max-width-grid1680px$max-width-grid-p-less1920pxcolumn8.333333%Shared structure. Brand context changes the expression.
The component does not need a brand-specific rewrite.
12 columns. Four responsive contexts.
Component anatomy
A component is a contract, not just a drawing.
Each piece connects design intent, reusable structure and implementation behaviour. This makes the hand-off understandable to both designers and developers.
Optional supporting text lives inside the same semantic component.
byline / timeComposition
Reuse before create.
The useful rule was not the Atomic Design label. It was the decision model: reuse first, extend when structure stays compatible, and create a new component only when semantics or architecture really change.
Three composition levels make the inventory easier to reason about and reuse.
Multi-brand
One core. Different identities.
Brand setups control typography, colour, helpers and specific behaviour. Components consume that context instead of duplicating the whole implementation.
Use case · headers
One structure. Many identities.
The header was a strong stress test: one information architecture and semantic structure, then brand expression through logos, typography, colour and selected variants.
Act 04
What it cost to ship
Production reality
A design system built for imperfect constraints.
42DS had to support parallel AMP entry points, brand bundles, paywall variants and legacy compatibility. The architecture was designed for a live business, not a clean-room rebuild.
Design ↔ engineering
The hand-off is part of the system.
A component was not finished when it looked right in Figma. It also needed a canonical implementation, documentation and a clear path into Vue.
Act 05
Then AI had to read it too
AI-operable architecture
Then the system had to become understandable to AI.
What began as AI support for isolated JavaScript tasks became a portable mind-system. Each mode owns a domain; governance defines execution order and conflict resolution, so AI can work with the real 42DS rules instead of inventing around them.
What the architecture enables
One system, several kinds of work.
What changed
The architecture grew. My role grew with it.
I joined mainly as a designer/front-end profile inside the architecture. As the system expanded, my role moved toward end-to-end Product Design and AI-assisted execution.
The most important evolution was not adding more components. It was turning implicit knowledge into an explicit system — first for people, and eventually for AI.