Caso de estudio 03 · Prensa Ibérica · 2023—2026
El encargo era simple: reproducir el mapa. El problema real no lo era.
Sustituí un recurso estático difícil de mantener por un mapa responsive dirigido por datos, cuyo contenido podía actualizarse desde datos estructurados.
En 30 segundos
- La tensión
- El encargo era volver a dibujar un conjunto de imágenes estáticas del mapa que nadie podía actualizar sin un diseñador y que no funcionaban en un teléfono.
- Mi decisión
- Sustituir lo que había debajo: un modelo de datos en Google Sheets y CSV sobre Leaflet e IGN, sin plataforma de mapas de pago.
- La evidencia
- 83 ubicaciones y 17 cabeceras como filas de cuatro campos, alimentando el mapa en vivo embebido más abajo. Recontado el 22 de agosto de 2026.
- Qué cambió
- Producto asumió el mantenimiento editorial, y el mismo patrón —primero los datos— viajó a un segundo mapa construido sobre SYX.
- Rol
- Product Design + Front-End — modelo de datos, interacción e integración en 42DS
- Sistema
- 42DS
- Datos
- Google Sheets → CSV
- Construcción
- Leaflet · IGN · JavaScript
El encargo
La interfaz que se pedía no era el problema real.
La solución anterior era un juego de imágenes estáticas: difícil de mantener, mal adaptada a móvil e imposible de actualizar sin abrir un editor de imagen. Lo que me llegó era, en esencia, volver a dibujarla. Propuse cambiar lo que había debajo.
Evidencia real del proyecto · código
El mapa en sí es la evidencia.
Esta vista independiente conserva la implementación original en Leaflet, las teselas del IGN, los datos reales de los marcadores, los iconos específicos de cada publicación, los popups y la lógica de encuadre para toda España. He quitado el envoltorio del periódico para que el desarrollo se pueda inspeccionar más fácilmente.
Qué contaba como éxito
Nadie puso un listón, porque nadie había pedido esto.
Conviene decirlo claro, porque es la parte que un caso suele inventarse después.
- Lo que se acordó
- Nada. El encargo era reproducir el mapa que había; cambiar la solución de debajo fue decisión mía, y nadie fija un objetivo para un trabajo que no ha pedido.
- Contra qué construí en su lugar
- Los dos fallos que la pieza vieja ya tenía: no se podía actualizar sin un diseñador y no funcionaba en el móvil. Eran las únicas referencias disponibles, así que se convirtieron en el criterio.
La restricción
Un mapa interactivo, sin meter una plataforma de mapas de pago.
Ese requisito lo puso mi design lead, no yo: el mapa no podía convertirse en un coste recurrente para la empresa. Google Maps y equivalentes estaban descartados, así que la implementación tenía que sostenerse sobre tecnología abierta: Leaflet, sobre recursos cartográficos del IGN.
- Lo que compró la restricción
- Sin licencia, sin proveedor y sin coste por visita. El mapa podía salir y seguir funcionando sin abrir una partida de presupuesto, que es lo que lo hacía aprobable.
- Lo que costó
- El clustering, la geocodificación y el cálculo de rutas vienen dados en una plataforma de pago; en Leaflet los construyes o te quedas sin ellos. Y la factura pasó de una licencia a mis horas. El ahorro fue real. El trabajo no fue gratis.
El equipo
Las restricciones vinieron del design lead. La solución, no.
Conviene decir el reparto, porque es lo que hace legible el resto del caso. Juan Francisco Molinera me puso al día del estado en que estaba el mapa anterior, fijó las directrices que tenía que respetar —entre ellas que no podía convertirse en un coste recurrente para la empresa— y me abrió las puertas internas que necesitaba para recuperar los datos. Todo lo que viene después de ahí es mío: proponer otra solución en vez de redibujar la vieja, el modelo de datos, la interacción y la integración con 42DS.
- Juan Francisco MolineraProduct Design Lead — el encargo, las directrices que el mapa tenía que respetar y los contactos internos para los datosLinkedIn ↗
- Contactos de redacción y de negocioNombres de los medios, geolocalización y datos empresariales, repartidos entre distintas redacciones
El trabajo invisible
Antes del mapa tenía que haber datos fiables.
La información estaba repartida entre redacciones y en ningún sitio en una forma usable. La reuní yo en una hoja de cálculo —ubicaciones, tipos de medio, relaciones y los campos que la interfaz iba a necesitar— y llevé el mantenimiento a Google Sheets y CSV en vez de a la edición de imagen. Cada ubicación pasó a ser una fila de cuatro campos en vez de un píxel que alguien tenía que redibujar.
Mover una sola localización obliga a reabrir el arte final y volver a exportarlo. 82 localizaciones, y ninguna con enlace propio.
Las mismas localizaciones→otro modelo de mantenimiento
Cada localización es una fila. 16 cabeceras · 13 comarcas · actualizadas sin tocar el build.
Geometría de país y provincias: Instituto Geográfico Nacional, CC BY 4.0, vía es-atlas. Coordenadas: la propia tabla de localizaciones del proyecto, leída de la demo publicada durante el build.
- Ubicaciones
- 83
- Cabeceras
- 17
- Campos por fila
- 4
Desarrollo asistido por IA
Usar la IA para ampliar la capacidad de ejecución, no para evitar decisiones de producto.
Mi origen era el diseño y el CSS, no JavaScript a este nivel de complejidad. El apoyo de la IA me permitió implementar una experiencia interactiva más compleja que nada que hubiera sacado yo solo, mientras la estructura de producto, el modelo de datos, el comportamiento y la integración con 42DS seguían siendo míos. La distinción importa: las decisiones difíciles de este proyecto no son las que un modelo toma por ti.
Decisión de producto
Hacer del mantenimiento parte del diseño.
Se daba por hecho que el mantenimiento editorial se quedaba en las redacciones. Como el flujo de datos salía lo bastante barato de operar, Producto pudo absorber ese trabajo cuando la redacción iba justa de recursos, y lo absorbió. Una decisión sobre formatos de fichero acabó decidiendo quién hace la tarea.
Qué pasó después
El modelo de datos sobrevivió al mapa para el que se hizo.
Salieron dos cosas. Producto se quedó con el mantenimiento editorial del mapa, que es justo el resultado que la decisión anterior existía para hacer posible. Y el patrón viajó: syx--emotional-spain-map es un proyecto público y en vivo construido con la misma forma —un JSON de coordenadas y campos moviendo un mapa de Leaflet, con el dato como lo que se edita en vez del dibujo—. Otro tema, la misma decisión.
Conclusión
El trabajo de interacción dejó de ser una excepción.
Este es el proyecto en el que construir la interacción, y no solo especificarla, pasó a ser algo que podía asumir; hoy es una parte habitual de lo que saco, en 42DS y en mis proyectos propios. Lo que me quedo es el orden: el modelo de datos antes que la interfaz. Lo que cambiaría es haber sustituido la solución sin acordar qué significaba que saliera bien. Salió porque la mantenibilidad resultó ser lo que quería todo el mundo, y eso no lo había dejado establecido.