FireAid
A peer-to-peer system for evacuation and aid requests
USE ARROWS
CLICK TO OPEN
PROBLEM
00 - OVERVIEW
FireAid is a concept UX/UI project exploring how communities coordinate during wildfire emergencies when official systems fail to reflect real-world conditions.
The project reframes emergency tools from broadcasting static alerts to enabling real-time, peer-to-peer situational awareness — allowing people not just to receive information, but to contribute it.
Post-project validation: In late 2025, real-world events mirrored this exact behavior at scale, reinforcing the core logic behind FireAid (covered below).
Tools: Figma, FigJam, ProtoPie (high-stress interaction testing)
Team: 3 designers Timeline: 3 weeks (2024)
My Role: End-to-end UX/UI, research synthesis, interaction design
01 - THE MOMENT IT BROKE
During Canada’s 2023 wildfires, 232,000 people were evacuated.
Information existed but coordination didn’t. One evacuee recalled:
“We wouldn’t have known the fire was coming if my spouse hadn’t driven by.”
— Lac Ste. Anne County evacuee (CBC)
People relied on neighbors, text messages, and word of mouth to decide when to leave and where to go.
The gap wasn’t data — it was shared, localized awareness.
Emergency systems answer: “Where is the fire?”
Evacuees are asking: “Who near me needs help — and which way is safe right now?”
SOLUtion
02 - Designing for Coordination, Not Consumption
Early research across first-responder interviews, news reports, and disaster recovery guides revealed three consistent breakdowns:
Fragmented communication
High cognitive load under stress
No mechanism for evacuees to help each other in real time
Instead of layering more alerts, FireAid centers on a single idea: Let people mark reality as they experience it — safely, visibly, and quickly.
This led to a unifying interaction model that supports both alerts and aid requests without separate flows.
03 - Live Labels: One Interaction, Two Critical Needs
standard multi-step reporting vs FireAid’s live label
In crisis conditions, every extra decision slows people down.
FireAid reduces the system to one core action:
Mark location
Select what’s happening
The same interaction handles:
Alerts: Fire, smoke, roadblocks
Aid requests: Medical help, shelter, supplies
No menus. No setup. No tutorial.
Result: An interaction that remains usable when cognition breaks down.
04 - Trust Without Slowing Down: A Proposed Logic for Truth
unverified → verified progression
Speed without trust can be dangerous in a crisis. To solve this, I proposed a Proximity-Based Trust Threshold for the backend architecture.
The Logic:
Unverified Entry: A new report (e.g., "Road Blocked") appears as a low-opacity, "unconfirmed" marker on the map.
Geographic Confirmation: The system only escalates a report’s visibility after multiple, unique users within a specific GPS radius report or confirm the same incident.
Self-Correcting Network: Visibility scales with geographic confidence, not just volume, ensuring the map remains a source of truth rather than a reflection of noise.
Why this matters: In a crisis, the greatest risk isn’t missing data — it’s acting on the wrong data. that could lead evacuees into danger. By proposing a backend verification logic, I moved the project beyond a "mapping tool" and into a Trust Framework, ensuring that speed never compromises safety.
05 - Navigation That Admits Uncertainty
AI route overridden by community input
Traditional GPS systems fail in fast-moving disasters by assuming conditions are static.
FireAid treats navigation as a living system:
User-reported roadblocks instantly trigger reroutes
Community-confirmed paths override algorithmic guesses
When data is thin, human signals take priority
Instead of pretending to be certain, the system adapts in real time.
06 - user testing under stress
Testing Under Stress: From "Polished" to "Hardened" I conducted a pilot study with 5 participants using structured interviews and think-aloud protocols.
Key Friction Points Identified:
Interaction Failure: "Live Label" interactions were confusing under pressure; users needed immediate, contextual guidance rather than a broad tutorial.
Accessibility Gaps: Participants struggled with button sizes and found the color scheme lacked the necessary contrast for high-stress legibility.
Engagement Barriers: A lengthy onboarding process was viewed as a fatal flaw—preventing immediate access to life-saving features.
The Iteration: Engineering for Impact I moved away from standard "app aesthetics" and following google maps icon layout toward Brutal Clarity:
Hardened UI: Increased touch targets by expanding button size and implemented a high-contrast color system to ensure legibility in smoke-filled or high-glare environments.
The "Emergency Skip" Onboarding: I redesigned the entry flow to allow users to skip onboarding entirely. This grants immediate access to the map and aid requests, but restricts reporting functionality to verified accounts—balancing immediate speed for the victim with data security for the system.
Modular Information Layering: To prevent cognitive overload, I kept information modular. Detailed wildfire updates were nested behind a progressive disclosure model, ensuring users only see what is critical to their immediate survival.
Option to skip the Lengthy Onboarding
Grouping core features by priority and utilizing progressive disclosure to move secondary data off the primary path. Also, Increased Button size according to the feature priority.
The Result: In final testing, the refined "Live Label" interaction allowed users to signal for help or report an incident in under 3 seconds with zero prior instruction.
Result
07 - Post-Project Validation (2025)
Crowdsourced app used to track the residents. Green = safe, red = missing. Credit: 9News
In November 2025, during the fatal Wang Fuk Court fire in Hong Kong, official infrastructure reached a breaking point. As government alerts lagged, residents were forced to engineer their own survival tools, creating a real-time, suite-by-suite census to track hundreds of trapped neighbors.
This wasn't just a "feature" of FireAid—it was the core thesis enacted in a life-and-death scenario.
The Hong Kong crisis proved that when centralized systems fail, peer-to-peer coordination is not a backup; it is the primary lifeline. FireAid didn’t just predict a UI trend; it identified a fundamental human survival behavior that emerges when institutional systems fall short.
08 - Reflection
This project shifted my perspective on what "good UX" looks like. In most industries, we design for delight; in emergency response, we design for survival.
What I Learned:
Aesthetics vs. Utility: "Clean" design is a liability in a crisis. I learned to kill my darlings—sacrificing minimalist beauty for "Brutal Clarity"—because a pretty interface that is hard to see in a smoke-filled room is a failed product.
The Ethics of Crowdsourcing: Designing the "Trust Threshold" taught me that designers are responsible for the data their systems generate. In high-stakes environments, the risk of misinformation is as dangerous as the fire itself.
The Power of Heuristics: When cognitive load is at 100%, people don't read; they recognize. Leveraging universal symbols and bold labels proved more effective than any onboarding flow.
Future Considerations:
Low-Connectivity Resilience: Wildfires often destroy cell towers. My next step for FireAid would be investigating Mesh Networking (Bluetooth/P2P) to allow devices to share peer-to-peer data even when the internet is dark.
AI vs. Human Agency: As AI-driven evacuation routing matures, the challenge will be maintaining human trust. I want to explore how to transparently show a user why a route has changed based on a neighbor's report, balancing algorithmic speed with human verification.
Inclusive Survival: Future iterations must account for accessibility under stress—specifically for elderly residents or those with mobility impairments who cannot "evacuate quickly" and need a specific subset of the "Aid Request" feature.
09 - Thank you
A high-stakes crisis.
A fragmented response.
A resilient, community-driven solution.
