Sol OS

Barcelona faces accelerating urban heat island effects. Neighborhoods like Nou Barris and Sant Martí are projected to exceed 50°C surface temperature by 2040. The city has the data — AEMET readings, Copernicus satellite measurements, census-level vulnerability indices, decades of urban planning records.

What it lacked was a way to turn that data into decisions across two radically different contexts: the urban planner running long-term intervention simulations at a Monday morning council meeting, and the resident navigating home safely on a 38°C Tuesday afternoon with a child in tow.

Existing tools were built for one audience or neither. Weather apps don't support policy decisions. Planning dashboards don't help residents find shade. A single unified app would serve both poorly — and in a safety-adjacent context, "poorly" isn't acceptable.

Spain-level heat vulnerability — Barcelona as pilot city

Before building anything, I ran a structured research sprint to validate whether the problem warranted a product — and to understand whether one product could actually serve both audiences.

5 stakeholder interviews

Three urban planners (two from Barcelona's Àrea de Medi Ambient i Serveis Urbans, one independent), two residents from high-vulnerability neighborhoods (Nou Barris and Besòs i Maresme). The planners spoke in data layers and policy cycles. The residents spoke in routes and heat and children. They didn't share a vocabulary for the same problem.

Existing tools reviewed

AEMET heat warnings (broadcast-only, not actionable at the individual level), OpenWeatherMap (real-time temperature without context), existing Barcelona city heat maps (planner-facing, not resident-accessible, not updated in real time), Copernicus Urban Atlas (excellent data, entirely inaccessible to non-specialists). None served residents. None let planners run what-if scenarios. None were honest about data confidence.

Key insight: two mental models, one data source

Planners and residents don't just have different needs — they have different mental models of what urban heat even is. A planner thinks in surface temperature differentials across census tracts. A resident thinks in "which street is shaded at 4pm." The same underlying data can answer both questions. The interface that answers one is useless for the other.

Policy landscape reviewed

Barcelona's Pla del Clima 2018-2030, the Pla d'Arbrat 2017-2037 (targeting 30% canopy cover), the Superblocks programme, and the city's digital sovereignty charter — which explicitly supports civic tech that keeps data processing local and avoids surveillance infrastructure. Sol OS was designed to align with every one of these commitments.

The original prototype was a single application with a role toggle: Resident / Architect / Planner. In theory, each role got a different view of the same map. In practice, this was a paper compromise.

The cognitive tasks are fundamentally different. A planner needs to load multiple data layers simultaneously, run intervention simulations, export policy-ready reports, and compare neighborhoods over time. A resident needs one thing: get home without a heat emergency. These two needs don't share a UI. They don't share an information architecture. They barely share a design language.

The architecture decision: split into two products with a shared data layer, distinct deployment contexts, and separate design systems that reference the same Sol OS visual identity.

Sol OS Platform │ ├── Sol Planner ─── B2G · Desktop · City contracts │ ├── Heat vulnerability maps (borough → block level) │ ├── Intervention simulator (trees / cool roofs / water) │ ├── Policy export (PDF reports for city council) │ └── Five-layer confidence model (Measured → Illustrative) │ └── Ruta Fresca ─── B2C2G · Mobile · Public service ├── Cool route navigation (shade-aware pathfinding) ├── Neighborhood heat alerts (hyperlocal) ├── Cooling center finder (real-time, offline-capable) └── AI Climate Guide (deterministic, labeled confidence)

One data layer, two products — Ruta Fresca (consumer, mobile) and Sol Planner (planner, desktop)

Sol Planner is a desktop web application for municipalities. Its primary users are urban planners, climate adaptation officers, and infrastructure teams. The job is analysis, simulation, and policy support — not navigation.

The core interaction model is a five-layer decision platform: every data point carries an explicit confidence label (Measured, Estimated, Modeled, or Illustrative). Planners can filter by confidence tier, run what-if scenarios for interventions like canopy expansion or cool roof installation, and export findings as structured reports for city council.

Sol Planner — Barcelona district view with confidence-labeled data layers

In climate data, certainty is not binary. Measured data (from AEMET ground stations) carries different weight than modeled projections (from urban heat simulation). Showing both on the same map without distinguishing them is not just bad UX — it is professionally misleading.

Sol Planner labels every data layer with one of four confidence tiers, each with a distinct visual treatment:

Measured — direct sensor readings. Solid color, full opacity.

Estimated — interpolated from adjacent sensors. Diagonal hatching.

Modeled — computational simulation output. Cross-hatching.

Illustrative — scenario hypothesis (what-if interventions). Dot pattern, clearly marked.

Planners and engineers who use data to make public decisions told us clearly: they need to know what they can stand behind. Confidence labeling is not a disclaimer — it is the product's primary trust mechanism.

Sol Planner — Intervention recommendations panel, Gràcia district

Significant product choices made during the design and architecture process — with the rationale behind each one.

Decision 01

Scope: Barcelona first

Barcelona has strong open data infrastructure (AEMET, Copernicus, INE census), demonstrated political will (Superblocks, tech sovereignty charter), and a clear procurement path through the Àrea de Medi Ambient. National scale is validated second — not assumed.

Decision 02

Explainable AI over black-box recommendations

In high-stakes contexts — health, safety, public policy — black-box recommendations are ignored or distrusted. Every data point in Sol OS carries a confidence label. Users see what they can trust before they act on it. This is not a disclaimer system; it is the product's core trust architecture.

Decision 03

Residents + Planners as primaries (not Architects)

Architects have professional tooling. Residents and planners sit on opposite ends of the impact flywheel — one lives the problem, one can fix it at scale. Designing for both creates a platform with both upstream influence and downstream adoption. Designing for architects would have produced a niche B2B tool.

Decision 04

Single-file prototype, zero dependencies

The Sol Planner prototype is one HTML file with no build pipeline, no backend, no API keys. It runs in any browser, can be emailed, can be demoed on a projector, can be handed to a city councillor on a USB drive. This was a design constraint that made the product more demonstrable and more honest about what a pilot requires.

Decision 05

Split Sol Planner and Ruta Fresca

The original mode toggle (Resident / Architect / Planner) was a paper compromise. A planner running policy simulations and a resident finding a cool route home do not share cognitive context, deployment environment, or update cadence. Two products, one data layer. The split is architectural, not cosmetic.

Decision 06

Data confidence over false precision

Showing imprecise data honestly is better UX than showing precise data dishonestly. "This is modeled, not measured" is more useful than a confident number that overstates certainty. In climate contexts especially, users who are misled by false precision stop trusting the system entirely — and that failure mode is irreversible.

The prototype is a working single-file application — not a mockup. It runs with no backend, no API calls, and no build process. Every interaction is functional: layer toggling, neighborhood selection, intervention simulation, confidence filtering, and the climate assistant.

Sol Planner — Interactive Prototype Open full screen →

The citizen-facing product in the Sol OS family. Where Sol Planner is data-dense and policy-linked, Ruta Fresca is radically simple: one job, one question, one answer.

"How do I get home safely today?"

Cool route navigation (shade-aware pathfinding)

Neighborhood heat alerts (hyperlocal, real-time)

Cooling center finder (offline-capable)

Hydration and rest reminders

Vulnerable population guidance

AI Climate Guide (deterministic, confidence-labeled)

No account required

Location stays on-device

Status: Concept / Design exploration — prototype not yet built. Ruta Fresca is designed to be funded and distributed as public infrastructure — not a consumer subscription. We are seeking a city partnership to pilot it as a public service, co-designed with residents from high-vulnerability neighborhoods.

Dashboard — Today

Alert Detail — Extreme UV

Route Planner — Cooler options

iOS screens · Figma design file · Not yet prototyped or user tested View in Figma →

Active route — confidence labels applied to mobile. Every estimate marked Modelado or Hipótesis. Location stays on device.

These screens are design hypotheses, not validated solutions

The Ruta Fresca flows, UI patterns, and information architecture shown here have not been tested with users. No formative or summative research has been conducted with target populations. The entire product concept is pre-validation — every decision visible in the prototypes represents design intent, not evidence-based conclusions.

Next step: Recruit 5–8 residents from heat-vulnerable neighbourhoods in Barcelona for moderated usability sessions before any development commitment.

What exists today

Sol Planner prototype complete — five-layer decision platform, three user roles (Resident / Architect / Planner), trilingual interface (ES / EN / CA), AI climate assistant with deterministic responses, full confidence labeling system, intervention simulator, and site analysis panel. Runs with zero dependencies in any browser.

What a pilot requires

No new hardware or data infrastructure — Sol OS runs entirely on open data sources already published by AEMET, Copernicus, and the Barcelona Open Data portal. A six-week pilot requires access to two or three planning teams and a commitment to use the tool in actual weekly prioritization meetings. Zero operational disruption.

Target partners

Barcelona City Council — Àrea de Medi Ambient i Serveis Urbans. Secondary targets: Generalitat de Catalunya (Departament de Territori), and European civic tech networks already piloting urban heat tools in Mediterranean cities.

The prototype, research documentation, and pilot framework are available. To discuss partnership or review the full research: design.perex@gmail.com or book a 30-minute call .

Continue reading

Read case study → Read case study →