Case study 01 · Flagship · 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.
- Role
- Product Designer & Front-End Engineer
- What I own
- Design-token architecture (Figma → JSON → Style Dictionary) · WCAG 2.1 AA · the line between shared core and brand configuration
- Team
- Four main contributors · 6,637 of 11,622 commits are mine
- 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
Who built it
A small in-house team, and a share of it that can be counted.
42DS is built and maintained by a small in-house team. It is not one person’s system, and reading the rest of this case as though it were would be wrong. I joined mainly as a designer and front-end profile inside an architecture other people had already started, and my part grew with it: as of August 2026, 6,637 of the repository’s 11,622 commits since February 2023 are mine. That is the most honest way I have of saying how much of this is my work and how much is not. Below are the people I worked with most closely — and the commit count measures code, so not everyone whose decisions shaped the system appears in it.
- Juan Francisco MolineraProduct Design LeadLinkedIn ↗
- Susana CabadoDesign System EngineerLinkedIn ↗
- Jorge HerreroChief Product OfficerLinkedIn ↗
Act 01
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.
What counted as success
One fix, every brand.
The bar was a behaviour rather than a number, and it is worth stating both halves of it.
- What success looked like
- A correction made once reaching every title, and a new brand arriving as configuration instead of as code. If the same fix still had to be repeated per masthead, the system had not done its job whatever it looked like.
- What nobody measured
- No one wrote that bar down or tracked it against a baseline. This was business as usual with a system growing inside it, so the evidence is structural — the shared/brand split and the fourteen setups — and not a before-and-after.
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. Measured today, that split is 97% shared SCSS against 3% brand configuration: fourteen brand setups, six for web and eight for AMP.
Shared by every brand
Per brand
Act 02
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 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. AMP is the hardest of those constraints: it caps inline CSS at 75 KB per page, and the eight AMP brand cores ship at around 33 KB — under half the ceiling.
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.
My role moved toward end-to-end product design and AI-assisted execution as the system expanded. What I did not anticipate is that the decisive work would turn out to be documentary rather than visual: the line between what is shared and what belongs to a brand holds because it is written down and enforced, not because it was drawn well once.
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.