7 min read · 1,343 words

Launch Scheduling

role

Product Designer

skills

Enterprise UX
Research Under Constraint
Design Systems
Stakeholder Management
Design-to-Code

with

Kallie Laspesa
Chris Ye
Sherry Wang
Goutam Satapathy

Outcome

Consolidated scattered, fragmented workflows into one Operations Management surface, turned around the first three screens in ten days for the Space Force kickoff, and prototyped directly in code with AI before it was standard practice in the defense industry. The modernization is now expanding to the Western Range, the next launch site set to adopt it.

Challenge

StarGate is the scheduling backbone for launch ranges. It's the system that keeps the US Space Force, SpaceX, and other launch service providers from double-booking the same radar, the same frequency, or the same window at Cape Canaveral's 45th Space Launch Delta on the Eastern Range, and it's about to be adopted on the West Coast's Western Range too. It had been running as a desktop install since the early 2020s. I was brought on by Goutam Satapathy, VP of Cyber/Intel Technology, to move it to the web and modernize it, working the operations side of the product while a second designer, Kallie Laspesa, took data management.

The ask sounded simple, revamp the UI. It wasn't. StarGate wasn't broken, it was just old, dense listed views, processes split across tabs operators had to hop between to finish one task, and years of operator muscle memory built around exactly how it currently worked. Redesigning it without breaking that muscle memory was the actual job.

User Research

The domain is closed by nature, government, defense-adjacent, and not something vendors publish case studies about. There was almost no public information about launch scheduling software to work from. So I stopped trying to research the product and researched the shape of the problem instead.

Airline scheduling tools like Airplane Manager and Sabre's planning products solve a structurally identical problem with different stakes, reserving shared resources across time, surfacing conflicts before they become real, disclosing complexity progressively instead of dumping it on the user at once. That gave me a working vocabulary for the patterns before I designed a single screen.

The rules specific to StarGate had to come from somewhere else. I sat through a full recorded demo of the legacy system, the actual thing operators used, and took it apart end to end. How an operation carries a job order number. How selecting an annex pre-loads the resources tied to that operation type. How conflict analysis runs automatically at submission. How color coded blocks (orange, yellow, black) tell an operator what kind of overlap they're looking at without reading a word. None of that was in a style guide anywhere. It was only visible in how people actually used the tool.

Solution

Three screens in ten days, for a room at Cape Canaveral

The first checkpoint was a kickoff meeting at Cape Canaveral on May 15th, in person, with US Space Force stakeholders who'd be using the tool. I owed three screens by then, a resource view and the three ways operators needed to see the schedule (timeline, calendar, and list). I started wireframes on May 5th, presented working designs to the team two days later, and had final screens ready for the kickoff.

Each of the three views had to answer a different operational question. Timeline needed to flex from showing a single day to a wider range, because what an operator actually needs to see is which days an operation spans and whether it's scheduled yet. Calendar needed to hold two months of dense data at once instead of the usual month-view sparseness. List stayed close to the legacy format on purpose, because that's the view operators already had trained instincts for.

The course correction that set the rule for everything after

The feedback that mattered most at the kickoff wasn't about visual polish. It was a course correction. Lean less on ASTRO's (the design system's) default interaction patterns and more on the behaviors the current software already had. The design system bought us consistency, but operator muscle memory outranked it.

That became the tradeoff I held for the rest of the project. When a component's default behavior and an operator's fifteen years of habit disagreed, the habit usually won, and knowing which situations called for which was most of the design judgment this project actually required.

Collapsing four separate processes into one surface

I'd been handed separate processes for editing an operation, editing a major operation, creating a new operation, and creating a new major operation, each living in isolation, so routine work meant constantly hopping contexts. I proposed collapsing all of it into one surface, Operations Management, so the whole job could happen in one place. It's the kind of change that doesn't show up as a flashy screenshot, but it's the one that actually changes how someone's day goes.

That surface is also where I did the most real stakeholder management on the project. A colonel wanted "recycle dates," a scheduling detail, surfaced as a prominent, visible input instead of tucked inside a notes field. The instinct made sense from where he sat, but visible prominence for a field most users wouldn't understand risked adding confusion instead of removing it. Making that case, and finding the version that served both the rank asking for it and the operators who'd actually use it, was as much design work as anything I drew.

Two months in, changing how the work got reviewed and built

I wanted to ease the design-to-code translation for Chris Ye, our engineer, so I started experimenting with AI coding tools on my own designs, first Cursor, then Builder.io, which I found easier to work in but which burns through credits fast. It turned out to be surprisingly workable. Well-built design files do most of the work, and the rest is learning to prompt well. I shipped a responsive list view that way, built out piece by piece.

About two months after the Cape Canaveral kickoff, our engineer was asking me to sign off on the initial designs so they could move into development, which meant the Space Force stakeholders would be reviewing raw Figma files. Nobody unfamiliar with Figma learns anything from being told to "play around" in it, so I pushed to put interactive prototypes in front of them instead. He agreed, though he wanted to check what the stakeholders actually preferred first. He didn't want the shipped implementation to look different from what they'd been shown and disappoint them. I also walked him through Figma's Dev Mode so implementation specs came straight from the source file instead of secondhand screenshots, and started a user guide to lower the relearning cost of the new interface.

AI-assisted prototyping wasn't standard practice at all at the time, especially not on a defense-sector product team. It was my first time doing it, and I took it upon myself to learn it. Prototyping directly in code instead of handing off flat design files turned out to be surprisingly workable, and that initiative to learn it myself ended up being the real benefit.

Lessons Learned

The hardest part of StarGate wasn't any individual screen. It was doing real research in a domain that actively resists being researched, and then choosing, screen by screen, between the design system's defaults and the habits that research had surfaced. That judgment, more than the visuals, is what made this software something people could actually pick up and use.

The first deliverables went in front of stakeholders, and the work moved into active development, with design continuing at a slower, ongoing cadence. I left the company before StarGate's rollout was complete, so the system described here reflects the state of the design at that point, not its final shipped form.