Case study 03 · Prensa Ibérica · 2023—2026
The brief was simple: reproduce the map. The real problem wasn’t.
I replaced a difficult-to-maintain static asset with a responsive, data-driven map whose content could be updated from structured data.
In 30 seconds
- The tension
- The brief was to redraw a set of static map images that no one could update without a designer and that did not work on a phone.
- My call
- Replace what sat underneath: a data model in Google Sheets and CSV on Leaflet and IGN, with no paid mapping platform.
- The evidence
- 83 locations and 17 mastheads as rows of four fields, driving the live map embedded below. Counted on 22 August 2026.
- What changed
- Product took over editorial maintenance, and the same data-first pattern travelled to a second map built on SYX.
- Role
- Product Design + Front-End — data model, interaction and 42DS integration
- System
- 42DS
- Data
- Google Sheets → CSV
- Build
- Leaflet · IGN · JavaScript
The brief
The requested interface was not the real problem.
The previous solution was a set of static images: hard to maintain, poorly adapted to mobile, and impossible to update without opening an image editor. The request that reached me was, in essence, to draw it again. I proposed replacing what sat underneath it instead.
Real project evidence · code
The map itself is the evidence.
This standalone view keeps the original Leaflet implementation, IGN tiles, real marker data, publication-specific icons, popups and Spain-wide bounds logic. I removed the surrounding newspaper chrome so the development is easier to inspect.
What counted as success
Nobody set a bar, because nobody had asked for this.
Worth saying plainly, because it is the part a case study usually invents afterwards.
- What was agreed
- Nothing was. The brief was to reproduce the existing map; replacing the solution underneath it was my call, and no one sets a target for work they have not commissioned.
- What I built against instead
- The two failures the old asset already had: it could not be updated without a designer, and it did not work on a phone. Those were the only reference points available, so they became the criteria.
The constraint
An interactive map, without adding a paid mapping platform.
That requirement came from my design lead, not from me: the map could not become a running cost for the company. Google Maps and its equivalents were off the table, so the implementation had to stand on open technology: Leaflet, over IGN mapping resources.
- What the constraint bought
- No licence, no vendor and no per-view cost. The map could ship and keep running without opening a budget line, which is what made it approvable at all.
- What it cost
- Clustering, geocoding and routing arrive free with a paid platform; on Leaflet you build them or you go without. And the bill moved from a licence to my hours. The saving was real. The work was not free.
The team
The constraints came from the design lead. The solution did not.
The split is worth stating, because it is what makes the rest of this case readable. Juan Francisco Molinera briefed me on the state the previous map was in, set the guidelines it had to respect — including that it could not become a running cost for the company — and opened the internal doors I needed to recover the data. Everything downstream of that was mine: proposing a different solution instead of redrawing the old one, the data model, the interaction and the integration with 42DS.
- Juan Francisco MolineraProduct Design Lead — the brief, the guidelines the map had to respect, and the internal contacts for the dataLinkedIn ↗
- Editorial and business contactsMedia names, geolocation and company data, held across different newsrooms
The hidden work
Before the map, there had to be reliable data.
The information was fragmented across editorial teams and nowhere in a usable shape. I assembled it myself in a spreadsheet — locations, media types, relationships and the fields the interface would need — and moved maintenance onto Google Sheets and CSV instead of image editing. Every location became a row of four fields instead of a pixel somebody had to redraw.
Moving one location means reopening the artwork and re-exporting. 82 locations, not one of them addressable.
Same locations→different maintenance model
Each location is a row. 16 mastheads · 13 regions · updated without touching the build.
Country and province geometry: Instituto Geográfico Nacional, CC BY 4.0, via es-atlas. Coordinates: the project's own location table, read from the live demo at build time.
- Locations
- 83
- Mastheads
- 17
- Fields per row
- 4
AI-assisted build
Use AI to extend execution capability, not to avoid product decisions.
My background was design and CSS, not JavaScript at this level of complexity. AI support let me implement an interactive experience more complex than anything I had shipped alone, while the product structure, the data model, the behaviour and the 42DS integration stayed mine. The distinction matters: the decisions that were hard on this project are not the ones a model makes for you.
Product decision
Make maintenance part of the design.
Editorial maintenance was expected to sit with the newsrooms. Because the data workflow was cheap enough to operate, Product could absorb that work when newsroom resources were short — and did. A decision about file formats ended up deciding who does the job.
What happened after
The data model outlived the map it was built for.
Two things came out of it. Product took over editorial maintenance of the map, which is the outcome the previous decision existed to make possible. And the pattern travelled: syx--emotional-spain-map is a public, live project built on the same shape — a JSON file of coordinates and fields driving a Leaflet map, with the data as the thing you edit rather than the drawing. Different subject, same decision.
Takeaway
Interaction work stopped being an exception.
This is the project where building the interaction, and not just specifying it, became something I could take on; it is now a regular part of what I ship, in 42DS and in my own projects. What I would keep is the order — the data model before the interface. What I would change is that I replaced the solution without agreeing what success would mean. It worked out because maintainability turned out to be what everyone wanted, and that was not something I had established beforehand.