L.O.V.E.: a control room for a telescope still being built
For four and a half years I designed the operators' interface for the Vera C. Rubin Observatory, before its main users, its data or much of its hardware existed. We built it as a framework, so Rubin's own team could keep extending it.
The subject. Rubin's telescope and its 3.2 gigapixel camera, drawn from public diagrams.SHEET 01
Client
Rubin Observatory (AURA), via Inria Chile and France
Years
Jun 2017 – Sep 2021
Role
Lead UX designer
Team
Me, 3 developers, 1 project manager
Methods
Expert interviews, component method, design system
65+systems monitored from one environmentL.O.V.E.
40+components designedL.O.V.E., 2017–2021
20 TBof data a night, once operatingRubin Observatory
4.5years, across two contractsInria Chile
01
Context
A telescope that will photograph the whole southern sky every few nights
The Vera C. Rubin Observatory, on Cerro Pachón in Chile, carries the largest digital camera ever built for astronomy: 3.2 gigapixels, covering 9.6 square degrees per image. Operators will run it from a control room that monitors more than 65 systems.
L.O.V.E. (the LSST Operators' Visualization Environment) is that control room's interface. Inria Chile and Inria France designed and built it with Rubin's team.
02
Role and team
Lead designer, from the first prototypes to the framework
I led the design across both phases: research with telescope experts, the component method, the interface and the UI framework. I worked with three developers and a project manager, and proposed a layout for the control room itself: shared screens and workstations.
03
Problem
Designing for users, data and hardware that didn't exist yet
When we started in 2017, the telescope was being built. There were no operators to watch, no live data and few final requirements. Engineers knew their own subsystem deeply, but nobody had seen the whole control room working.
The interface had to work for years of change: new hardware, new procedures and a ten-year survey plan.
04
Research
A method for each component
Without users to observe, I built a repeatable method. Every component went through seven steps:
01–02 / LearnRead the documentation, XML and databases, then interview the subsystem's experts.
03–04 / DiscussDiscuss it as a team, then sketch together.
05–06 / DesignWireframes, then mockups, reviewed with the experts.
07 / BuildImplementation with the developers, and back to experts for feedback.
Two components from the method. The ScriptQueue, which sends commands to the telescopes, and the M1M3 mirror's actuator forces.FIG. 01
05
Decisions
Build a framework, not a fixed screen
D1 · Discovery
Prototype to find the requirements
In phase one (2017–2018), prototypes in front of experts surfaced requirements that documents couldn't.
D2 · System
A UI framework operators can compose
Operators build their own views from components, so Rubin can extend L.O.V.E. over its ten-year plan without us.
D3 · Data viz
Fix the colour scale on M1M3
The existing force map's colour scale hid the values engineers needed. I redesigned its colour scale so engineers could read the forces they needed at a glance.
D4 · Scope
Design the room, not only the screens
I proposed the control room layout: which screens are shared, which are personal.
06
Result
The views operators use
Auxiliary telescope. Dome and mount in motion, with the live camera.FIG. 02
Mobile proof of concept. Monitoring components adapted for phones.FIG. 03
07
Outcome
A framework Rubin's team now extends
More than 65 systems monitored from one environment.
40+ components, documented with interaction rules and functional specs.
After my part ended in 2021, the work continued to 2023 on the framework, the main telescope and new tools.
08
Reflection
What I'd do differently
✓ What workedA method for each component kept the work moving when the users and the hardware weren't there yet.
↺ What I'd changeWithout operators to observe, the experts stood in for users. I'd test earlier with the people who will run the telescope at night, even in simulation.
