A control room for a telescope that didn't exist yet
I designed L.O.V.E., the interface that runs Rubin Observatory's control room, from 2017 to 2021. In 2026 I returned to it and rebuilt it with AI, building on what operators had told me since.
Rubin needed one interface for 65+ systems before operators, live data or final hardware existed. I designed all of the original.
It now runs the observatory's control room, and Rubin's team still extends it in 2026.
In 2026 I rebuilt it with AI as a working prototype and design system: safer commands, keyboard navigation, color-blind-safe states, and a light and dark theme that follows the sun at the summit.
Part 1
The original, 2017 to 2021
Designed with Rubin's scientists and engineers while the telescope was still being built.
The bet
Rubin photographs the whole southern sky every few nights, from a control room watching more than 65 systems. When work began there were no operators, no live data and few final requirements.
The stakes are high. Rubin's first priority is the safety of the people on the mountain and of one-of-a-kind, very expensive equipment, so operators need to see at once when something is wrong. And the telescope runs a ten-year survey: every night lost to a fault leaves a gap in the data the survey can't get back.
Older telescopes split monitoring across many tools. The bet: one environment, built from components operators compose themselves, so it could grow with a telescope that kept changing.
Views indexDome and mountScript queueM1M3 hardpoints
The original L.O.V.E., as shipped.
The hard calls
Decision 1 of 3
Make the case for visualizations
As operators came on board, some asked for terminal-like views of raw values, the way older tools worked. I made the case for visualizations with side-by-side examples of what each one showed at a glance.
Result: Operators were won over: they said it looked modern and agreed it made finding data much faster.
Decision 2 of 3
Build a framework, not a fixed screen
Requirements changed with every construction milestone. Instead of finished screens, I proposed components operators compose into their own views.
Result: Rubin's team still extends it on its own, five years later.
Decision 3 of 3
Design the control room, not only the screens
Beyond the interface, I proposed a model for the room itself: which displays are shared on the wall for the whole team and which stay personal. Everyone keeps the same picture of the observatory, while each person works on their own part of it.
Result: Adopted as proposed. It increased situational awareness across the room and made collaboration between operators easier.
Outcome
There was no earlier control room to compare against. The evidence is that it shipped, is used every night, and keeps growing.
In production
Listed in Rubin's operations documentation as its control and monitoring software.
Still developed
494 commits since January 2025 in Rubin's public code repository.
My method, adopted
The designer who took over kept my per-component method and scaled it.
Part 2
The redesign, 2026, built with AI
A personal re-imagining, not an official Rubin release. All data is simulated.
Why I went back
L.O.V.E. kept growing, and operators' feedback pointed to four things it needed next:
Adapt to every screen, from a laptop to the control-room wall.
Smoother interaction: keyboard navigation and fixes for the bugs operators reported.
One accessible design system, with status that reads the same for color-blind operators.
A light and a dark theme that follow the sun at the summit.
Before and after
The main mirror floats on 156 actuators
Original, shipped2026 redesign
The original already zoomed from the whole mirror down to each actuator, with color-blind operators in mind. The redesign keeps that zoom, lists what needs attention beside it, and uses a force scale that's even easier to tell apart.
Status that reads the same for everyone
Original, shipped
EnabledRunningStandby
UnconfiguredFailed
Standby is calm gray, yellow is kept for real attention, and fault is magenta-red, which stays distinct from green for color-blind readers.
2026 redesign
The original's status vocabulary, now in one system where meaning never depends on color alone: every state has a tint, an icon shape and a label.
The dome has to keep its opening in front of the telescope
Original, shipped2026 redesign
The original paired the dome view with a live camera. The redesign puts dome, mount and target on one plan, and makes commands that move hardware unmistakable.
From conditions to a verdict
Original, shipped2026 redesign
The original brought every weather reading into one place. The redesign answers the next question, whether it's safe to keep observing, with a verdict that names its reasons.
Navigation and interaction
Operators wanted keyboard navigation from the start, but it was beyond the original's scope. The redesign adds a quick switcher (⌘ K), shortcuts to every view and pinned views, shown as ⌘ or Ctrl depending on the operating system. No single key ever moves hardware. Along the way I fixed the interaction bugs operators had reported.
The shortcuts dialog, one keypress away (?) from any view.
How I worked with AI
I directed; AI built, in under 24 hours. That was only possible because I'd spent four years on the original: the time went into decisions, not discovery.
What I brought
The original's screens and video, interviews with four users, real dome data and Rubin's documentation.
What AI built
9 views, including a new Scheduler, five guided scenarios, and a design system with both themes and 17 components.
What I decided and checked
Every design call, checked against the real system. Anything without real data is labeled illustrative.
Light and dark are designed separately; automatic mode follows the sun at the summit.
Try it
Pick a scenario and watch the control room respond. No astronomy needed.
Built for desktop. Simulated data. An independent redesign, not affiliated with or endorsed by Rubin Observatory.
What worked
The per-component method kept the original moving with no users and no hardware. Building the redesign with AI let me test decisions in working code instead of static mockups.
What I'd change
I'd test with the people who run the telescope at night much earlier, even in simulation. The redesign's scenarios are a first step toward that.
Coordinators needed four systems and 5–10 minutes to answer one performance question. I designed one tool that answers it in a single view.
Shipped
Client
NIC Chile, the .cl registry
Years
Oct 2021 to 2025
My role
Lead product designer
Team
Me, 1 developer, 1 database engineer
Built for
ReCon's annual report view, as shipped. Interface in Spanish.
The bet
NIC Chile has run online arbitration for .cl domain disputes since 2014. Coordinators report performance to the board, but the data lived in four systems and a set of spreadsheets, and some of it had never been displayed at all.
The stakes are fairness. The center exists to resolve disputes fairly, and without visibility into how arbitrators and each stage were performing, cases could take too long, an unclear process could see a dispute decided in favor of the wrong party, and leadership couldn't make decisions quickly or accurately enough. Data is how the center keeps its process fair, and shows that it is.
The bet: if the tool followed the arbitration protocol coordinators already knew, rather than the databases it came from, they could answer board-level questions themselves, in one place.
What I owned
Research sessions with coordinators, the information architecture, every chart decision, and the front end, built in code with the developer's UI kit.
Worked with: The Legal Director, the main coordinator and a legal assistant on the client side; a developer and a database engineer on ours.
Research with coordinators: what they needed to know (left), and the structure we drew from it (right).
The hard calls
Three decisions shaped the tool.
Decision 1 of 3
Organize by the protocol, not by the data source
Options
Mirror the four existing systems in tabs, or restructure everything around the 12 stages of a dispute.
Why
Coordinators think in stages. A tab per database would have rebuilt the problem inside one tool.
Early sketch: every case along the 12 protocol stages, on time (green) or late (red).
Decision 2 of 3
Choose each chart by the question it answers
Options
A standard KPI dashboard, or charts chosen per question after grouping coordinators' questions into historical, comparative and mixed.
Why
Each chart had to answer a question someone asked the board, and was tested against those real questions.
A shipped view: domains, revocation requests and cases, day by day.
Decision 3 of 3
Prototype in code, with real data
Options
Static mockups handed to the developer, or a coded front end on the developer's UI kit.
Why
Tests ran on real data shapes, and the developer started from working code instead of a picture of it.
Outcome
Measured across six sessions observing coordinators answer real questions before and after launch, in their own workspace.
Before5–10 min
per question, across 4 systems and several spreadsheets. Longer when the data had to be requested from another team.
AfterOver 90% faster
to find a key indicator, in one view.
Board reports
Period comparisons now go to the board and external stakeholders.
Clinics
Coordinators saw why legal clinics had started losing more cases.
Arbitrators
Performance data informed which arbitrators the center kept.
The arbitrators view: time per stage, and the arbitrators performing best. Names and fees blurred.Arbitrators ranked by performance, with disqualifications and ruling trends. Names blurred.
What outlived the project
The board's period-comparison report is built on ReCon. Sorting stakeholder questions into historical, comparative and mixed before choosing a chart became how I start every dashboard.
What worked
Organizing by the 12 protocol stages gave coordinators a structure they already knew.
What I'd change
Some data edge cases only surfaced once the data was visible. Next time I'd review raw data with coordinators before designing any view.
An AI ranking that widened coverage, riskiest mines first
About 50 inspectors had to choose which of 3,905 mines to visit, with records on paper. I designed a ranking that shows its reasons, and the planner inspectors used to act on it. In 2026 I rebuilt it with AI as an interactive prototype you can try.
SERNAGEOMIN, Chile's mining safety agency, via Inria Chile
Original
Oct 2018 to Feb 2019. Shipped
My role
Lead product designer
Prototype
2026, personal, built with AI
Built forSERNAGEOMIN, the national geology and mining service
2026 interactive prototype. Mock data; terrain and positions are schematic.
In short
SERNAGEOMIN, Chile's mining safety agency, wanted to inspect mines by risk instead of by calendar. I designed the explainable risk ranking and the inspection planner.
45% more mines reached with the same number of inspections, and the planner became the agency's main inspection planning tool.
In 2026 I rebuilt it with AI as an interactive prototype: the same four decisions, plus a way to question a rank, a page explaining the model, trip planning on a map and a view for inspectors in the field.
Part 1
The original, 2018 to 2019
Designed with the agency's inspection coordinator, a data scientist, a developer and an ontology researcher.
The bet
Mining is over 14% of Chile's GDP. SERNAGEOMIN inspects mines to prevent accidents, but with about 50 inspectors for 3,905 mines, every visit has to count. The agency wanted to move from inspecting on a calendar to inspecting by risk.
The stakes were human. Without visibility into which mines were most urgent to visit, a high-risk site could go uninspected, and in mining that gap can mean an accident or a death.
Two things stood in the way: inspection records were on paper, and inspectors are experts. They would not follow a ranking they couldn't question.
What I owned: five sessions with the inspection coordinator and a joined field inspection, the information architecture (the base for data entry and for the model), and every screen of the planner. I worked with a data scientist who built the model, a developer and an ontology researcher.
The hard calls
Four decisions made the ranking usable by experts.
Decision 1 of 4
Show the points behind every rank
One risk score per mine, or the score broken into five criteria inspectors can see and challenge: time since the last inspection, pending corrective measures, the accident rate, and more. Each list had its own five, as in the agency's own tables.
Inspectors trust their own experience. Seeing the reasons let them check the model against what they knew, instead of being asked to take it on faith.
Mock data.
In the 2026 prototype: the five criteria as chips on every row, orange when they add to the score; "Why this rank" opens the breakdown.
Decision 2 of 4
Rank large and medium or small mines separately
One national list, or separate rankings by mine size.
Mixed together, nearly every small mine sinks to the bottom. Separate lists keep small operations visible, where risk is often highest.
Mock data.
In the 2026 prototype: two tabs, each with its own criteria, plus an urgency level on every score and sorting on any column.
Decision 3 of 4
Plan by place
Schedule mines one by one from the ranking, or group them by where they are.
A large mine takes a full inspection day on its own. Medium and small mines close to each other can share one. A prioritization polygon groups them by distance and travel time, so a day on the road covers the riskiest sites nearby.
Mock data; terrain is schematic.
In the 2026 prototype: the polygon on a terrain map, with travel time, a suggested visit order and the riskiest mine left out of the trip.
Decision 4 of 4
One mine record instead of ten tabs
The client's draft spread each mine's data across ten tabs; the alternative was one page read top to bottom.
Inspectors do final reviews outside the mine, in poor light. One record they can scan beats tabs they have to remember. The client had drafted the tabs.
Mock data.
In the 2026 prototype: should we visit, and what should the inspector check? Main reasons first, then installations with overdue measures, then a printable visit sheet.
Outcome
The scheduler became the agency's main inspection planning tool. Inspection volume stayed constant, so the gain came from better targeting, not more visits.
BeforeCalendar
Visits planned on a fixed schedule and inspectors' memory, from paper records.
After+45% reach
More mines reached between 2019 and 2021 with about 10,000 inspections a year, the same as before. The ranking scored 2.21 relative NDCG against the experts' 1.00.
SERNAGEOMIN's broader Zero Accident program reported fewer fatalities. I don't attribute that to this tool: the program had many contributing causes.
As covered in the press
“…permite mejorar la productividad y focalizar con mayor efectividad la acción preventiva y fiscalizadora” (it lets the agency target prevention and inspection more effectively).
Alfonso Domeyko, National Director of SERNAGEOMIN, Feb 2020, Diario Estrategia
What outlived the project: the information architecture I built with the ontology researcher became the foundation for both data entry and the predictive model.
Part 2
Interactive, 2026, built with AI
The original's decisions still hold. This shows the planner working, with what's possible now. A personal project, not an agency release.
Walkthrough
About 100 seconds, captions, no audio. Mock data.
What 2026 adds
None of these were in the 2019 release. They answer what the original research pointed to: field records came back slowly, and experts who can question a rank need somewhere to say why.
Question this rank. Experts note what the score misses; the model's rank never changes.How the ranking works. What the model sees, what it doesn't, and every questioned rank.Assign on a map. One polygon per inspection day, in each inspector's colour.The inspector's view. Field checks and a visit report that feeds the next ranking run.
Also: keyboard support, text for every colour-coded value, contrast tuned to WCAG AA, colour-blind-safe inspector colours, and English and Spanish throughout. Not yet tested with a real screen reader.
How I worked with AI
I directed; AI built, in one working session, view by view, with the original screens and research as the reference.
What I brought
The original screens, research findings and the agency's criteria for each list.
What AI built
The working prototype, its maps and both languages.
What I decided
Every design call, checked against the original research. A note never changes the model's score.
Try it
Plan a week of inspections in the Aysén region: pick the riskiest mines, group nearby ones into a trip, assign inspectors, then follow one into the field.
Built for desktop. All data is invented: mines, people, scores and weights; terrain and positions are schematic; travel time is estimated. An independent prototype, not affiliated with or endorsed by SERNAGEOMIN.
What worked
Going down the mine. The lighting, the paper workflow and the travel distances shaped what the planner had to do, and they still shape the 2026 version.
What I'd change
I worked part-time on the original, which left a gap between design and implementation; next time I'd stay closer to the front end. For the prototype, the next step is putting it in front of inspectors.
Connecting space-weather data so discoveries aren't missed
Heliophysics data, papers and people sit on different platforms and use different vocabularies, so connections get missed. At a Knowledge Graphs hackathon, Harini Muralidharan and I designed a discovery tool for Helio-KNOW, a NASA-funded knowledge network led by Ryan McGranaghan at NASA JPL. In 2026 I built it as a working prototype with AI.
Helio-KNOW, NASA Heliophysics Early Career Investigator Program
Concept
Knowledge Graphs hackathon; presented at KGC 2024
My role
UX design and project management, with Harini Muralidharan
Prototype
2026, personal, built with AI
Principal investigatorRyan McGranaghan, NASA JPL
2026 working prototype. Storm activity and orbits are modeled.
In short
The heliophysics community works across separate platforms and vocabularies, so related observations, papers and people are hard to find together.
With Harini Muralidharan, I designed a discovery tool on Helio-KNOW's knowledge graph: three ways in, and a scientist's own model compared with real observations. The design was presented at the Knowledge Graphs Conference 2024.
In 2026 I built it as a working prototype with AI: a real 3D magnetosphere, conjunctions computed from orbits, and the project's own glossary.
Part 1
The concept
A hackathon project for Helio-KNOW, with Ryan McGranaghan (NASA JPL) as principal investigator. A concept, not a shipped product.
The problem
Helio-KNOW organizes space-environment knowledge as a graph: phenomena, regions, instruments, datasets, papers and people, with the relationships between them made explicit. Its focus is how energy from the solar wind reaches Earth's upper atmosphere.
The stakes are scientific. When data, papers and people live on separate platforms, under different names for the same phenomenon, a scientist can miss the observation that would confirm or challenge their model.
What I owned
UX design and project management, shared with Harini Muralidharan, with Ryan McGranaghan as principal investigator and the person we designed for. We framed the problem, designed the discovery flow, and delivered a pitch deck and a Figma prototype.
What we designed
A discovery interface on the knowledge graph, which shows results as a network, by physical location or as a table. Scientists can import their own model and map it onto the ontology, which the project calls semantic lifting.
Choice 1 of 3
Three ways into the same graph
Scientists arrive with different questions: a phenomenon, a paper, a person. Science, Publications and Researchers discovery are three entry points into one knowledge graph, instead of three separate tools.
Choice 2 of 3
The model next to what the data says
The core screen puts "Your model" beside "Identified conjunctions": the moments when two spacecraft or radars observed the same region. A scientist sees at a glance where real observations can confirm or challenge a simulation.
Choice 3 of 3
Every result can be traced
Each finding opens a details window with three parts: Details (what was observed, by which instrument, when), Co-location (where and when the observations overlap) and Metrics (the measured values, with flags and comments).
The flow
The prototype follows a scientist verifying a simulation of how the magnetosphere and ionosphere interact.
Choose a type of discovery: Science, Publications or Researchers.Import a model, then choose phenomena, analysis type and a time range.Compare "Your model" with the conjunctions found in the data.Open a result: where and when the observations overlap.
Part 2
Working prototype, 2026, built with AI
The Figma prototype showed the flow. This version works: real geometry, real computation and the project's real content. A personal project, not a NASA release.
What it does
A real 3D magnetosphere. Rotate and zoom; the magnetopause, field lines, ring current and auroral ovals change shape as a storm unfolds.Conjunctions, computed. Found from approximate orbits of missions operating on the chosen dates, each one traceable to where and when the tracks meet.The project's own content. Definitions, harmonization categories and relationships come from Helio-KNOW's glossary worksheet.Six playable scenarios, from verifying a storm-time model to replaying the original hackathon demo.
Also: model import from a CSV with columns mapped onto ontology concepts, a timeline, threshold alerts, saved queries, export as linked data (JSON-LD), and Publications and Researchers modes built from real papers and talks about the project.
Real and modeled
Real
Definitions, harmonization categories, relationships and source glossaries from the project's glossary; region names from its taxonomy; the missions and the dates they operated; the papers and talks.
Modeled
Storm activity is a simplified curve scaled to each storm's published strength. Satellite orbits are approximations. The app says so on screen.
Not claimed
No real data archives are queried. Conjunctions are illustrative, not results to publish.
How I worked with AI
I directed; AI built. I started with a research summary of the project and a rebuild of our Figma screens, then built the working app on top of them.
What I brought
Our original design, the project's glossary and region taxonomy, and its papers and talks.
What AI built
The 3D scene, the orbit and conjunction calculations, model import and the scenarios.
What I decided
The flow, what counts as real, and labelling everything modeled on screen.
Try it
Replay the May 2024 storm and watch the magnetosphere change shape, or verify a storm-time model against spacecraft passes.
Built for desktop. Storm activity and orbits are modeled. An independent prototype, not affiliated with or endorsed by NASA or JPL.
I've spent 13 years designing for people whose decisions can't wait.
Telescope operators, transit controllers, arbitrators, mine inspectors and network engineers. Their tools hold more data than anyone can read, and a wrong call costs a night of observation, a delayed bus fleet or a missed inspection.
I learn each field well enough to speak its language, design with the engineers who build the tool, and prototype in code when a decision depends on real data.
How I lead
Founding designer at Inria Chile
Set up how design, engineering and research work together in a tech-transfer center: researchers in discovery, developers as active participants in design sessions, standardized development cycles.
Winning over clients and users
Making the case with evidence: side-by-side examples that turned operators from terminal views to visualizations, and a single scannable chart that replaced a client's tabbed draft.
Methods that outlast me
The per-component method I built for L.O.V.E. was adopted by the designer who took over, and scaled to the components that followed.
AC3E (GESTIN management platform and website), Helio-KNOW, a NASA-funded research project (hackathon concept, presented at KGC 2024), LACTLD performance reports, an agricultural risk platform.
2021 to 2025
Lead Product DesignerNIC Chile Research Labs
Led ReCon, the arbitration performance tool for .cl domain disputes. Managed two interns; ran exploratory workshops for a DNS performance platform.
2015 to 2021
Lead Product Designer, founding designerInria Chile and Inria France
L.O.V.E. for Rubin Observatory, ALMA's alarm system, Cero Accidente for SERNAGEOMIN, Santiago's bus control room. Hired two designers; set up how design, engineering and research work together.
2015
Visiting ResearcherCiTIUS, Spain
Visualization and real-time interaction for 3D virtual sets.
2013 to 2015
Product DesignerNIC Chile Research Labs
UI, UX and front end for Adkintun, a mobile internet quality platform.
Education
Digital and Multimedia Communication, Universidad del Pacífico, 2014
Training
HCI residency, Inria Saclay (2016 to 2020); ACM HCI/CSCW school, Brazil (2019); Information visualization, NYU (2026)
Languages
Spanish (native), English (fluent, C1), French (B1)
AI does more of the making. I keep the judgment.
It's only as good as the brief, so most of my effort goes into the research, structure and specs I give it, and into checking what comes back.
Stage
What I do
What AI does
Research
I run interviews, observation and synthesis.
Desk research and summaries.
Structure
Information architecture and the content model.
None.
Direction
Mood boards, design system principles, tokens and component rules.
Builds the components and their live previews, in light and dark.
Explore
I pick and refine.
Wireframe and UI variants.
Build
I write a spec for every view.
Front-end code and prototypes.
Review
I check against research, structure and the system.
None.
What I check, every time
Research questions, where it sits in the information architecture, design system fidelity (tokens, components, states), and reality: real data shapes, accessibility and truthful copy.
Where I don't use it
Talking to users, interpreting what they say, and deciding what matters.
See it in practice: the L.O.V.E. redesign, a working control-room prototype and design system I directed over 21 rounds.
Product designer with 13 years designing tools for expert operators: observatory control rooms, transit crisis rooms, mine safety and legal arbitration. I learn each field's language, design with the engineers who build the tool, and prototype in code when a decision depends on real data. My work turns overwhelming data into clear decisions, and it tends to outlast my time on the project.
Experience
2023 to now
Independent Product Designer Remote
Alongside NIC Chile until 2025.
AC3E, since August 2026: Lead Product Designer for GESTIN, the management platform of a research center, and for its website.
L.O.V.E. redesign, 2026: rebuilt Rubin Observatory's control-room interface as a working prototype and design system, directing AI to build it: 9 views and 17 components in under 24 hours, with keyboard navigation and a light and dark theme.
Helio-KNOW, a discovery tool concept for a NASA-funded space-weather knowledge graph (presented at KGC 2024, rebuilt as a working prototype with AI); performance reports for LACTLD; an agricultural risk platform.
2021 to 2025
Lead Product Designer NIC Chile Research Labs
Led ReCon, the arbitration performance tool for .cl domain disputes: one view organized by the 12 stages of the protocol replaced four systems and several spreadsheets.
Cut the time to find a key indicator by over 90%, from 5 to 10 minutes per question, measured across six observed sessions with coordinators.
Prototyped the front end in code on the developer's UI kit, with real data; ran exploratory workshops for a DNS performance platform.
2015 to 2021
Lead Product Designer, founding designer Inria Chile and Inria France
L.O.V.E., Rubin Observatory: designed one interface for more than 65 systems before operators, live data or final hardware existed. It runs the observatory's control room, and Rubin's team still extends it.
Cero Accidente, SERNAGEOMIN: designed an explainable risk ranking and inspection planner for 3,905 mines. The agency reached 45% more mines with the same number of inspections.
ALMA, ESO: an integrated alarm view for 66 antennas and the buildings around them.
CMB, Ministry of Transport: a real-time map of Santiago's bus fleet for the crisis room, with incidents, alerts and a history mode. Designed and built the front end.
Set up how design, engineering and research work together: researchers in discovery, developers in design sessions, standardized development cycles.
2015
Visiting Researcher CiTIUS, Spain
Visualization and real-time interaction for 3D virtual sets.
2013 to 2015
Product Designer NIC Chile Research Labs
UI, UX and front end for Adkintun, a mobile internet quality platform.
Skills
Product design for data-heavy tools, information architecture, data visualization, design systems, field research with experts, prototyping in code (HTML, CSS, JavaScript), AI-assisted prototyping and building.
