From rough beta prototypes to two production-ready drone platforms.

Airobotics builds automated drone systems for industrial environments — refineries, chemical plants, manufacturing facilities. When I joined, both products existed as rough Photoshop prototypes: inconsistent by screen, built without a shared interaction language, designed without a system underneath.

Over three years, I shaped two production platforms: PRIMUS for real-time mission control, and Insightful for post-flight analytics. My role spanned product design, design leadership, and building the infrastructure that let the product scale without losing coherence.

PRIMUS was a real-time operations platform where users monitored drone status, active missions, weather, and map state simultaneously. Every screen carried operational weight — a misread or missed state had real consequences in the field.

Insightful was an analytics platform designed to turn flight logs, mission history, and performance patterns into decisions operators and managers could actually act on.

What made both products difficult was the context around them. Emergency landing, parachute deployment, and Flight Termination System actions had to stay accessible under pressure — while protecting against accidental activation. These are not the same problem. Each required a different level of friction calibrated against consequence and reversibility.

Before designing the interface, I needed to understand what mistakes actually cost in the field. I started by learning the operational environment: flight procedures, control protocols, domain constraints, and the language operators used to make decisions.

Together with the PM, I clarified the main audiences behind the product — shift managers, site security managers, and senior facility managers. From there, I mapped the core tasks, the information people needed in the moment, and the consequences of delay, confusion, or accidental action during a live mission.

I began sketching early, especially around flight zones, waypoint logic, map behaviors, and high-risk actions. The goal was not to make the screens cleaner in isolation — it was to understand how the product should behave under real operational pressure.

The most important design decision in this project was not a layout or a workflow. It was proving that a design system would help engineering ship faster — and framing it that way to the right person.

When I proposed building a proper design system, the Head of Software Development saw it as overhead. The team needed features now. Design infrastructure looked like a delay — something to revisit after the product matured, not during active development.

I repositioned the system as a delivery tool, not a design exercise. Shared components, clearer patterns, and reliable handoff would reduce guesswork, prevent repeated UI decisions, and make the product easier to extend. It wasn't a cost to the roadmap — it was how the roadmap would move faster.

To keep the effort practical, I used Material Design as a starting point instead of inventing everything from scratch, and moved the workflow from Photoshop to Adobe XD so components and prototypes could live inside the working files.

A mission control interface is not a dashboard — it is a working environment where users hold multiple threads simultaneously. I structured PRIMUS around three layers: ongoing status awareness, mission management, and live spatial context.

A persistent left rail held site and drone state. The center panel handled active mission tasks. The right side gave the map room to do real work — not decorative, but operationally primary. Layout was not an aesthetic decision. It was a priority decision.

Emergency landing, parachute deployment, and Flight Termination System could not share one interaction pattern. Each action has a different consequence, a different reversibility, a different operational urgency.

Each flow carries the right level of friction — enough to protect against accidental activation, not so much that it slows a user in an actual emergency. Separate design decisions for each action, not one pattern applied uniformly.

Insightful served three audiences: operators checking their own performance, site managers reviewing fleet activity, engineers investigating issues. The same data needed to be legible at a glance and support deeper analysis when required.

Weekly summaries, mission distribution, and performance patterns were organized by what users needed to see first — not by what was technically available. The challenge was not to simplify data until it lost meaning. It was to create enough hierarchy that people could understand what mattered first, then go deeper.

Operators moved between Windows workstations in control rooms, tablets in the field, browser access, and mobile extensions. The product had to stay coherent across all of them — not identical, but consistent enough that users never had to relearn spatial logic or interaction patterns when the device changed.

Core interaction patterns held. Density and input method adapted. In high-stakes environments, users should not have to re-learn the product each time the context changes.

The team moved from rough beta prototypes to two coherent production platforms with a shared design language. Critical flows became clearer and safer. Development moved faster — because components, patterns, and handoff were no longer reinvented screen by screen.

The design system argument, won early, prevented the inconsistency that would have compounded as the product scaled. The most important outcome was not visual consistency alone. It was creating a system that helped the whole product team build with more confidence. The company was acquired by ONDAS Holdings in 2022.