Insights from the DIRECTED Data Fabric

The Challenge: Building Software That Users Actually Need and Use

In geospatial research and software engineering, we frequently encounter a persistent paradox: sophisticated platforms, cutting-edge hazard models, and rich spatial data infrastructures are built with tremendous technical skill and effort – but lack uptake. Why? Because the development process often occurs in isolation from the operational realities, decision-making pressures, and daily workflows of end-users.

When addressing complex crises like climate change adaptation (CCA) and disaster risk management (DRM), a purely top-down or tech-driven development approach routinely fails. Emergency responders do not need generic GIS viewers with a multitude of layers and tools; civil protection officers require clear, actionable, and rapid information products that answer specific questions during an evolving crisis.

This leads to this week’s challenge:

How can we design and develop geospatial information systems that genuinely address user needs, bridge organizational silos, and adapt as real-world requirements evolve?

52°North tackled this exact challenge in the Horizon Europe DIRECTED project, working with an interdisciplinary consortium including stakeholders from Real World Labs. By establishing a structured Co-Design Framework around the DIRECTED Data Fabric, we turned end-users from passive recipients into active co-creators of the software platform.

Our Approach: Co-Design in Action

Co-design is far more than asking stakeholders what features they want at the beginning of a project, re-visiting design choices with them once in a while and presenting a finished tool later. It is a continuous, agile conversation that aligns technical possibilities with operational needs.

To turn co-design principles into a tangible engineering process, we structured our work around four key pillars:

1.  Dedicated Task Forces and Product Ownership
For each of DIRECTED’s four Real World Labs (RWLs), we established a compact, cross-disciplinary Task Force. Crucially, a representative from the local RWL host acted as the Product Owner. The Product Owner prioritized the development based on the real thematic needs of local practitioners, while developers, modelers, and experts in governance and knowledge co-production supported the technical execution.

2. Iterative Interface Evolution (Mock-ups to Production)
Before committing to backend pipeline engineering, we created interactive Graphical User Interface (GUI) mock-ups based on initial user stories. Presenting these mock-ups during early stakeholder workshops allowed us to refine UI elements, data layer groupings, and decision-support widgets early. This saved plenty of redundant development time.

3. Agile, Sprint-Based Increments
Borrowing from Scrum, development moved in short, bi-weekly sprints. Every iteration delivered a testable software increment. Stakeholders were not evaluating static specification documents; they were interacting with specific and live solutions, enabling continuous feedback and quick pivots when assumptions met reality.

4. Continuous Feedback Loops and Operational Drills
For the DIRECTED project, we tested prototypes directly within real-world emergency management workflows. From Tabletop Exercises (TTX) in flood management to full-scale multi-agency field drills with firefighters and rescue teams, software components were evaluated under operational pressure.

Real-World Impact Across the DIRECTED Labs

Our co-design methodology was put to the test across four diverse European regions, each presenting unique hazard profiles, institutional contexts, and user requirements:

• Capital Region of Denmark (Roskilde Fjord): Local municipalities and fire departments needed to evaluate combined storm surge and heavy rainfall risks. Through iterative workshops, we implemented interactive rainfall/coastal water sliders, local groundwater levels, and a Multi-Criteria Decision-Making (MCDM) process backed by CLIMADA to weigh adaptation measures.
• Emilia-Romagna Region (Italy): Civil protection officers and firefighters needed rapid forecasting tools during emergencies. The Data Fabric integrated real-time radar (HERA), weather forecasts (ICON), and live sensor streams to trigger automated pluvial/coastal flood mapping (SaferPlaces) and wildfire spread simulations (PropagatorCIMA) intersecting with sensitive receptors like schools and hospitals.
• Danube River Basin (Vienna & Zala County): In Vienna, insurance and public sector actors focused on urban pluvial flash floods and shifting return intervals under climate projections. In Hungary’s Zala region, volunteer rescue teams and municipal planners co-designed a multi-hazard dashboard featuring historical disaster catalogs, local sensor feeds, and crop yield projections.
• Rhine-Erft Region (Germany): Following the catastrophic 2021 floods, the Erftverband and district emergency authorities required tools to test non-structural measures. We co-developed hydrodynamic simulation sandbox workflows (RIM2D) for different scenarios.

5 Questions for 52°North’s Development Team

1. What was the biggest surprise during the co-design process in DIRECTED? How quickly stakeholders’ focus shifts from complex backend model mechanics to visual clarity and user experience. Modeler teams often want to highlight technical precision, but operational users care most about transparency: Where does this data come from, how old is this simulation, and how uncertain is this prediction?

2. Is co-design more time-consuming than traditional software engineering? Initially, yes. It requires significant effort upfront to build trust, organize workshops, and run feedback loops. However, it saves immense time in the long run by preventing us from building features that nobody uses or understands. It’s a demanding, yet insightful process for everyone involved.

3. How do you manage conflicting feature requests from different user groups? That is where the Task Force Product Owner is essential. By establishing clear acceptance criteria and prioritizing items based on actual operational gaps, we ensure the platform remains focused rather than bloated.

4. How does Open Science play a role in this co-design approach? Open Science and FAIR data principles are the foundation. By relying on open standards (like OGC APIs) and open-source frameworks and solutions, any component co-designed in one region can be reused or extended by another without vendor lock-in.

5. What is the main takeaway for future research and software projects? Don’t build for users in a silo; build with them. Prototype early, test under real conditions, and accept that user feedback will—and should—change your original development plan.

Your Take Away Today

Co-design is not just a theoretical framework; it produces modular, highly reusable open-source software. As part of our commitment to Open Science, the tools and building blocks created during the DIRECTED project are openly available for your own applications:

• Open Pioneer Trails: An open-source framework maintained by 52°North and con terra for building modular, modern geospatial web clients. It served as the frontend foundation for the Data Fabric (on GitHub).
• Pygeoapi Kubernetes Manager: An open-source extension co-developed in DIRECTED to execute OGC API processing jobs dynamically in cloud environments (on GitHub).
• Data Fabric Web Client Repositories: Explore our open-source frontend code directly on GitHub.

Are you planning a geospatial platform or looking to incorporate co-design methodologies into your research infrastructure? Reach out to our team to explore collaboration opportunities!