UX Design 2025

Autonomous Island Delivery Ops — Supervisory Dashboard

Read-only, map-centric dashboard for autonomous UAVs and maritime mothership drones enabling hub-and-spoke deliveries across Hong Kong’s islands.

Role: UX Designer Client: HKUST Robotics R&D Duration: 7 months Year: 2025
Autonomous Island Delivery Ops — Supervisory Dashboard
Autonomous Island Delivery Ops — Supervisory Dashboard

Project Overview

Client HKUST Robotics R&D
Duration 7 months
Role UX Designer
Year 2025

Skills & Technologies

UX DesignAutonomous SystemsFleet OperationsDashboardMappingR&D

Autonomous Island Delivery Ops — Supervisory Dashboard

Role: UX Designer (read-only supervision)
Organization: HKUST Robotics R&D, Hong Kong (remote)
Dates: Jan 2025 — Jul 2025
Status: R&D with limited field tests validating detection/position/status overlays; preparing for partner demos (no piloting or direct control from UI)


Summary

Designed a map-centric, read-only operations dashboard for a hybrid sea–air delivery network in Hong Kong. The system uses autonomous UAVs for last-mile island deliveries and maritime “mothership” drones for sea legs, addressing over-water flight constraints and battery limits. The dashboard provides situational awareness, handoff visibility, and exception management across the hub-and-spoke model while remaining strictly supervisory.


Why this project existed (R&D team’s idea)

Hong Kong is a maze of dense city and far‑flung islands. The R&D team’s idea was simple but bold: use autonomous maritime drones (“motherships”) to ferry delivery UAVs close to islands, then launch short over‑water UAV hops to complete last‑mile drops. That sidesteps long, continuous over‑water flights (which are restricted) while expanding reach.

Why they needed a dashboard:

  • Real‑time situational awareness for two vehicle types moving in concert (sea + air).
  • Safety + compliance in a constrained airspace with geofences and no‑fly rules.
  • Maintenance & triage for a fully autonomous fleet (no pilots → the UI becomes the “pit crew”).

Problems to solve:

  • Orchestrate mothership ↔ UAV pairing (who’s deployed from where? how far?).
  • Surface only the telemetry that is needed (battery, link, GPS confidence).
  • Predict and warn before bad things happen (pre‑violation of geofence, low reserve for RTL).
  • Give maintenance fast hand‑offs from ops (anomaly → ticket), and vice versa.

How I got involved (the human bit)

I first met the team in Tallinn. I was visiting Tallinn University when a group from HKUST was there finalizing summer‑school course partnerships. That’s where I met Marco, part of the drone systems R&D group—he owned the mothership↔drone link, manufacturing, and landing systems.

We bonded over finite state machines (FSMs) in robotics—I’d worked with FSMs during my student years, and we quickly dove into state transitions for launch/recover cycles and failure modes. We kept talking, found common ground, and agreed to collaborate. I joined the project on behalf of Limina Agency to design the dashboard and component system around their autonomy stack.

The tech (in plain language)

Think of the stack as sensors → MAVLink → server → web UI:

  1. Vehicles emit telemetry via MAVLink. Position, attitude, battery state (including per‑cell health), link quality, GPS fix type/HDOP, mission progress.
  2. Backend ingests and normalizes it. We mapped MAVLink messages to a stable API (e.g., GLOBAL_POSITION_INT → position/heading/speed; BATTERY_STATUS → pack %, temps, per‑cell deltas; HEARTBEAT → mode/arming). We streamed live updates via WebSockets.
  3. UI renders in real time. The browser subscribes to updates and paints the map, cards, and alerts. We added range rings for motherships (legal over‑water radius for UAV hops), geofence overlays, and breadcrumbs for playback.

What took time: getting a reliable MAVLink → server → UI link, and agreeing on which telemetry actually mattered for operations vs maintenance. We iterated: start lean, add only signals that changed operator decisions.

Users & Jobs-To-Be-Done

Ops Supervisor (Primary)

  • See the whole network status at a glance.
  • Identify/triage exceptions before they jeopardize SLAs.
  • Verify capacity (deck space, charge bays, island pads) against demand.

Field Technician (Secondary)

  • Prepare pads/chargers and deck areas.
  • Respond to on-deck or pad-side exceptions flagged by the UI.

Partner/Client Viewer (Tertiary)

  • Read-only visibility for a specific island/route (service health, ETAs).

Goals

  1. Real-time situational awareness across sea and air legs.
  2. Handoff transparency (UAV ↔ mothership) with clear queues and capacity.
  3. Actionable exceptions with minimal alert noise.
  4. Post-ops playback for incident review and SLA reporting.
  5. Strictly supervisory: no command/control, no piloting.

Constraints & Assumptions

  • Vehicles are fully autonomous.
  • UI is read-only: acknowledges alerts, filters views, exports data.
  • 4G/5G provides primary connectivity; LoRa supplies degraded updates.
  • R&D phase with limited validation of detection/position/status overlays.

Solution Overview

Map-First Overview

Clustered markers, mission-phase colors, ETA halos, weather/sea-state overlays.

Mothership Detail

Deck/charge capacity, launch/landing queues, UAV manifest, next departure ETA.

Island Hub View

Inbound batches, pad availability, demand backlog, recent exceptions.

Mission Timeline (per UAV)

Event stream from preflight to RTB/charging.

Alert Center

Prioritized exceptions with acknowledgement flow and playbook snippets.

Playback & Reporting

Time-scrubbed visualization with CSV export for SLA audits.


Mission Phases (Canonical Labels)

Preflight → Launch → Transit-to-Mothership → On-Deck → Sea-Transit (Batch) → Island-Sortie (Deliver/Return) → Return-to-Mothership (RTM) → Return-to-Base (RTB) → Charging → Idle/Ready)


Information Architecture (Routes)

  • /overview — Live map, fleet KPIs, filters
  • /mothership/:id — Deck & charge capacity, queues, manifest, ETAs
  • /island/:id — Pads, inbound batches, demand backlog, weather
  • /mission/:id — Timeline, events, KPIs, export
  • /alerts — Triage, acknowledge, notes, runbooks
  • /playback — Time scrub, compare incidents, CSV export
  • /reports — SLA and utilization summaries

Core Entities & Fields (Data Contract)

UAV

  • id, callsign, battery_pct, health, payload_kg
  • mission_phase, position{lat,lon,alt}, eta, link{primary:4g5g|lora, status}
  • last_telemetry_ts

Mothership

  • id, position{lat,lon}, sea_state, speed_knots
  • deck_slots{total, used}, charge_bays{total, used}
  • queue_launch[], queue_land[], manifest_uav_ids[]
  • next_departure_eta

IslandHub

  • id, name, pads{total, free}, demand_backlog, service_window, weather

Mission

  • id, uav_id, mothership_id, route, waypoints[]
  • phase, events[], start_ts, end_ts, sla_target

Alert

  • id, severity{info|warn|alert}, category, subject_ref, started_at
  • status{open|acked|resolved}, notes[], playbook_ref

Alert Taxonomy & Behavior

Categories

  • Comms: heartbeat missed, LoRa-only, telemetry stale
  • Energy: battery critical, charge bay unavailable, charge overrun
  • Ops: deck full, pad blocked, handoff delayed, manifest mismatch
  • Env: high wind, precipitation cell on route, swell over threshold

Behavior

  • Priority queue; ack → own → resolve workflow
  • Correlate duplicates and apply cooldown windows
  • Link to short runbook per alert type
  • Role-based visibility (Supervisor vs Viewer)

Visual Language & Design System (Ops-Grade)

Density

Compact 8-pt grid, keyboardable controls, large map targets.

Color Semantics (WCAG AA)

  • Phase (informational)
  • Warning (threshold breach)
  • Alert (immediate action)
  • Muted (historical/past state)

Iconography

Phase glyphs; battery & health micro-charts; sparklines.

Tokens (sample)

  • radius.sm/md/lg, space.2/4/8/12/16, font.ui-12/14/16
  • color.phase.*, color.state.warn, color.state.alert, color.text.muted

Component Inventory (React/TypeScript)

  • Map Canvas (vector tiles + deck.gl) with clustering & ETA halos
  • Entity Badges (UAV/Mothership chips with live stats)
  • Capacity Bars (deck, charge bays, island pads)
  • Queue Lanes (launch/landing; read-only, scrollable)
  • Event Timeline (per mission)
  • Alert Drawer (triage, ack, notes)
  • Playback Scrubber (24h default)
  • KPI Tiles (on-time batches, dwell variance, comms health)
  • Theming: tokenized dark mode; high-contrast focus states
  • State: React Query + Zustand/RTK for store; WS live feed

Integration Pattern (High-Level)

Storage: time-series DB for telemetry; relational DB for entities & events
Simulation: deterministic replays + noise injection for testing


MVP Scope (Once Data Feed Is Ready)

Must-Have

  • Live positions & phase coloring for UAVs/motherships
  • Battery/health, basic ETAs
  • Deck/charge capacity & launch/landing queues
  • Alert center (Comms/Energy/Ops/Env) with ack flow
  • 24h playback + CSV export

Nice-to-Have

  • Weather/sea overlays (wind, swell)
  • SLA dashboard (on-time batches, dwell variance)
  • Basic demand forecasting per island

KPIs & Success Metrics

  • Time in unknown state (telemetry stale)
  • Failed handoffs per 100 sorties
  • Deck dwell time variance
  • On-time batch departures
  • Alert noise (duplicates/hour) ↓ with maintained coverage

Risks & Mitigations

  • Telemetry sparsity / LoRa-only: show confidence bands; conservative ETAs; stale-data badges
  • Over-alerting: correlate related alerts, per-entity thresholds, cooldowns
  • Map overload: progressive disclosure; cluster by role; hover-to-detail
  • Env data gaps: cache last known + “stale” label; manual annotation fallback

Test Plan (R&D-Focused)

Golden-Path Replay

Known mission with expected timestamps.

Edge-Cases

Deck full, pad blocked, comms degraded, sudden squall.

Usability

5-minute “find & explain” ops tasks (time-to-insight).

Performance

500 UAVs + 10 motherships in playback; steady 15 FPS map.

Accessibility

Keyboard traversal of map markers; AA contrast audits.


What I Delivered

  • Information architecture, user flows, supervisory constraints
  • Interactive prototypes (map + detail panels + alert triage)
  • Capacity/turnaround models (deck slots, pad queues, charge utilization)
  • Alert taxonomy & exception paths
  • Compact component/token system for React/TypeScript build
  • Validation of detection/position/status overlays in limited tests

Outcomes & Next Steps

  • Shared situational awareness across sea/air legs and queues
  • Ready for partner demos (delivery companies)
  • Next: predictive ETAs, what-if capacity checks, richer playback analytics

Screens / Assets To Include (Placeholders)

  • Map overview with clustered fleet
  • Mothership detail: deck/charge + queues
  • Island hub view: pads, inbound batches, backlog
  • Mission timeline (per UAV)
  • Alert center with ack flow
  • Playback with time scrub

Replace this section with final screenshots or short clips.


Implementation Notes (Engineering Hand-Off)

  • Tech Suggestion: React + TypeScript, Vite; Mapbox GL + deck.gl; React Query + WS
  • Security: JWT + short-lived WS tokens; read-only roles (Supervisor/Viewer)
  • Logging: audit trail for alert acks, filters, and exports
  • Availability Target: 99.9% viewer uptime (R&D goal)

Timeline & Collaboration

  • Jan–Mar 2025: Problem framing, IA, phase grammar, alert taxonomy
  • Mar–May 2025: Interactive prototypes, capacity models, visual tokens
  • May–Jul 2025: Limited tests validating detection/position/status overlays; demo prep

Disclaimer

This dashboard is strictly supervisory. No piloting, commanding, or direct actuation is exposed in the UI. All vehicles operate fully autonomously; human operators supervise status and exceptions only.


Table of Contents