Introduction
An anticipatory flood response platform that acts before disasters hit, not after.
OPAL connects forecast data, risk analysis, and cash disbursement into one decision system. I designed the system logic, the core experience, and the geospatial architecture, ensuring the platform could scale as open, reusable infrastructure for anticipatory action.
The problem
By the time funding reaches affected communities, the damage is already done.
Humanitarian response systems exist. Workflows exist. But they're reactive — funds arrive days or weeks after a disaster, when costs have multiplied and lives have already been lost. Research shows that every €1 invested in anticipatory action saves €7 in disaster response. The infrastructure to respond was there. The infrastructure to anticipate was not.
On top of that, the tools decision-makers rely on are fragmented: disconnected dashboards, siloed data, manual coordination. Under the stress of an unfolding crisis, there's no single place to understand what's happening, who's at risk, and what to do — which delays the one thing that matters most: getting money to people in time.
Systems thinking
I mapped the full system before designing a single screen.
I worked directly with WASDI (satellite data), ML engineers, blockchain engineers, and Jokalante (community alerts) to understand what each system can do, how they connect, and what OPAL should orchestrate. Alongside the tech lead and geospatial scientist, we defined the logic flow — simplifying who does what, when, and how — so that the path from forecast to cash transfer could actually be shortened.
Domain research
I studied how humanitarian decisions actually get made
Deep desk research into Anticipatory Action. Multiple workshops with Mercy Corps. Conversations with AA experts, platform builders, and institutions like CALP, Anticipation Hub, and CILSS. The goal: map real workflows, find where delays happen, understand why funding arrives too late — and design a system that closes those gaps.
Exploration
Early mockups weren't meant to ship but to expose what we didn't know yet.
After studying workflows and testing existing AA platforms, I created exploratory mockups to align stakeholders, surface hidden complexity, and bring technical and humanitarian teams onto the same page.
Core design decision
I unified the entire experience into one map-based "Situation Room."
Instead of breaking the workflow into modules (which would fragment the experience and slow down decisions), I designed a single full-screen interface where risk, data, actions, and triggers converge. Testing confirmed users need to answer three questions fast: Where is the risk? Who is affected? What should I do? — not navigate between tools while a crisis unfolds.
Progressive disclosure
The system reveals information only when it's needed
Each disaster stage surfaces d ifferent data, actions, and coordination workflows:
T0 — Monitoring: Risk layers, forecast data
T1 — Readiness Trigger: Early warnings, impact estimation (automatic)
T2 — Activation Trigger: High-risk signal, human validation required
T3 — Activation: Alerts sent, cash disbursement triggered
T4 — Post-event: KPIs, feedback, learning
This changed the design from a static dashboard to an adaptive system — one that accelerates the path from forecast to funding at every stage.
Decision architecture
I designed the trigger logic that decides when to act — and when to wait for human judgment.
Readiness Trigger — Automatic. Generates impact estimation and enables early awareness, giving teams a head start before conditions escalate.
Activation Trigger — Requires human validation. Provides impact data, trigger explanation, and decision support so operators can release funds with confidence — before the flood, not after.
Inside the Situation Room
One single interface showing where's the risk, who's affected, what should the user do.
Insights panel: forecast data and impact estimates read alongside the map, so risk and its likely human cost are never two screens apart.
Trigger status: the readiness and activation triggers live in the same view, with the human validation step built into the interface itself, not a separate approval workflow.
Decision panel: where the decision-maker reviews and confirms the response: alert messages, disbursement conditions, and the approval action, all in place before anything is sent.
Map with layers and pins: flood risk, vulnerability, and population layers stack directly on the map, with pins surfacing contextual detail on click. No separate GIS tool to cross-reference.
Decision architecture
I designed the trigger logic that decides when to act — and when to wait for human judgment.
Readiness Trigger — Automatic. Generates impact estimation and enables early awareness, giving teams a head start before conditions escalate.
Activation Trigger — Requires human validation. Provides impact data, trigger explanation, and decision support so operators can release funds with confidence — before the flood, not after.
Built to ship, not just to show
From zero mockups to production-ready, deployed screens.
Segmentation and persona research defined four distinct users — System Admin, Decision-Maker, Operational User, Beneficiary — each with different needs, different stress levels, different reasons to trust the system. That fed directly into user journeys mapped stage by stage across T0–T3, then into a full UX logic document defining how every screen connects to the system's decision architecture. None of it stayed conceptual. It became the high-fidelity, validated screens now live in the platform.
Scaling design
I built a design system meant to grow across every OPAL product.
The OPAL Design System defines UI components, interaction patterns, map standards, data visualization rules, and accessibility considerations for low-bandwidth contexts. It's the shared language for a growing product ecosystem.
Open-source infrastructure
I chose an open-source map stack so the platform wouldn't depend on anyone.
Alongside our geospatial data scientist, I led the geospatial architecture decisions, not just how the map looks, but how it behaves. Maputnik for custom basemap editing, OpenFreeMap as the open-source basemap, deck.gl for dynamic data visualization layers. This means reusability across products, lower cost, regional adaptability, and zero vendor lock-in.
AI integration
I pushed to integrate the chatbot into the map to not hide it on a separate screen.
The chatbot was originally scoped as a standalone feature. I argued it would die in isolation. After working with the ML Ops team, we connected it to map state and real-time data — enabling context-aware queries like "How many people are affected here?" directly inside the Situation Room.
One Platform, many Operators
The hardest technical problem was making different organizations trust the same data without stepping on each other.
Working with engineering, I helped define OPAL's multi-tenant architecture - a system where multiple organizations operate inside the same operational environment, sharing datasets and workflows, without losing control over who can see or do what.
Inside the Mercycorps pilot,, different institutions (like Practical Action) all work from the same data, but through role-based permissions - administrator, decision-maker, operational user, view-only . So a decision-maker's authority to trigger a response never gets confused with the admin role. That structure is what lets OPAL scale to new organizations later without redesigning the core system each time.
Proof and Evidences
A real product that was tested with domain experts
OPAL it's live, and tested alongside Mercy Corps, Practical Action, and ANACIM. Senegal is now working to fold anticipatory action into its national contingency plan, giving the platform's national-integration goal an actual government process to plug into.
"I haven’t seen anything like this. I see great potential"
by an Humanitarian Affairs Officer, Anticipatory Action · UN OCHA
"I think this is something which makes lot of sense. You’ve got all this public data out there that you can use"
by a Technical Advisor on Data and Digitalisation · Anticipatory Hub
"What creates confusion is not seeing the whole information, and this really solves it."
by an Anticipation Action Division · United Nations
Testing with AA field experts didn't just validate the interface but it changed the design. One practitioner confirmed something we couldn't have known internally: no fully automatic AA trigger system exists anywhere in the region today. Every real system keeps a human in the loop.
That single conversation turned our T2 validation step from an assumption into an industry-confirmed decision. Two more field experts, testing the prototype against their own crisis workflows, confirmed the T0–T3 structure mapped directly onto how decisions actually get made on the ground, and surfaced a gap we hadn't designed for: preparedness has to be visible before a trigger ever fires, not just at activation.
Challenges
Honest about what was hard.
Complexity was the enemy. The biggest risk was building a system that mirrored the fragmentation it was trying to solve. Resisting the urge to add was constant discipline.
Bridging worlds. Translating between humanitarian workflows, ML constraints, geospatial science, and blockchain systems required nonstop context-switching.
Designing for real stress. Every decision had to account for cognitive load during actual disasters — not just clean usability testing.
Open-source trade-offs. Less mature tooling and documentation, but the right call for scalability and independence.
Reflection
The hardest part wasn't designing screens — it was defining how a humanitarian system should think, decide, and act.
And then making that logic feel simple enough to use when it matters most.
Projects
OPAL Anticipatory Action
Product Design + Systems Thinking
2026
Earth Genome
Product Design
2025
KPI Tracker
Product Design + Front-End
2026