MMO for EO

Context

Where I came in

I joined the CTO Digital Transformation team for six months to work as a UX designer on the Multi-Mission Orchestrator for Earth Observation, a system that coordinates satellite acquisition requests across several missions and sensors at the same time. It sits at the centre of the ground segment, between the systems that collect user requests and the systems that actually command the satellites.

I had no prior vocabulary for any of it. The first stretch of the internship was spent learning what a satellite mission is, how acquisition planning works, what constrains it and why. That was not a detour from the design work, it was the condition for doing it: you cannot design an interface for a domain whose decisions you cannot understand.

What existed was a proof of concept. A working planning engine behind an interface that had never been designed. Every available action was exposed at once on a single screen, there was no navigation, and the interface assumed the operator already knew how the system behaved. It was functional and it was not usable, which are different things.

Problem

What the interface had to solve

The revealing number in this system is the ratio between requests and results. In the scenario I built, four hundred and fifty one acquisition requests come in and twenty are planned. The rest are refused or unfeasible, because satellites pass when they pass, sensors see what they can see, and quotas are finite.

So the orchestrator's real output is refusal, and that reframed the whole brief. The interface does not exist to celebrate the plan that worked. It exists to make refusal legible and actionable: to let an operator see what was rejected, understand why, and know what can still be done about it before the window closes. Everything downstream in the design follows from that.

Process

Designing without a brief

The project was design-driven, which in practice meant I had no clear direction handed to me. That is a harder starting condition than it sounds, because there is nothing to react against, and the process has to be defined before it can be followed.

I started with low-fidelity wireframes and abandoned them early. The difficulty in this product was never layout. It was density, state and system behaviour: whether an operator can read four hundred requests and find the one that matters, whether the status of a request is legible at a glance, what the interface does while an algorithm is recomputing. A grey box labelled "table" cannot answer any of that, and it cannot start a useful conversation with engineers either. So I moved to high fidelity, dividing the application into areas and designing each one as a real interface, then prototyping it so it could actually be used rather than described.

System

Extending a design system, not decorating it

The visual and structural foundation came from the group's existing design system, which gave me consistency with the other ground digital touchpoints for free. What it did not give me was most of the components this product actually needed.

I designed those and built them into the system: the map, a complex multi-criteria filter component, the operational data table, and an interactive timeline showing the next contacts for every asset engaged in the plan. The requirement I set for myself was that the extension had to be invisible. Someone using the product should not be able to tell which components came with the system and which ones I added, and that seamlessness is the actual measure of whether an extension was designed well or merely appended.

Scenario

A scenario as a design tool

To make the system demonstrable I built a scenario rather than a feature list. A severe flood in the Danube basin, an emergency service issuing urgent tasking requests, and three unrelated missions already running in the ground segment whose requests now have to be resolved into a single coherent plan.

The choice was deliberate. An abstract capability cannot be evaluated, a situation can. The scenario also produces the conflict the product exists to handle, because emergency response, infrastructure monitoring and agricultural observation want different things from the same satellites at the same time, and someone has to arbitrate.

Decision

Automation you can argue with

The core design problem was the relationship between the algorithm and the person.

The system computes and optimizes the plan on its own, using an orchestration criterion inherited from each mission. In the scenario, that default criterion prioritizes high-value targets, which is reasonable in general and wrong in this particular case: the emergency teams need imagery within six hours, and urgency is not what the algorithm is optimizing for. The operator can see that. The algorithm cannot.

So I designed two ways in, at two different scales. The operator can override the orchestration criteria and let the algorithm recompute the entire multi-mission plan against a different goal, which is intervention at the level of policy. Or the operator can promote a single request by hand and let the rest of the plan re-adjust around it, which is intervention at the level of the individual object. Alongside those, refused requests can be duplicated and sent to a different sensor or a different mission rather than simply lost.

This is the argument of the whole project. Automation in a critical system is only trustworthy if the person operating it has a way in, and one way in is not enough, because the mismatches between what the algorithm optimizes for and what the situation requires happen at more than one scale.

Testing

Testing, and what testing changed

I ran seven usability sessions with operators, without giving them training or documentation first, because in a system this complex the honest question is not whether people can be taught the interface but whether the interface teaches itself. I designed and moderated the sessions, collected and normalized the data, and measured usability through the System Usability Scale alongside task success rates.

The findings were then synthesized into a diagram organized by area of work, which turned a pile of observations into a prioritized agenda rather than a list of complaints. Three prototype iterations came out of that, and the final version was presented internally and reviewed with designers from the group, including the French division during recurring cross-site sessions.

Reflection

Working while the brief moved

The hardest part of the project was not complexity, it was instability. In research work the ground shifts: I would spend a week designing a component or a mechanic, and the following week a new user need would surface and change the premise, and part of the work had to be redrawn.

What I took from it is the reason I now design systems rather than screens. Screens do not survive a moving brief. Components, states and rules do, because when the premise changes you re-compose them instead of starting over. That is not a consolation, it is the practical argument for design system thinking on projects where requirements are still being discovered.

Outcome

Where it stands

The MMO is a research and pre-development product, so this case study has no adoption metrics and I will not invent any. What it has is a fully prototyped and tested second version, usability measured rather than assumed, and positive qualitative feedback from prospective operational users.

There is one more outcome worth naming. In an environment led by engineering, part of a designer's job is to make the contribution of design visible: to show that interaction, hierarchy and accessibility are not finishing work applied at the end but decisions that change what a system can do and who can operate it. Arguing that case, with prototypes rather than principles, was as much a part of these six months as the interface itself.