Autonomous Drone Security

VIEW PROTOTYPE

CHALLENGE WALKTHROUGHT

THE PROBLEM

When a drone autonomy platform detects an intrusion at 2:34 AM and launches a drone before a human sees anything, the operator doesn't need a control room. They need a decision surface.

The existing paradigm for drone operations interfaces answers one question: what is each drone doing? Tabular drone data, live video feeds, map on the right. It's built for someone piloting a system.

But when the drone has already launched, assessed the threat, and started recording evidence before the operator sees anything, that question is wrong.

The right question is: what is happening, and what does the operator need to decide right now?

Those two questions produce completely different interfaces.

WHAT I DID

I reframed the operator's role before designing a single screen.

The operator at 2:34 AM is not a pilot. They are a judge. The AI has already acted before the operator receives any alert. The interface's job is not to give them raw data to analyze. It is to give them a verdict to approve, challenge, or override.

That reframe produced three distinct operator modes across one incident.

Phase 1: Judge
The operator assesses the AI verdict and decides to trust, redirect, or escalate. The interface delivers a briefing, not a notification. One centered card. Four sections in order. Three actions. Nothing else on screen competes for attention.

Phase 2: Commander
The map expands to seventy percent of the screen. The operator speaks in outcomes. Cover east exit, not launch drone three from dock B. The system resolves the asset. The operator resolves the situation.

Phase 3: Archivist
Evidence captured itself throughout the entire incident. The operator reviews eighteen AI-curated clips, not sixteen minutes of footage, and approves three separate packages for three different audiences. Owner, police, and insurance each get what they actually need.

THE DECISIONS THAT MATTERED

Verdict states over confidence percentages

Showing 78% confidence moves interpretation work to the operator. They now have to decide what 78% means personally. That is a new cognitive task created by the interface. Verdict states give the operator something to agree with or challenge. The AI classifies. The operator decides.

The alert as a full interface state change

The instinct is to design an alert as a banner or a sidebar. The problem is that at 2:34 AM, anything competing for attention costs seconds. When the alert arrives, the map dims, the left panel deactivates, one card appears centered on screen. The operator has nowhere else to look. This is not a UI choice. It is a product decision about what the operator can afford to miss.

Deployment as outcome language

Cover east exit instead of launch drone three from dock B. The difference is five decisions collapsed into one. Which drone is available, which dock is closest, which has enough battery, which flight path avoids conflict. Outcome language gives the operator one decision. The system handles the rest.

Evidence as a parallel system

Any evidence action requiring operator attention during an active response is a design failure. The evidence strip runs passively across every Phase 2 screen. Recording, tagging, GPS logging, chain of custody. All automatic. The operator's only live evidence action is one optional tap to flag a critical moment. Nothing more is ever asked of them.

Three documents for three audiences

One export button producing one file fails everyone. The dealership owner needs a narrative. Police need legally valid video with GPS and timestamps. Insurance needs a complete audit trail. The package builder generates all three automatically. The operator reviews, approves, and sends. They do not compile.

THE EDGE CASES THAT SHAPED THE DESIGN

The happy path is easy to design. Edge cases reveal what the design actually believes.

If the operator goes silent, the system shows its next move before taking it. A visible countdown with plain language, security team auto-dispatched at zero, makes autonomous behavior legible before it happens, not explained after.

If the operator dismisses a real threat, the drone holds position for visual confirmation before standing down. A single tap dismissal is too risky. The system verifies before accepting it.

If two alerts fire across two sites simultaneously, the AI ranks them by threat confidence and asset value. The operator sees the highest priority first. They never triage manually under pressure.

HOW IT CAME TOGETHER

Five AI tools across five stages.

Claude for research and reframing. Stress testing assumptions and asking what the operator is actually deciding, not what they are doing. This is where the judge mental model came from.

Google Gemini for hand-drawn wireframe sketches from text prompts. Layout structure decided before any digital work began. Also used for the aerial night photography across the screens.

Loveable and v0.dev for UI generation and component iteration. Detailed prompts for all fifteen screens, base layouts generated, everything refined and rebuilt in Figma.

Claude again for all written documentation across the Notion research file, process page, and screen annotations.

AI handled the speed. Every design decision came from evaluating what the tools produced and often disagreeing with it.

HOW IT SHIPPED

I'd get this in front of a real security operations operator before calling it done. The operator mental model came from research and reasoning, not from watching someone sit in front of a live incident at 2:34 AM. The thinking is grounded but it needs to be tested against what that moment actually feels like under real pressure.

The evidence layer is also the part I'm least certain about. Designing evidence capture as a completely passive system feels right from a cognitive load perspective. But chain of custody in a legal context has requirements I modeled from research, not from legal practice. That layer needs to be validated with someone who has actually submitted drone footage as court evidence before it ships.