Start with a pilot, not a platform. We tried to design for every use case at once — UPS last-mile delivery, BP pipeline inspection, hospital networks. In hindsight, I'd have pushed harder to pick one mission type, nail it, and expand. The scope of Version 1 made it hard to give any single workflow the depth it deserved.

​

Build the design system earlier. I built components as I went, which created inconsistency between early screens and later ones. Starting with even a lightweight system of tokens and base components would have sped up iteration and made the V1 → V2 redesign less costly.

​

Test with actual RPICs sooner. Our early feedback came mostly from business stakeholders at UPS and BP — people thinking about the system, not operating it. Getting the product in front of actual remote pilots earlier would have surfaced the urgency and cognitive load issues we only discovered during the V2 feedback cycle.

​

Push back on the map-first assumption. Everyone assumed the flight map should be the dominant element. I followed that assumption into V1 without questioning it. In retrospect, the flight list and status indicators were what operators actually needed at a glance — the map was secondary. I'd spend more time stress-testing that core mental model before committing to a layout direction.

​

Document edge cases as design artifacts. Emergency checklists, off-field landings, RPIC-unresponsive fallbacks — these were handled in conversation but rarely made it into the design files. Those states matter enormously in a safety-critical product, and I'd treat them as first-class design problems next time.