FlytBase / Shipped product / Weather Intelligence

Weather data became flight guidance operators could inspect.

Remote drone operators needed to know whether a site was ready now or a planned mission remained viable later. I translated the brief and expert guidance into rules for which weather source to use and how limits changed during flight. The product showed the basis of its guidance while the operator kept the final flight decision.

FlytBase Docks overview with weather guidance alongside the fleet.
The shipped Docks overview shows the current verdict, its key factors, and the weather feeds beside the fleet.
My role
Product design and AI-assisted frontend / backend implementation.
Ownership
Took an assigned brief through design, build, and shipment.
Collaboration
Subject-matter experts advised source meaning and drone-operation rules.
ProblemDeciding when to fly

Operators needed to inspect the answer.

I started by assuming operators needed fewer weather dashboards. A product discussion challenged that: someone might already trust one regional service.

I designed guidance around the question being asked, the evidence allowed to answer it, and the flight phase. Operators could inspect the source and limits while keeping the final flight decision.

Current readiness

Does the available local or eligible nearby evidence support flying now?

Future viability

What does the outlook suggest for a mission planned later today or this week?

Source selectionDifferent evidence for now and later

Now and later needed different evidence.

The first step was deciding what each source could mean. With subject-matter experts, I separated local readiness, eligible nearby aviation evidence, and forecast-based planning.

The interface retained the source behind its guidance. Forecasts stayed advisory for current readiness by default, and limited or unavailable states remained visible when the evidence could not support an answer.

  1. 01

    Local sensor

    First source for current site conditions.

  2. 02

    Eligible METAR

    Nearby aviation evidence, when eligible.

  3. 03

    Forecast

    Later planning; advisory now by default.

Weather forecast outlook with a viability timeline and site map.
The outlook exposes changing viability over time instead of presenting a forecast as a live site reading.

A traceable answer

One eligible source drives the current verdict. Disagreement stays visible instead of being averaged into a reassuring number.

Less apparent completeness

A reachable forecast cannot always fill a missing current reading. Limited or unavailable states are accepted when the evidence cannot support the answer.

Flight phasesChanging limits after takeoff

The guidance changed when the drone took off.

A launch verdict stopped making sense once the drone was airborne. The language and limits needed to follow the flight, including its different launch and landing constraints.

I carried flight phase into the guidance. In-flight conditions could be nominal, need monitoring, or prompt an advisory return home, rather than label an airborne drone “grounded.”

  1. 01

    Before launch

    Ready to fly

  2. 02

    In flight

    In flight · nominal

  3. 03

    Conditions worsen

    Monitor / advisory return-to-home

In-flight guidance with flight status, weather sources, and a map.
The in-flight surface uses phase-appropriate language and distinguishes telemetry from weather sources.

Phase-aware guidance added rules and states to test, but avoided applying launch limits after takeoff. Drone telemetry stayed labeled as estimated wind resistance, giving operational context without presenting it as a calibrated weather reading.

Planned redesignSimplifying the dock overview

I planned a clearer path to the evidence.

The shipped overview made the reasoning inspectable by showing the verdict, key factors, and every feed. It also repeated evidence detail available in the dock and graph layers.

The archived PostHog checklist report recorded more actors at fleet review than at dock-decision and evidence-detail steps. The counts did not track an ordered journey or establish drop-off. I used that pattern to explore a simpler overview, with supporting evidence available on demand.

Shipped dock overview

Weather Intelligence Docks overview. Numbered outlines identify the flight decision, key factors and weather-feed status columns across the first three dock rows.
  1. The decision and its reason

    Each dock shows a verdict and its main driver. A missing required sensor can leave it with no verdict, even when other feeds are live.

  2. The conditions behind it

    Wind, gust, temperature and humidity sit beside the decision, adding detail to every dock row.

  3. Every feed’s status

    Sensor, METAR, forecast and drone-data statuses remain visible. A live feed is not necessarily the source used for the verdict.

The shipped overview placed the decision, conditions and every feed side by side. These annotations explain that existing screen; the proposed simplification below was not shipped.

The trade-off: a simpler overview, with an extra step to inspect supporting evidence. The rules for choosing the active source would stay the same. This direction was not shipped before I left.

Customer exceptionForecast fallback without a sensor

One site’s fallback stayed explicit.

The source hierarchy also met a real constraint: one customer had no local sensor and already relied on an external forecast provider.

I added an organization-level provider policy that stayed visible and kept live sensor precedence. When a later simplification removed that accepted exception, I restored it.

Weather provider settings for an organization-level exception.
Provider configuration supports an explicit, organization-scoped path rather than a silent global fallback.

A real site stays supported

An explicitly approved provider fallback supports the organization without displacing a live local sensor.

More rules to preserve

Organization-specific branching adds testing and maintenance. Simplifying to sensor-only would erase an accepted customer workflow.

Wind visualizationMaking stale wind data visible

A convincing picture could still be stale.

Inspectability also mattered in the altitude-aware wind view. I built freshness checks, field validation, diagnostics, and degraded states alongside the visualization.

A frozen field could still look believable. Its visual quality only mattered if the product made stale or missing information clear.

Regional wind visualization with altitude-aware data on a map.
The altitude-aware wind layer provides regional context while preserving freshness and failure behavior.
  1. 01

    Validate

    Check the field and manifest.

  2. 02

    Publish

    Keep the data path accountable.

  3. 03

    Render

    Handle lifecycle and diagnostics.

  4. 04

    Degrade honestly

    Make stale or missing data explicit.

Failed updates stay contained

Validated wind data is staged before the current manifest changes. A failed publish preserves the prior valid assets.

More than visual polish

Validation, staging, diagnostics, and freshness handling add operational work. Retaining an older valid bundle does not make it current.

ImplementationIntegrating and testing weather data

Real data tested the guidance rules.

From FlytBase’s shared app foundation, I translated the brief and expert guidance into rules for source eligibility, thresholds, and unreliable data.

I directed AI-assisted slices from mock states to real providers, then reviewed behavior, tests, and builds. I owned the interpretation, exceptions, and release judgment.

  1. 01

    Interpret

    Brief and subject-matter guidance.

  2. 02

    Constrain

    Rules and mock-backed edge states.

  3. 03

    Integrate

    Real sources, platform, and backend.

  4. 04

    Revise & verify

    Failures feed back into the rules.

Wrong-phase labels, old readings, and the lost customer exception sent me back to the rules, then to the interface and its checks.

OutcomeGuidance operators can inspect

Operators could inspect the guidance and keep the decision.

The shipped product connected current and future flight questions to the source, time horizon, and operating phase behind the guidance. Operators could inspect that basis and retained the final flight decision.

The planned overview asked how to make that basis easier to reach while reducing the feed detail at first glance. I now define the operator’s question and the evidence that can answer it before designing the screen.