Case study
Dronisos — Safety Reporting System
Redesigning post-mission reporting for drone swarm operations
Context
Dronisos designs light-show drone performances for theme parks (Disneyland Paris, Puy du Fou, Dollywood) and premium events. Operations rely on an internal software ecosystem: Symphony for 3D choreography, Orion as the RTK base, and the DCC (Drone Control Center) as the swarm pilot station. Every flight is regulated by the French DGAC: traceability of mission data is a regulatory obligation, not a documentation comfort. I joined the team as a Product Designer, and very quickly the writing of the project’s PRD was entrusted to me, which led me to carry both the product vision and the design direction.
Problem
After each flight, the DCC automatically generated an internal, hard-to-read tabular PDF report. In practice, no one opened it. The flight director was instead writing a Slack message summarising wind speed, battery state, incidents; an operator then re-entered this information into a non-standardised Google Sheet. Result: about 20 minutes of manual work per mission, three contradictory sources of truth, and a post-flight analysis structurally impossible to industrialise. For a company whose safety is the primary commercial argument, this tooling gap was becoming a risk.
Challenge 01 — Understanding why the report was not being read
The challenge: before redesigning the interface, understand why an already-automated artefact had been abandoned by its own users.
My approach: in Sprint 1, I ran interviews with flight directors, field operators and the analysis team. The existing report mixed, without hierarchy, raw telemetry data, technical fields aimed at developers, and the indicators actually useful to debriefing. The tabular format made it impossible to quickly isolate critical information, notably exceeding the 35 km/h wind threshold, which conditions the decision to take off.
Outcome: a three-layer needs map (immediate field decision, operational debrief, regulatory archive) that served as a grid for everything that followed.
Challenge 02 — Designing an editorial report fitting on two pages
The challenge: render the telemetry of a flight in a document scannable in less than a minute by a flight director, while remaining compliant with DGAC expectations.
My approach: I treated the report as an editorial document, not as an admin view. Page 1: an Operator Feedback block open to free input from the flight director, a Quick Summary with four indicators (Flight Score, Pyrotechnic Firing, Hotswaps Used, Detected Issues), the Flight Details and the Wind Summary. Page 2: the System Versions and the Issues & Errors table qualified by severity. I built a dedicated design system in Figma (foundations, Vuetify 3 components, workflows and states) documented across seven iterations versioned with the developers.
Outcome: a single deliverable that simultaneously replaces the abandoned PDF, the manual Slack message and the Sheet re-entry.
Challenge 03 — Wiring the interface to the data pipeline
The challenge: the report only has value if its generation is reliable, automated, and its archiving traceable.
My approach: I led the pipeline design with the PM: ingestion of .ulog and .bin logs, correlation with anemometer data, PDF generation from the DCC’s Analysis page, automatic deposit in the DGAC-compliant Google Drive tree, Slack notification to the flight director with a direct link. On the UX side, the stake was to keep a human control point: the flight director can edit the report before archiving, but the default path requires no action.
Outcome: end-to-end centralisation of the contractual flows, from raw data to regulatory archive.
The interviews as a source of truth
During the interviews carried out in Sprint 1, the flight directors expressed a shared observation: after each flight, they spent more time manually compiling the information than analysing it. The double entry (Slack then Google Sheet) wasn’t a preference, but a symptom: the existing automated report addressed no real use case.
Sprint 1 interview synthesis (flight directors, field operators)
Iterations and design decisions
V0 proposed a single dense page, close to a dashboard. Internal tests showed it reproduced the original report’s flaw: too many signals, no hierarchy. V3 introduced the editorial break (Operator Feedback as opening, visual Quick Summary, Issues & Errors at document end) and the move to two pages. The decision to keep two pages rather than one was defended with the PM: explicit pagination allows field printing and improves linear reading, two needs raised by the operators. V4 to V6 refined the typography and the qualification of incidents by severity; V7, delivered as the Sprint 3 handover, is the one running in production today.
Results and impact
- ~20 minutes saved per mission on post-flight analysis.
- 100 % centralisation of the contractual flows, from telemetry to DGAC archiving.
- Critical wind threshold (35 km/h) made immediately legible on the report and in the Slack notification.
- Regulatory compliance ensured by automated archiving on Google Drive.
- Versioned design system (seven documented iterations) handed over to the dev teams in Sprint 3.
Reflection
This project confirmed to me that an abandoned deliverable is not always a design problem: it can be a product framing problem. Carrying the PRD in parallel with the design allowed me to align the technical scope with the real business needs, with no intermediate filter.
The regulatory constraint (DGAC, traceability, archiving) turned out to be a decision accelerator rather than a brake: it forced the team to choose a single source of truth, which simplified the architecture.
If I were to redo the project, I would invest earlier in tests with field operators. The flight directors were consulted from Sprint 1; the operators who use the report on the move on tablets were only brought in at Sprint 2. The tablet aspect was caught up later, but it would have benefited from being framed earlier.