Hamal Ezrahi

Crisis communication infrastructure for 40,000 evacuees

A self-initiated crisis response in Eilat after October 7th. Live in under two weeks, reaching roughly 70% adoption among approximately 40,000 evacuees.

The Hamal Ezrahi web page, routing evacuees to aid services by category of need.
Role
Product Lead (Volunteer)
Platforms
Web, WhatsApp and bot integrations
Team
All-volunteer: designers, developers, field coordinators
Year
2023

A week after October 7th I arrived in Eilat, one of the main cities hosting evacuees from the south. I came to help with small logistics tasks, and walked out of the first meeting running this instead. After speaking with evacuees and community leaders directly, I identified a gap: approximately 40,000 people were being served with no reliable, centralised way to find relevant aid, connect with local resources or receive updates. Information was scattered across WhatsApp groups and word of mouth, and was not reaching everyone. I proposed building a communication and connection infrastructure, and was given full autonomy to execute it. This ran from October 2023 to January 2024, unpaid.

The product was never only the web page. It was partly digital, a lightweight page routing people to bots, WhatsApp contacts and aid organisation websites based on their need, and partly physical: volunteers who went into hotels in person to guide evacuees through using it.

Challenge

Evacuees were organised by their original communities but had no shared infrastructure to receive information or request help. Each community leader was operating in isolation.

The population was in acute psychological distress. "Just build a good UX" was not sufficient. People in that state needed human guidance to use even a simple tool.

There was no budget, no formal team and no existing codebase. And the timeline pressure was real: people needed help now, not in a month.

What I did

I mapped the need before building anything. Three days walking hotels and listening, then 25+ field discovery interviews with hotel managers, city welfare departments and community leaders, to understand what evacuees were asking for and what aid organisations could actually provide. I translated those interviews into a delivery roadmap.

Then I chose simplicity over sophistication. Rather than a custom app, I built a single web page with structured links routing to existing bots, WhatsApp numbers and websites, by aid type and organisation. It was the fastest path to something functional and the lowest barrier to use, operational in under two weeks.

The routing structure, showing a request entering by aid type and being directed to the relevant bot, WhatsApp number or organisation website.
The routing structure. Nothing here was built from scratch. Every endpoint already existed and already worked. The product was the decision about which one you needed.

The decisive move was not a UX fix. Standard adoption assumptions did not hold here, because what blocked usage was psychological state rather than interface design. So I deployed volunteers physically into hotel lobbies to sit with evacuees and walk them through the platform. That was the adoption unlock.

Community leaders were both research sources and distribution channels. I worked with them to understand evolving needs and to push updates out through trust networks that already existed.

I documented it and handed it over after a month, once the platform was stable, so I could move to other initiatives. It ran for 3+ months after that without me and without going down.

Adoption figures for the platform, showing roughly 70% reach across the served evacuee population.
Roughly 70% adoption among approximately 40,000 evacuees, estimated from field observation and volunteer reports, not analytics. There was no instrumentation, and building it would have cost time the situation did not have.

Alongside the platform I ran three adjacent initiatives: a free three-day hotel programme for families living under active fire near the warzone, coordinated with city welfare departments; a local kitchen network connecting evacuee families with host families so parents could cook their own food instead of relying on hotel meals; and rest events for combat units, coordinating a local chef, a venue and a DJ.

Outcome

~70% adoptionAmong approximately 40,000 evacuees served

Thousands of evacuees were connected to specific aid through the platform, observed through community leader feedback and volunteer reports. The exact number is unverified. The operation was handed off after one month and ran 3+ months afterwards with zero downtime.

Learning and reflection

The product was never just the web page. The real product was the system: digital tool, plus volunteer guidance, plus community leader distribution. Treating the page as "the thing" would have produced low adoption. Understanding what was actually blocking use, psychological state rather than UX, changed the whole strategy.

Speed required accepting imperfect tools. A custom-built solution would have been better in theory. Choosing existing infrastructure meant launching in days rather than weeks. In a crisis, a good-enough product live now beats a better one live later.

Autonomy without a mandate is still earned. I was not assigned this. I had to identify the gap, propose the solution, and build trust with hotel managers and council leaders who had no particular reason to listen to a volunteer arriving with an idea. That stakeholder work mattered as much as the product work.