A mission control dashboard that lets one operator monitor and command a fleet of surveillance drones — flight status, live map position, and system alerts — from a single screen instead of switching between separate tools.

Right now, UAV operators manage 2–4 drones at once from ground control stations, switching between separate apps for telemetry, mission planning, and alerts. Every switch costs situational awareness — the ability to perceive fleet state, understand what it means, and anticipate what happens next.

This isn't a convenience problem. Time pressure, irreversible outcomes, and 6–8 hour shifts mean interface hierarchy functions as a safety mechanism, not a preference — whatever is buried behind a click is what gets missed.

Direct access to ASELSAN operators wasn't possible — UAV ground control is a classified environment. I built the research base from human factors literature (Endsley, Wickens), analogous high-stakes domains (NASA mission control, air traffic control), and published post-incident reviews of UAV interface failures — all read through one question: where does this interface's cognitive demand exceed what the operator can actually supply?

Before drawing screens I set three levels of information access: always visible (fleet status, active alerts, map position — zero clicks), one click (alert detail, per-drone telemetry, route status), and deliberate navigation (planning, history, settings). This maps directly to Endsley's perception → comprehension → projection model, and every layout decision below was tested against it.

Four screens, each answering a different cognitive question: what's the fleet's current state (Dashboard), is the route safe (Planning), how is each vehicle actually performing (Telemetry), and what needs my attention right now (Alerts). The operator stays on the dashboard for most of a mission — every other screen is a deliberate, justified departure.

This project pushed me to design in a register I hadn't worked in before — where a bad interface decision is operational, not reputational. That reframed every tradeoff: I was far less willing to sacrifice clarity for aesthetics, and far more disciplined about asking "what happens if the operator misses this?" instead of "does this look clean?"

What I learned

• Designing for cognitive load is different from designing for engagement — engagement asks how to make people stay, cognitive load asks what can be removed so people can think.
• Rigorous secondary research and analogous-domain analysis can meaningfully substitute for direct user access, if treated with the same discipline as real interview notes.
• Alert design is its own specialization — severity hierarchy, dismissal timing, and action framing all need dedicated thought general UI guidelines don't cover.

What I'd do differently

• Test with real UAV operators or HMI specialists, even for one session — analogous professionals validated the layout but couldn't simulate the actual cognitive demands of drone operation.
• Prototype alert timing and animation earlier — static wireframes can't surface how a 3-second dismiss lockout actually feels.
• Run a color-blindness simulation pass during exploration, not at the end, so it shapes the palette instead of forcing rework.