FLYTBASE
48 minutes to 90 seconds: Designed for high-stakes emergency operations
Enterprise
Emergency Dashboard
Role
Product Designer
Timeline
10 days
team
2 Branding, 1 UXR, me
platform
Web
It was 3:47 AM. A sudden heat spike flared in the foothills. Dry grass ignited. Wind pushed the flames forward. What began as a small glow spread fast-fire racing through brush, embers lifting into the air. Smoke thickened. The fire moved closer, closing the gap between wilderness and sleeping homes. No alarms. No voices. Just fire, advancing. By the time anyone would notice, it could already be too late.
The Brief
FlytBase : an enterprise platform for autonomous drone operations challenged 280 teams to design the operator experience for AI-powered emergency response. The brief was explicit: this wasn't about optimising an existing dashboard. It was a first-principles challenge to reimagine how humans and intelligent autonomous systems work together when lives are at stake.
Every team started from the same scenario: a wildfire detected at 3:47 AM. In a traditional response system, that detection takes 48 minutes to become coordinated action. With autonomous drones, the system can compress that to 90 seconds, but only if the operator interface doesn't become the bottleneck.
The core design challenge
How do you design an experience that collapses decision time from minutes to seconds?
How do you maintain operator control over a system that acts autonomously?
How do you surface critical information without creating cognitive overload?
How do you design for an operator who may be managing multiple zones simultaneously at 3:47 AM?
The underlying issue wasn't just bad UI, it was that nobody had ever looked at the complete journey. Each screen had been built separately over time, and they'd never been stitched into a coherent experience.
The Scenario
SET BY FLYTBASE · CALIFORNIA, JANUARY 2026, 3:47 AM
FlytBase provided the following scenario as the design challenge. All 280 teams worked from this same brief.
The Old Way - 48 Minutes of Chaos
3:47 AM - Sensor triggers alert
3:52 AM - Alert reaches monitoring center (5 min delay)
3:58 AM - Operator reviews sensor data, checks weather, pulls up cameras (11 min delay)
4:05 AM - Decision made: "Send someone to check it out" (18 min delay)
4:12 AM - Ground crew en route, no visual confirmation yet (25 min delay)
4:18 AM - Crew confirms: active fire, requests backup (31 min delay)
4:25 AM - Fire department fully mobilised, evacuations begin (38 min delay)
4:35 AM - Coordinated response underway (48 min delay)
By then, a small brush fire has become a threat to 40+ homes.
The New Reality - 90 Seconds from Detection to Action
3:47:03 AM - Thermal signature detected
3:47:18 AM - AI validates pattern, autonomous drone dispatched from nearest dock
3:47:45 AM - Drone airborne, operator receives alert
3:48:12 AM - Live thermal + visual feed confirms: active fire, 50m from homes
3:48:30 AM - Operator assesses situation, deploys additional drones for perimeter coverage and evacuation support
3:48:51 AM - Fire department receives: GPS coordinates, thermal map, wind data, recommended approach route
3:49:05 AM - Evacuation alerts sent to 47 households in projected fire path
3:49:30 AM - Drones coordinate: one providing live intel to fire crews, another guiding evacuation with speakers and lights
90 seconds. Detection to coordinated response. That's not just faster, that's the difference between contained and catastrophic.
But Here's the Design Problem
The operator managing this system isn't sitting in a sci-fi control room staring at one screen. They're responsible for multiple monitoring zones, dozens of sensors, several autonomous drones on patrol, and ongoing operations. When the alert comes in at 3:47 AM, they might be reviewing footage from an earlier alert or coordinating with field teams on something else entirely.
In that moment, they need to: understand what's happening (Is this real? How urgent? Where exactly?), make fast decisions (trust the autonomous response? deploy more resources?), coordinate multiple moving parts, and stay aware without drowning.
The challenge: How do you design an experience that collapses decision time from minutes to seconds without creating cognitive overload, false confidence, or loss of control?
My Approach
The research framework our UX researcher developed identified three core operator needs: situational awareness at a glance, fast decision-making without context switching, and trust in autonomous systems without losing control over them. My job was to translate those constraints into a working interface.
The foundational design principle I committed to early: one screen handles the 90-second action window. Everything else is supporting context. The operator should never need to navigate away from the Live Incident dashboard to act.
From that principle, the entire information architecture followed:
Live Incident - the operator's primary workspace for the crisis window
Incidents - post-incident review and historical context
Assets - fleet management and coverage monitoring
Insights - longitudinal system performance
Coordination - ground team and zone management
System - automation configuration and boundaries
Screen 1 - Live Incident Dashboard
THE 90-SECOND ACTION SCREEN
This is the hero screen, the one the operator lives in during a crisis. Every design decision here was evaluated against a single question: does this help the operator act within 90 seconds?
Map takes primary real estate
The thermal heatmap occupies the largest section of the screen. Spatial awareness comes first, the operator needs to know where the fire is before they decide anything else. Once they understand the geography, every other decision follows from it.
Interchangeable pinnable camera feeds
Three live drone feeds are visible simultaneously - Zone A, B, C, and a primary pinned view. The operator can click any feed to pin it to the primary position. This gives control without adding steps, one click, no navigation, no modal. The feed they need most is always where they need it.
Quick Actions permanently visible
Evacuate Zone, Abort Mission, Deploy Backup, Notify Team, Mark High-Risk, all permanently visible at the bottom of the screen. In a 90-second window, hunting through menus is not an option. These actions are always one click away regardless of what else the operator is doing on screen.
Priority Risks - the system pre-triages
The Priority Risks panel on the right doesn't just list alerts. It ranks them. The system does the triage so the operator doesn't have to. Number 1 is the most urgent. The operator reads top to bottom and acts, no mental sorting required.
Bravo Team's card is the only one highlighted in red with an alert icon. That's status-based visual differentiation, the system surfaces proximity to danger automatically. The operator doesn't need to track which team is where; the interface does it for them.
Ground Teams with live vitals
BPM and visibility range for each ground team. An operator managing a wildfire response needs to know if personnel are in danger, not just where drones are. Including crew vitals on the primary dashboard reflects the reality that this is a human coordination problem, not just a drone management problem.
Screen 2 - Incidents
POST-INCIDENT ACCOUNTABILITY AND CONTEXT SWITCHING
The Incidents screen serves two operator needs: reviewing historical incidents without leaving the application, and understanding the complete timeline of what happened during a contained event.
The Incident timeline
The timeline isn't decorative. It makes the system accountable, it shows what happened, what the system did autonomously, what changed, and in what sequence. An operator reviewing a contained incident can see exactly how the response unfolded. That builds trust in the autonomous system over time because the system's decisions are visible and auditable.
The False-Alarm tag
Most competition prototypes design for the happy path, successful detections, contained fires, correct decisions. We designed for reality. The False-Alarm status tag on resolved incidents acknowledges that the system makes mistakes. A system that only shows successes trains operators to over-trust it. Surfacing false alarms explicitly keeps operators appropriately sceptical, which in a life-safety system is exactly what you want.
This decision directly addresses one of the brief's explicit concerns: designing against false confidence.
Screen 3 - Assets
FLEET MANAGEMENT AND COVERAGE MONITORING
The Assets screen gives the operator a complete view of every drone in the fleet, status, battery, connectivity, assigned role, and last seen timestamp. It was designed to reflect real operational states, not idealised ones.
Designing for real operational states
Foxtrot-2 appears at 0% battery, offline, last seen 2 days ago, currently under maintenance. That's not a UI error, it's the truth of how a real fleet operates. Including degraded and offline states means the operator always has an accurate picture of available resources.
Sensor Health
The Sensor Health panel shows the operational status of thermal cameras, visual cameras, environmental sensors, and wind sensors across the fleet. Environmental sensors are showing degradation. That tells the operator which data to trust, a critical consideration when making decisions about fire spread and wind direction.
Screen 4 - Coordination
GROUND TEAMS, ZONE STATUS, AND SHIFT CONTINUITY
The Coordination screen is a deliberate architectural decision. All of this information, ground team updates, zone classifications, shift handover, is necessary for the operator to do their job. But none of it belongs on the Live Incident dashboard. Adding it there would create cognitive overload in the exact moment when the operator needs clarity most.
The Live Incident screen handles the next 90 seconds. The Coordination screen handles the broader operation.
Shift Handover Summary
The Shift Handover Summary is one of the most operationally considered decisions in the entire design. Most dashboards are designed for the current moment, they assume one operator, one shift, one incident. The Shift Handover panel is designed for continuity. At 14:00, Day Shift A hands over to Day Shift B. The incoming operator needs to know: current state, open risks, pending follow-ups. That's all here, in one panel, ready for handover.
Designing for the operator's full shift, not just the crisis window, is what separates a real product from a competition prototype.
Screen 5 - Insights
SYSTEM PERFORMANCE AND OPERATIONAL INTELLIGENCE
The Insights screen steps back from individual incidents to show how the system is performing over time. It separates outcome metrics from technical performance metrics, because those are two different conversations for two different stakeholders.
Success Metrics: 89% early detection rate, 127 hours saved for ground teams this month, 2,450 km² monitored, zero casualties. These are the numbers an operations director cares about.
System Performance: 2.3 min detection latency (down 15%), 94.2% confirmation rate, 5.8% false positives (down 2.4%), 4.7 min response time (down 8%). These are the numbers a technical supervisor uses to tune and trust the system.
The false positive rate appearing here connects back to the False-Alarm tag on the Incidents screen. The system tracks its own error rate over time and makes it visible. That's honest design.
Screen 6 - System
AUTOMATION BOUNDARIES, THRESHOLDS, AND FAIL-SAFE BEHAVIOUR
The System screen is the most sophisticated screen in the prototype, and the one the jury never saw due to time constraints during the presentation.
It directly answers the hardest question in the brief: how do you maintain human control over a system that acts autonomously?
Automation Boundaries
The Automation Boundaries table defines exactly where the AI's authority ends and the operator's authority begins. Three actions are fully automated, trigger fire detection alert, assign drone to hotspot, update risk assessment. The system handles these without waiting for human input because speed matters and these decisions carry lower stakes.
Four actions are manual and require confirmation, issue evacuation order, abort drone mission, deploy backup resources, notify external agencies. These are irreversible, high-stakes actions that affect people's lives. The system never takes them autonomously. An operator must confirm every time.
That line 'automated vs manual' is not arbitrary. It's a considered design decision about where human judgment is irreplaceable. This was my decision, and it's the one I'm most confident in across the entire project.
Alert Thresholds
Four configurable sliders: Fire Spread Rate, Wind Speed Alert, AI Confidence Threshold, and Crew Proximity Alert. The AI Confidence Threshold at 75% is particularly important, it lets the operator tune how certain the AI needs to be before acting autonomously. Lower it and the system acts faster but makes more mistakes. Raise it and the system is more conservative. That trade-off is now visible and configurable, not hidden inside the algorithm.
Voice Alert Settings
Critical and High Priority alerts are on by default. Medium and Low Priority are off. This is an alert fatigue solution baked into system defaults - at 3:47 AM, the operator is not being notified about routine weather changes. Only what demands attention gets through.
Fail-Safe Behaviour
Four defined failure states: system overload, multiple sensor failure, data feed delay over 30 seconds, and drone connection lost. Each has a prescribed degraded behaviour: prioritise critical alerts, reduce automation confidence, mark data as stale, disable auto-decisions. The system knows what to do when it breaks. That's engineering-level thinking applied at the design stage.
System Audit Logs
Every action by the operator and by the system is logged with a timestamp, user, action, and type (decision, detection, action, alert, approval). The operator can see exactly what the AI did and when. That's the accountability trail that makes autonomous systems trustworthy over time.
What I Learned
This was the first time I designed for a domain with no established patterns. There are no competitor dashboards to benchmark for autonomous emergency drone response. Every decision had to come from first principles, from understanding the operator's mental model, the stakes of each action, and the cost of cognitive overload at 3:47 AM.
The most important lesson: designing for autonomy is not about replacing human judgment. It's about deciding precisely which decisions humans must own and designing the interface so those decisions are impossible to miss and impossible to rush.
The Automation Boundaries table started as a simple configuration screen. It ended up being the answer to the brief's central question.
Competition Context
Design Fusion S3 was an international design competition hosted by Designare. 280 teams participated. Our team of 5 collaborated entirely remotely, across multiple cities including Bhubaneswar, Pune, Chandigarh, and Dehradun.
I led the UI design direction across all six screens and presented the full prototype to the jury.
"Great work everyone. The way you guys have presented this is definitely something that I can see being used in real life. Good job."
- Rajat Patel, Ex-Zepto · Design Fusion S3 Jury
