Introduction
A flood response platform that turns scattered data into coordinated decisions built from scratch, with no UX foundation to start from.
OPAL for Floods is a decision-support platform designed for governments and analysts to coordinate responses to floods in Senegal. As the solo UX/UI designer, I built the product from scratch, designing interfaces, shaping flows, and growing a UX culture along the way.
Impact: From research to rollout, I helped shape a tool now used to inform high-stakes decisions in flood-prone areas
The chaos
Flood disasters are abstract
Multiple data sources. Dispersed information. Decision-making under stress. Machine learning models that are hard to interpret. Different thinking styles, different needs — and all of it converging in moments where lives and infrastructure are at stake.
Domain research
No UX culture, no user research, no defined roles
The project began with no UX foundation. User roles were undefined. There were many features, but it was unclear who would use them. The domain covered life, infrastructure, and complex data like satellite imagery and flood modeling. Stakeholders ranged from analysts to responders,, roles were ambiguous. OPAL's MVP-first mission: connect everything, keep it simple, powerful, and user-driven.
Designing for modularity
I designed for the product we'd need in a year not just the one we needed today.
To make OPAL future-proof, we designed the platform with scalability at its core. Anticipating new features — such as poverty mapping — meant building a system that could grow and adapt without compromising usability. The back end was structured to seamlessly combine in-platform functionalities with external services through API integrations.
The main challenge was creating a unified experience — bringing together diverse tools and services in a way that felt cohesive and intuitive. To achieve this, we focused heavily on mapping user flows. By understanding the journeys of analysts, response advisors, and response managers, we ensured the platform was routed in a way that matched real-world workflows.
Understanding the users
No direct access to users so I built the bridge with what I had.
No UX culture, no direct user access — creativity required. I mapped assumptions into proto-personas covering four key groups: Government Decision-Makers, Field Responders, Analysts, and Admins. I dove into stakeholder research across ministries and organizations, and ran internal testing before external validation to define the core user experience.
Understanding the context
I mapped Senegal's flood landscape before designing a single screen.
Research involved mapping Senegal's flood ecosystem, uncovering pain points and stakeholders, and reviewing competitors. Every insight helped shape key requirements for the platform.
Framing the problem
How could OPAL connect fragmented workflows and disconnected stakeholders to make sense of crisis moments?
Problem framing was crucial to guide every decision. The question wasn't just about interfaces — it was about orchestrating the relationship between data, people, and time-sensitive action.
Making complexity feel simple
My approach: turn complexity into clarity, always prioritizing simplicity.
User flows were rooted in real crisis needs, not just business priority. I used rapid mockups, collaborative iteration with developers, and constant heuristic evaluation to keep designs both powerful and approachable.
Wireframing
Sketches, Crazy 8s, and AI-assisted exploration, whatever it took to find the right shape.
Extensive wireframes and mockups brought ideas to life, visualizing functionality and testing possibilities fast. I ran different brainstorming exercises by myself — sketching ideas to come up with unique designs, then doing Crazy 8s to rapidly explore directions in 8 minutes.
I also used AI to assist and upscale some of my work — uploading top sketches into Figma Make to generate alternative directions, providing context about the problem statement, user needs, and research findings. Once I got interesting visual wireframes, I cherry-picked the best ideas, combined them with my own, and reworked everything back in Figma.
Iteration
Not all ideas survived technical constraints but the best were rapidly iterated and turned into prototypes.
Design and engineering worked in tight loops. Ideas that couldn't be built were discarded fast. Ideas that could were pushed into higher fidelity and tested immediately.
Prototyping
Wireframes became high-fidelity, testable prototypes and now deployed.
The path from wireframe to working prototype was intentionally short. Every screen was designed to be tested, not just admired.
Testing, testing, testing
The users were ministers, analysts, and decision-makers, each with unique needs and zero patience for confusion.
We relied on scenario-based tasks, proactive internal testing cycles, and planned drills to simulate floods and measure experience. Feedback was captured in structured checklists, focusing on what worked and what was confusing — spanning usability, clarity, and accessibility across UX categories.
Design System
I built a living Design System, an evolving artifact
The design system wasn't an afterthought. It was the foundation that made speed possible without sacrificing consistency.
Impact
We launched the live MVP in less than a year.
I served as the bridge from business to engineering, raised UX maturity across the team, and embedded user-centricity into OPAL's strategy — culminating in a full Design System rollout. The platform is now used to inform high-stakes flood response decisions in Senegal.
Projects
OPAL Anticipatory Action
Product Design + Systems Thinking
2026
Earth Genome
Product Design
2025
KPI Tracker
Product Design + Front-End
2026
AI integration