StarGate
Launch range scheduling for a government space operations customer, off a legacy desktop tool and onto the web.
- role
- Product Designer
- skills
- Scheduling UX, Design Systems, Research, Prototyping, Design-to-Code
overview
StarGate is the scheduling backbone for launch ranges: the software that keeps operations from colliding when multiple launch service providers need the same windows, radars, and frequencies. It had been running as a desktop application since the early 2020s. I was brought on to modernize it as a web platform for a government space operations customer, covering the operations side of the product while a second designer took data management.
the challenge
The existing product worked, but it worked the way software from a decade ago works: a desktop install, dense listed views, and processes split across tabs that operators had to hop between to finish a single task. The ask was to move it to the web and modernize the interface without throwing away the operational logic schedulers already had in their heads — the thing that actually makes range scheduling work.
Two constraints shaped everything. It had to be built in the customer's existing design system, which I moved into Figma and became the team's reference point for. And it had to serve a wide user base at once: operations crews, range engineers, schedulers, and the launch service providers submitting requests from outside.
research
There is almost no public information about how launch scheduling software works — the domain is closed by nature. So I pivoted to adjacent industries solving the same structural problem: aviation scheduling tools like Airplane Manager and Sabre's planning products, where the function is the same even when the stakes differ. That gave me a vocabulary for the patterns — progressive disclosure when building a complex booking, how conflicts get surfaced, how resources get reserved — before I designed anything.
I also went through a recorded demo of the legacy system end to end, noting how operators actually moved: how an operation carries a job order number, how selecting an annex pre-loads the resources for that operation type, how conflict analysis runs at submission, and how color-coded blocks communicated overlap.
designing the views
My half of the product was the operations view — the same schedule seen three ways, each for a different question an operator is asking.
- Timeline — how operations span time. The early version showed a single day; operators needed to stretch the range, because the useful signal is which days an operation covers and whether it's scheduled yet.
- Calendar — what's happening at a given moment, two months at a time, with more data per cell than a typical month view carries.
- List — the dense, scannable format the legacy tool trained everyone on, kept deliberately.
Conflicts drove the detail work. They had to be visible on backup days, not just primary ones, and in calendar view they read as red on the time itself rather than as another color bar competing with the schedule.
Early feedback pushed me in a useful direction: lean less on the design system's default behaviors and more on the behaviors the current software already had. The design system gave us consistency, but operator muscle memory outranked it.
operations management
The clearest win came from consolidation. Editing an operation, editing a major operation, creating a new one — each lived in its own screen, so routine work meant hopping between tabs. I proposed collapsing them into a single Operations Management surface: one place to do the whole job, with fewer handoffs between contexts.
It also became the piece where I did the most stakeholder work. One requested change — surfacing "recycle dates" as a prominent input rather than keeping it inside notes — risked confusing users who wouldn't know what the field meant. Making the case for where it belonged, and what it would cost in clarity, was as much of the design work as the layout was.
design to development
Handing designs to a small engineering team meant thinking about the translation, not just the artifact. I pitched giving stakeholders interactive prototypes rather than raw Figma files — nobody unfamiliar with the software learns anything from being told to "play around" in it — and walked the engineers through Figma's Dev Mode so specs came from the source of truth instead of from screenshots.
I also started building my own designs into code with AI tooling, first in Cursor and then Builder.io, getting a responsive list view working. Well- built design files turn out to be most of the battle; the rest is prompting. It cut the distance between what I drew and what shipped.
where it stands
The first applications went to stakeholders in the summer of 2025 and the work moved into development, with design continuing at a slower cadence. I also started a user guide to reduce the relearning cost of the new interface — the kind of asset that decides whether a modernization actually gets adopted or just gets installed.