Where We Started

We came into this project through Teague, a global design and innovation consultancy, not through a NASA contract or an existing space-company relationship. Teague had hoped to pair us with an external space company as the direct client. That partnership didn't come together, so Teague became our client and partner directly. That worked in our favor: it gave us the freedom to explore the space domain broadly, with a general pointer toward mission control, rather than inheriting someone else's predefined problem.

Research Approach

As a team, we researched adjacent industries to understand how other safety-critical or highly automated domains handle a structurally similar problem: keeping a human meaningfully in the loop of a system built to mostly run itself. That research spanned defense platforms (Palantir, Anduril), aerospace autonomy (Lockheed Martin, Northrop Grumman), and ongoing news coverage of autonomy efforts at NASA, Blue Origin, SpaceX, and VAST.

I led the competitive analysis on autonomous vehicles, focusing specifically on Waymo and Aurora.

Waymo operates its self-driving fleet using what it calls Fleet Response Agents: human operators who step in only when the vehicle itself decides it needs help. The interaction is structured as a question-and-answer exchange, not open-ended remote control. The vehicle asks a specific question, the agent answers, and the vehicle continues making its own decisions using its own sensor data throughout, even after receiving that input. If the vehicle determines stopping is safest, it stops regardless of what the agent suggests. That distinction, between a system that asks for input while retaining authority versus one that hands off control, became a reference point for how I thought about human oversight for the rest of the project.

I also tracked a February 2026 Congressional hearing where a Markey investigation into seven autonomous vehicle companies found that none would disclose how often their remote operators actually intervened, and that Waymo was the only company relying on overseas operators, some without valid US driver's licenses. That gap between what companies claim about their automation and what they're willing to make transparent felt directly relevant to a domain like mission control, where trust in a system has to be earned through demonstrated reliability, not asserted.

Aurora takes a different technical approach with what it calls Verifiable AI: a learning model handles judgment-heavy tasks like merging and reading other drivers, while a second layer of hard, non-negotiable rules sits on top and can override it for the rare, high-stakes situations the learning model has seen too little of to be trusted. Aurora's argument is that a purely learned system can't guarantee its own behavior to a regulator, but a system with an explicit rules layer can show exactly what it will and won't do. I also noted that despite nearly 3 million internal test miles, Aurora still moved a human back into the driver's seat at the request of a manufacturing partner shortly after launch. Trust in an automated system, in other words, isn't just a technical property. It gets negotiated across every stakeholder who has to rely on it.

Together, this analysis fed our team's shared framing: that the mission control industry's real barrier wasn't necessarily technical capability, but unearned trust in newer tools, and that any design solution would need to make its own reliability and boundaries legible to the people using it.

Building the Archetypes

Rather than designing for "mission control operators" as a single, undifferentiated group, we mapped the actual decision-making roles within the domain, analyzed across NASA, Boeing Starliner, and air traffic control operations, since each of these organizations names the same underlying jobs differently. That cross-referencing is where my research into Boeing Starliner mission control positions fed in directly: aligning Starliner's role titles against NASA's and ATC's helped the team confirm that we were looking at genuinely equivalent functions, not just similar-sounding job titles.

That work led to five operator archetypes, each representing a distinct authority level and interface need:

• Mission Commander — holds ultimate authority and makes go/no-go calls

• Operations Planner — owns the integrated flight plan, tracked to the minute

• Flight Dynamics Navigator — owns vehicle trajectory and timing across mission phases

• Systems Monitor — continuously monitors one system and responds with precision to anomalies

• Ground Control Liaison — the primary interface between ground and crew, managing communication delay

I contributed to the affinity mapping and clustering process that turned interview transcripts and secondary research into these five distinct profiles, identifying where different SME accounts of "who does what" actually described the same role versus a genuinely different one. This is also where the project's eventual design focus started to take shape: the Operations Planner archetype, the one whose job is literally building and adapting the schedule, was the role that came up again and again when SMEs described their biggest pain points. That repetition across independent conversations is what made the Operations Planner the team's primary design focus once we moved into summer.

Subject Matter Expert Interviews

Over the course of spring, our team conducted SME interviews across Voyager Space, Axiom Space, Stoke Space, Teague's internal human factors group, and NASA Ames Research Center, reaching professionals in flight operations, human factors, product design, and station strategy.

I researched each SME ahead of their session, including their professional background and the specific systems or programs they'd worked on, to help shape the questions we asked. That prep work mattered because these interviews were short and the SMEs were senior. Knowing enough about someone's actual work going in was the difference between a generic conversation and one that surfaced something specific.

Themes converged quickly across interviews: trust, safety, automation boundaries, and efficiency came up repeatedly, and scheduling specifically surfaced as a recurring pain point in a majority of our early conversations. That pattern is what eventually pointed us toward NASA's SPIFe team and scheduling software as a design focus, though that pivot didn't happen until later in the project.

Once the interview round was complete, I helped cluster findings across all our interviews and secondary research into affinity groups, the process of taking scattered notes from six different conversations and finding the patterns that repeated across them. That synthesis work became the foundation for the operator archetypes the team ultimately built the rest of the project around, including a specific look I did at Boeing Starliner mission control operations to ground our archetype definitions in a real, documented organizational structure rather than an abstraction.

Screenshot of our team FigJam SME clustering.

Narrowing the Scope

Summer began with a mandate that was still, honestly, too broad. Our team's first move was a scope alignment meeting with Teague on July 1, followed shortly after by an interview with the lead of NASA Ames' SPIFe/Playbook scheduling team, on July 10.

Our Playbook SME's first reaction to our framing was direct: what we'd described was still far too wide. She pointed out that mission-critical design work falls into different tiers of criticality, and treating "space mission control" as one undifferentiated problem risked us designing the equivalent of an over-engineered light switch instead of solving something that actually mattered. That conversation, and the SPIFe/Playbook research lineage she pointed us toward, became the anchor for the rest of the project. Two findings from her team's own published research shaped everything that followed: a 2019 study where an astronaut got stuck mid-conflict because the system flagged a violation without explaining why it existed, and a 2023 study showing that scheduling performance measurably degrades as constraint complexity increases for novice planners. Constraint transparency wasn't a nice-to-have. It was the actual design problem.

With that direction locked, my focus became translating it into a concrete artifact: the operations planner journey map. This is the work I owned for the rest of the summer, taking the team's converging research (the SME interviews, the SPIFe/Playbook literature, the archetype work from spring) and turning it into a structured, stage-by-stage picture of how a planner actually experiences building and defending a schedule.

The map went through six iterations. Early versions tried to document the full planning lifecycle, and kept sprawling back toward the same problem our Playbook SME had flagged: too broad, not committed to a specific design opportunity. Each iteration narrowed further, cutting stages that were technically part of a planner's job but not part of the problem we were actually solving. The version we landed on structures the planner's experience into four stages: Setup, Spot Conflicts, Fix Conflicts, and what happens after the schedule is set, with Spot Conflicts and Fix Conflicts marked as our actual design focus. Getting to that structure meant repeatedly asking the same question she had asked us on July 10: is this in scope, or is this just because it's technically true?

What the Journey Map Actually Maps

The journey follows a working scenario we built to ground the abstraction: an operations planner scheduling a recurring exercise activity for a four-person crew on a long-duration mission, where one-way communication delay with the ground makes real-time back-and-forth impractical. Multiple crew members, shared equipment, and a repeating weekly cadence meant the scenario would naturally surface the kind of conflicts a planner deals with constantly, not just a one-off edge case.

• Setup. The planner gathers input from documentation (things like required exercise duration and procedure equipment), confirms which crew members are involved, then identifies every constraint that applies before anything gets placed on the schedule. I made a deliberate scoping call here: we treated this data as already existing in structured form by the time our design picks up, rather than trying to design the sourcing and documentation problem itself. That's a genuinely messy, multi-owner process today, and Marquez's own account of it later confirmed we were right not to try to solve it inside this project's timeline.

• Spot Conflicts. This is where the constraint engine flags violations as each instance of a recurring activity gets placed. Because an activity repeats, a conflict might only hit some occurrences and not others, which is a real design problem: a planner needs to see conflicts across the whole series at once, not discover them one day at a time. That insight, seeing the pattern across a recurring series rather than a single instance, became one of the core design requirements I carried into the prototype conversations with Victor.

• Fix Conflicts. Here the system proposes resolutions instead of just flagging a problem: adjust timing, swap equipment, split the booking, showing the planner what each fix might affect elsewhere on the schedule before they commit to it. If nothing works, the planner can waive the conflict, but only with a logged, timestamped rationale, an auditable trail rather than a silent override. This is also where we introduced AI-assisted resolution: instead of a planner manually testing each day by hand, the system could suggest something like staggered start times based on patterns from past scheduling decisions.

I want to be specific about that distinction, because it mattered a lot in how we designed it: automation in this system never makes a decision or commits a change on its own. It detects and suggests. The planner always resolves or approves. That boundary came directly out of the trust research from spring, autonomous vehicle systems that retain authority while accepting human input, not systems that hand off control.

Simplifying the Constraint Taxonomy

One piece of translation work I did early on was taking NASA's internal constraint taxonomy and making it legible to a design audience that would never have encountered it before. The underlying system defines five constraint archetypes: Claim, Unary, Binary, Assignment, and Profile. Those names mean nothing outside the SPIFe/Playbook team itself. I renamed them into plain-language terms the rest of the journey map and prototype could actually use:

• Equipment sharing (Claim) — multiple people need the same limited resource

• Time windows (Unary) — an activity can't happen during a blackout or restricted period

• Activity order (Binary) — one activity depends on the sequence of another

• Crew eligibility (Assignment) — who is qualified or required for a given activity

• Day exclusions (Profile) — certain days are off-limits for a given activity type

That renaming turned out to matter more than I expected. When we walked Marquez through the plain-language stage names in the journey map, "Spot Conflicts" and "Fix Conflicts," she specifically called out how approachable that terminology was, telling us she'd written the terms down herself. That was a strong signal that the simplification wasn't just cosmetic. It made a genuinely technical process legible to people outside the small group who already understood it, which was the actual goal of the Playbook deliverable we were building toward.

The plain-language names are the explanatory layer, not a replacement for the formal taxonomy. Victor kept Claim, Unary, Binary, Assignment, and Profile as the actual category labels inside Orbit, since a real mission planner would already know that vocabulary. The renaming does its work everywhere the audience isn't a trained planner: the journey map, the Playbook, and walking a non-expert like Teague or a client through how the system reasons.

Validation with NASA Playbook SME

On August 6, 2026 the team returned to our Playbook SME with the narrowed journey map and a working version of the prototype, Orbit, that Victor had built around it. I led the walkthrough of the journey map itself, first showing an earlier, more detailed iteration (Iteration 3) so she could see the full granularity of the process, then the current, more focused version (Iteration 6) that reflected the scope we'd committed to.

Her response validated something I'd been careful about the entire time: that narrowing the scope hadn't come at the cost of accuracy. She called it a genuinely detailed task analysis of a process that isn't well documented publicly, and specifically praised the plain-language stage naming, saying she'd written down "Spot Conflicts" and "Fix Conflicts" herself because they were such an approachable way of describing the process. For a project built almost entirely on synthesizing fragmented, undocumented expert knowledge into something legible, that was the validation that mattered most.

She also refined the constraint taxonomy I'd simplified. The five archetypes I'd translated into plain language, equipment sharing, time windows, activity order, crew eligibility, and day exclusions, covered the basic family, but she pointed out real constraint types that don't fit neatly into any of them: activity-avoidance rules triggered by another activity's state (she used the example of pausing exercise during a vibration-sensitive crystal-growth experiment), and a distinction between plan-level constraints and activity-level constraints, like a daily working-hours cap that applies per day rather than across an entire plan. That kind of detail doesn't show up in any published paper. It only surfaces when you're in a room with someone who actually runs the system, which is exactly why this SME session mattered as much as it did.

The second half of the session moved into the prototype itself, which Victor demoed live. Several of her reactions became direct, actionable design fixes:

• Conflict visualization - The current design highlighted overlapping activities as a single ambiguous block. She couldn't tell where one activity ended and the conflicting one began. Her fix was to outline each conflicting activity separately, so the boundary between the two is visually legible instead of implied.

• AI-assisted resolution labeling - The prototype distinguished a manual resolution path from a pattern-based, historically-informed suggestion path, but the labels ("Resolve" vs. "Suggested") didn't make that distinction clear. She proposed simpler, clearer copy: "To resolve" for the manual path, "Other suggested" for the pattern-based one. She also validated the underlying concept directly, noting that using a model to surface historical resolution patterns for a scheduler isn't something that's been done in this domain before.

• Day-tile conflict dots - She asked, genuinely confused, what the small dots scattered across the calendar days were supposed to mean. Victor agreed on the spot that they'd become visual noise. She offered an alternative worth carrying forward: thematic day-coloring, showing what a given day is dedicated to, which she noted would matter more for short-duration, tightly scheduled missions than for the ISS's current seven-person, non-thematic cadence.

She also, unprompted, flagged strong interest in a feature that wasn't part of our design scope at that point: an AI tool that could read uploaded mission documentation and automatically generate constraint templates from it, noting how document-oriented NASA's process still is. It wasn't something we'd built at the time of that session, but the signal was strong enough that we brought it into Orbit afterward: the current prototype reads attached mission documents at activity creation and surfaces the constraints they define, each one traceable back to its source document.

By the end of the session, the throughline was consistent with everything that had shaped the project since spring: the design worked because it made an opaque, undocumented process legible, not because it eliminated the planner's judgment. Our Playbook SME closed the session telling us the work looked genuinely good, which, for a project built on translating a domain expert's tacit knowledge into a system a stranger could understand, was the outcome we'd been narrowing the scope toward all along.

How Orbit Helps

We mapped Orbit directly against the mission planner journey, showing how each stage resolves a friction point the research surfaced. By this point I had also simplified the journey map's stage numbering, from feedback in our Teague meeting that the earlier Stage 1–3 / Stage 4 / Stage 5 / Stage 6–8 grouping was hard to follow without context, into a flatter four stages: Setup, Spot Conflicts, Fix Conflicts, and Post-Planning (review, publish, and handling changes after the fact, which stayed out of scope for this project). At every stage, the goal wasn't just speed. It was trust: making sure the planner always knows why the system is telling them something, and always keeps the final call.

Setup. Orbit lets a planner attach mission documents, flight rules, ops notes, equipment specs, right when they create an activity. The system reads them and surfaces the constraints they define, each one traceable back to its source document. This is the feature our Playbook SME flagged unprompted in the August session; Victor built it into the prototype afterward. It matters for trust specifically because the constraints aren't invented or guessed. They're pulled straight from documents a planner already has reason to trust, so what the system surfaces has a source they can go check themselves.

Creating an activity: attaching mission documents to surface constraints.

Spot Conflicts. Every conflict is labeled by category and grouped in a violations panel. Click into one and see exactly what's conflicting: which activities, what times, why. That "why" is the direct answer to the failure mode our Playbook SME's own research documented: a 2019 study where an astronaut got stuck mid-conflict because the system flagged a violation without explaining why it existed. Orbit's panel is designed against that specific failure. The panel groups conflicts under the formal taxonomy (Claim, Binary, Assignment) rather than the plain-language names from earlier in this case study; that was a deliberate choice, not an inconsistency, since the tool is built for planners who'd already know that vocabulary.

Resolving a violation (left) with the full constraint and crew detail panel (right).

Fix Conflicts. Orbit doesn't just flag a problem, it suggests a specific fix: move the activity, or relax the constraint. If the planner doesn't want either option, they can waive it or send it to ground for review, but either path requires a logged rationale before it applies. Nothing gets overridden silently. This is the automation boundary the whole project was built around: Orbit suggests, the planner decides. If someone waives something, that decision is on the record, so trust doesn't depend on the system being right every time. It depends on the planner staying in control and being able to explain what happened.

Applying a suggested fix or waiving a conflict with a logged rationale

I want to be clear about where my work ends and Victor and Nic’s begin here. The research, the journey map, and the constraint taxonomy work are mine. The interface decisions above, how the attach flow works, how the violations panel is structured, how the resolution options and waive flow are built, are Victor and Nic’s design and engineering work using Claude code and Cursor, built around the research and journey map I owned. Where I contributed directly was in the SME session that shaped these decisions and in framing how the prototype maps back to the trust problem the whole project was solving.

From Feedback to Final Prototype

After the SME session, Victor took the conflict-visualization fix, the resolution-labeling change, and the rest of the feedback from that walkthrough, along with input from Teague and the broader team, and folded it into the working build. You can try the current prototype here: Orbit. Password: 1007

The Future of Mission Control

One line from our spring SME interviews stuck with the team the entire summer:

"Spaceflight folks are reticent to embrace automation, because the more automation you have, the less control you have." - Flight Controller, Axiom

That's the tension Orbit was designed around, not to resolve it by removing the human, but by proving the opposite is possible: automation that earns trust by staying legible, detecting and suggesting rather than deciding, and leaving the planner with more control over a more complex problem than they'd have on their own. Maintaining human control isn't a constraint on scaling mission control design. It's what makes scaling it possible at all.

What This Taught Me

Going from "space" to Orbit wasn't a straight line, and it wasn't handed to us. We started with a domain, not a problem, and had to do the investigative work ourselves: research, SME interviews, finding where the actual pain points were, choosing one problem space out of everything we could have chosen, and then narrowing that further, and further, until what was left was small enough to actually solve well. Every one of those narrowing decisions took real work to get to, and none of them were obvious in the moment.

That process is genuinely hard. It takes time, it takes a lot of research, and there's no shortcut through the ambiguity of an undefined problem. But getting to the other side of it, watching a specific, focused product take shape out of something as broad as "space," was rewarding in a way that a handed-to-us brief never would have been. I'm proud of what my team built out of a problem nobody gave us. That's what UX research actually is: finding and defining the problem worth solving, then handing off something specific enough that a design can actually address it.