Enter password to view case study
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.
Key Insight
Make the workflow less fragmented
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.
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.
End-to-end execution
From zero mockups to production-ready, deployed screens.
Beyond system design, I executed the full product: exploratory concepts → mid-fidelity flows → high-fidelity validated screens now live. The system logic wasn't just conceptual — it became usable, testable, and real.
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 — 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.
Technical alignment
I aligned the codebase architecture to mirror how users actually think.
Working with frontend engineering, we adopted a "Screaming Architecture" — the system structure reflects user workflows and domain logic, not technical layers. The Situation Room functions as a central orchestrator, not just a UI screen.
Validation
I reached out to AA institutions to validate the approach & and it opened doors.
I outreached to CALP, Anticipation Hub, and CILSS served two purposes: gathering expert feedback on our design decisions, and exposing the project to organizations who could become future collaborators.
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