Context

There are few things NASA likes more than a good approval process or twelve. Unfortunately for the scientists and engineers navigating those approvals, there is often little overlap in the systems used to support them, even if the processes themselves are highly synergistic. Thankfully, the opportunity occasionally presents itself to create a technical intervention where processes come into alignment. As the project's design lead, it was my responsibility to craft a solution that met the needs of both systems and their users.

Prompt

The Ames HCI team, in its effort to integrate NASA data and make it more readily accessible across the administration, became the system owners for two distinct tools – the ISS Hazard System (or IHS, since NASA loves acronyms), which manages safety approval of experiments going to the International Space Station, and OCAD, the database housing documentation for when astronauts themselves have to step in to make sure those same experiments are safe. Users previously had to stop their work in IHS and hop to the OCAD system every time they wanted to use its capabilities. Afterwords, the onus was on the user to manually synchronize two data sets in two systems if content changed in either . We had a golden opportunity to make this process seamless, saving time and increasing accuracy of and access to the data.

This process / cultural model reflects the Hazard Author as the feature's primary beneficiary

Understanding

We had a great advantage going into this project, as we were able to leverage previous research, process knowledge, and usability evaluations that the Ames HCI team had already undertaken for each of the component systems. This allowed us to begin user research with very specific targets in mind, exploring anticipated pain points while uncovering details previous research hadn't come across. One crucial finding was that Hazard Authors, the users who created OCADs by hopping between systems, already lacked insight into how OCADs were processed and evaluated. If our goal was to lessen their involvement in the process even further, it would be imperative that we keep the Hazard Authors informed of what's happening with their work while still eliminating the tedious aspects of OCAD creation.

Speed Dating was used to quickly validate early design options

Members of both systems' design teams were brought together to brainstorm design concepts that fit within the tools' established usability patterns, yet would allow data to be shared in unprecedented ways. Research had made it clear that though the main task of creating OCADs and associating them with the correct part of the Hazard process was relatively straightforward, the ways in which the OCAD and Hazard evaluation processes interacted would require the consideration of numerous edge cases and the introduction of several secondary functions. We quickly transitioned from these brainstorming sessions to low-fidelity user evaluations, "Speed Dating" a number of potential solutions to various functional categories.

Solving

Confident in our direction, the next hurdle was to implement the best possible design solutions that were still in line with our technical limitations. Cost and time constraints mandated the use of existing tools to facilitate the integration between systems, shaping the space of potential interactions. Ultimately, this resulted in the adaptation of similar data linking capabilities to meet the needs of the OCAD-producing Hazard Authors. Our designs were then able to leveraged both existing code and design patterns to display OCAD data in a similar manner to Verifications, a data type users were already familiar with. Interactions and visual designs strove to be as consistent as possible across the various OCAD features that were needed.

New OCAD content (the blue box) is displayed similarly to Verification content (the red box)

With this basic framework in place, the next task was designing, iterating, and testing the numerous secondary interactions. A brief list of these included…

• Creating new OCADs
• Showing OCAD approval status
• Reusing existing OCADs
• Resubmitting erroneous OCADs
• Concurrence for modified OCADs
• Rendering the new OCAD data on a customized PDF export
• New error states and network conditions introduced by the integration

These features were generally mocked up as storyboards and presented to our internal clients and users for feedback. Working collaboratively with our development and QA teams, we created a thorough chart of potential network error conditions, writing user-friendly copy for each.

Resubmitting an approved OCAD, one of many edge cases that had to be considered

Results

As deployment time neared, we began planning in-person training for Hazard Authors and OCAD system users who would be affected by the changes. To support this training, new process flow diagrams were created and handed out during the sessions, and were also added to each system's documentation. Since deployment, hundreds of OCAD records have been created using the H2O funtionality, representing a significant increase in both time savings and data reliability for both systems.

Process flows customized to each user role were provided, along with in-person training