Kenobi

CONTEXT AND BRIEF

Our team's platform, Mission Assurance System (MAS), manages spacecraft safety data, like instruction on how to assemble the rocket. The main users of this tool are engineers and administrative folks; they create, edit, and reference various types of data on our applications.

One type of data that currently doesn't exist on our platform is Flight Rules. Flight Rules are written agreements between various engineering and operations groups about what to do in an "off-nominal" situation. Basically, lots and lots of backup plans for when something goes wrong. They are used in the Mission Control Center, by the Flight Directors and Controllers (the Houston-we-have-a-problem headset people).

The project objective was to research the Flight Rules creation/editing/use process. From there, we would determine whether our MAS platform was the mot efficient way for them to do their work.

DESIGN OUTCOME

(Right: Current Flight Rule format, text redacted)
‍
We conducted comprehensive research around their Flight Rules data process. We also created several new mental models around their process and developed prototypes to illustrate them.

The final recommendation was to not use our platform for their data. The way Flight Rules are structured is vastly different from the structure that is best supported on our platform.

01
DESK RESEARCH AS FOUNDATION

There's a lot of NASA and process-specific terminology that we needed to catch up on. While we scheduled interviews, we read as many documents as we could get our hands on. Time with research participants is precious, so foundational knowledge helped us use our research time better. We saved our "beginner mindset" for the process, and not for the parts.

This knowledge of how the process should be conducted was very helpful to compare with how people actually did the work.

02
COLLABORATIVE JOURNEY MAPPING

As we discovered parts of the current Flight Rule approval process from people in different roles, we slowly compiled a coherent visualization of it.

We used the journey map in subsequent research sessions to help guide the conversation. I'm used to this process, but this time we did it a little differently: together with the participants, we filled in missing moments, and dove deep into details. Collaborating on creating the journey map benefitted everyone; it helped us fully understand each of the steps and the participants also discovered what their colleagues were doing.

03
PROTOTYPING, IN THREE WAYS

The old interface (to the right) used to process changes to Flight Rules was inflexible and static. We began experimenting with our current platform features to see if we could make the process smoother.

For every pain point that we discovered, we took three different approaches of brainstorming:

no constraints; what would be the perfect solution?
platform constraints: what solution could we build using only the current platform capabilities?
mixed constraints: what solution could we build using some platform capabilities with some new features on top?

For proof-of-concept visual work, we balanced setting up test instances to push current platform capabilities as well as mocking up brand new features in Figma. One kept us grounded to today's feasibility and the other, pushing our vision of our platform's future.

04
STAKEHOLDER STRUGGLES

Our main stakeholder for the project was a Flight Director who leads the Artemis I mission; he is a very busy man trying to get everything organized to go to the Moon.

We were careful to not ask too much of his time, but also needed a close partner to make decisions with a holistic understanding of the tool and long-terms strategy in mind. Our weekly tagups were fruitful, but keeping continuity between meetings was a challenge.

We finished the project with lots of insights about stakeholder engagement. We have new standards for what kind of stakeholder to engage in the future, and thoughts about our internal team: how can we facilitate a smooth transition between leadership (strategy) handing a project to a team (implementation)?

1.5 years with:

Project Leads - Momo Miyazaki, Joe Medwid