Earth Observation (EO) Image Acquisition Planner Application
Quentin Brohan
Earth Observation (EO) Image Acquisition Planner Application for satellite operators
Role: UI Developer
Client: Leanspace, Strasbourg
Year: 2024-2025
Overview
Five years at Leanspace designing interfaces for commercial satellite operators. The Earth Observation Image Acquisition Planner (IMAQ) is the product I was most embedded in — a mission planning application for remote sensing operators whose primary goal is to fulfil as many customer image requests as possible.
Manual planning is painful for EO operators: alongside imaging activities, they need to account for station keeping, flight software updates, multi-band downlinks, orbit maneuvers, and more. The IMAQ Planner gives operators a single interface to manage all of it — with human-on-the-loop automation so operators only step in when something actually needs their attention.
The work I contributed to supported €10.5M in France 2030 funding and drove +48% ARR for Leanspace.
“Quentin is a hard worker who you want to invite into your design process as early as possible. Regardless of the topic — ranging as diverse as astrodynamics, UX or a hackathon event — if you tell him your vision and give him some reference material, he will amaze you with the outcome. He has this incredible talent to be introduced to a brand new subject, study it, draft up possible solutions and then completely change your mind about where the real value exists.” — Patrick Connolly [Product Manager, Solutions Architect]
The Problem
EO operators receive image acquisition requests from customers — some routine, some urgent (natural disasters, military, time-sensitive targets). They need to schedule those requests against satellite passes, manage onboard resources (battery, memory, propellant), handle collision avoidance, and push a validated plan to mission control before the next ground contact.
The existing workflow was fragmented and manual. Operators ran separate planning instances per satellite, did resource math in spreadsheets, and had no safety net before committing a plan. The challenge we set out to solve:
How do you make a technically complex plan feel manageable to an operator under time pressure?
How do you surface constraint violations before they become mission risk?
How do you handle urgent replanning — even moments before a pass — without breaking the active schedule?
What I Designed
The planning interface is organized around a central timeline with user-defined swimlanes by activity type: Resource release, Contact, Imaging, Solar charging, Orbit maintenance maneuvers. Each swimlane makes payload and platform activities visible side by side — operators can see at a glance whether the bus can support the imaging schedule.
Request handling sits upstream: operators receive, track, and prioritize customer image requests. Feasibility checks run automatically against orbital windows. The system supports mesh decomposition — complex polygon AOIs are broken into multiple acquisition opportunities.
The plan template feature lets operators scaffold a standard ops sequence (imaging cycle, maintenance window, downlink pass) in seconds. Define a T0, all activities instantiate at their relative offsets. Critical for operators managing recurring mission patterns without rebuilding from scratch every cycle.
Resource and constraint modelling runs on every draft edit. Simulated resource curves (battery, memory, propellant) update live as activities are added or moved. Violations surface immediately, not at commit time.
The compare screen is the last checkpoint before anything goes to mission control. Removed activities in red, new activities highlighted, summary counts. You see exactly what you're committing before it becomes a telecommand.
Small details matter in dense UIs: the activity popover gives operators immediate context (name, execution time, duration, priority, impacted resources, status) without leaving the timeline view.
Design Decisions
Human-on-the-loop, not out-of-the-loop. The automation goal was never to remove operators — it was to make their interventions deliberate. Notifications only when there's a conflict requiring a decision. Quiet when everything is nominal.
Dark navy theme. Mission operations run in low-ambient-light environments. The Leanspace design system uses dark navy as the base, with teal for active/committed activities and orange for warnings and brand accents. Contrast and color semantics are load-bearing in this UI — operators decode status at a glance.
Swimlane layout. Separating activity types into named swimlanes means payload scheduling and bus scheduling are visually co-located but distinct. Operators see resource contention spatially, not in a table.
Safe replanning by design. To replan, you duplicate the most recent plan and adjust — the master stays intact until you explicitly commit the diff. Only constraint-validated, committed plans can generate telecommands. Audit history is always accessible.
Platform and payload agnostic. The planner supports optical, SAR, and RF payloads, and is bus-agnostic. Design decisions had to avoid hardcoding assumptions about what a "payload" or "resource" meant — the activity and resource models are generic enough to work across mission types.
Outcomes
The EO Image Acquisition Planner shipped as a customer-facing product within Leanspace's MPS suite. My contributions across product design, research, and usability testing supported:
€10.5M France 2030 grant secured
+48% ARR generated
5M€ contract win with a key customer
First paying MPS customers: Clearspace, Infinite Orbits, Promethee
The Figma files and prototypes were used as the demo foundation for the solutions team across EO, Hosted Payload, and In-Orbit Servicing prospect presentations.
What I'd Do Differently
The resource constraint editor should have been operator-accessible from the start. During early phases, impact values (how much battery an imaging activity consumed, how much memory a downlink recovered) were hardcoded in scripts and required backend access to tune. That's a gap that slowed down every customer onboarding.
I'd also push for a clearer separation between "what the algorithm decided" and "what the operator changed" in the plan history. Operators working with automated scheduling need to know which activities were touched by automation versus manual edits — it's important for accountability and debugging.
Tech Stack
Design: Figma, Miro (user flows, workflows, usability testing)
Frontend: React, TypeScript, TailwindCSS, MUI
Platform: Leanspace MPS microservices — Plans, Activities, Resources, Orbits, Passes, Requests, Dashboards APIs
Integrations: Exotrail (flight dynamics), Leafspace (ground station network / GSaaS), Celestrak / SpaceTrack (TLE / orbital data), Cesium (3D geospatial visualization)
Like this project
Posted Jul 27, 2026
A mission planning app for Earth Observation (EO) operators to optimize image capture and manage dynamic requests within satellite constraints.
Likes
0
Views
1
Timeline
Jul 24, 2024 - Apr 1, 2025
