Context
Designing a rocket takes an immense amount of coordination across engineering teams.
In 2020, NASA was projected to launch its most powerful rocket to Mars. Rocket design is no small feast; in order for it to achieve mission success, all parts need to integrate into one cohesive and functional system.
NASA approached us at the beginning of 2019, for an HCI solution to help engineers have the confidence to move forward in their design process, knowing that they are done with designing a part.
Problem
Misaligned design assumptions cause delays and incur huge costs.
Existing work processes present challenges for engineers to collaborate effectively: specifically, we identified three major underlying pain points:
1. Insular focus on discipline work
2. Diffused data
3. Different sub-team cultures
Solution
Iris is a web application that helps engineers externalize and align design assumptions by surfacing relevant information and keeping communication contained and traceable.
Key Feature 1: Relationship Diagram
Interactive visualization shows the interrelationships between different rocket parts, enabling engineers to gain a holistic understanding of the program.
Key Feature 2: In-tool Communication Thread
Discussion threads can be marked as resolved, surfacing decision points; this keeps communication contained and allows user to trace back to historical records.
Key Feature 3: Usage Context Cards
Usage contexts are independent of the specific work documents and provides a structured format for cross-team communication.
For the full experience, play with our prototype here.
Research & Scoping
Understanding our domain and users
In January, we received an open-ended prompt from our client:
How can we help systems engineers understand that they are “done” with designing a part of the rocket?
We started with background research to understand what we’re working with (including reading through NASA's own handbook describing systems engineering and functional analysis). We also leveraged analogous domain users and desk research.
After the government shutdown ended, we traveled on-site at Marshall Space Flight Center to interview and observe our users to understand their processes, needs and motivations.
We created a variety of design artifacts (journey maps, sequence models and affinity diagram), which we frequently referred to as we progressed in our processes. We also shared them with our stakeholders to get alignment.
Here is a simplified workflow diagram I made to represent NASA's rocket design process.
Key insights:
1. Engineers’ insular focus on their own domains deters proactive information sharing.
Tension exists over who should have what access to information at what levels of detail, and discipline engineers don’t always get to see how everything fits together.
2. Locating and communicating specific data is difficult.
Data is stored in a multitude of systems, and decisions are often made informally, making them hard to trace back.
3. Particularity in work processes pose collaboration challenges.
Discipline teams have specific cultures and vernacular, resulting undesired communication gaps.
I also made a more detailed user journey map to help us emphasize with our engineers.
Ideation
How can we help discipline engineers align their design assumptions and move forward in the design process more efficiently?
This was the revised problem statement we arrived at through research. When teams don’t constantly communicate and have insular focus on discipline-specific work, they can operate on different design assumptions, which can lead to failures in integration and prevents work from being marked as “done”.
We put together multiple ideation sessions, with exercises such as Reverse Assumptions, Creative Matrix and Crazy 4's.
150+ ideas, 10 storyboards, 7 speed-dating sessions later, we synthesized our insights into the following areas:
1. Improving visibility into each other's works
2. Facilitate understanding of dependencies
3. Make decision-making traceable
4. Centralize and streamline communication
Concept Development
In order to gauge the usefulness and desirability of our concepts, I led the team in translating them into stand-alone features, which we tested with our engineers at Marshall via video calls and solicited feedback on from senior designers at Ames.
We conducted heuristics evaluation on some initial wireframes, and recruited our co-workers at NASA for experience prototyping to catch obvious usability issues that did not require specialized knowledge.
I also put together a user flow based on the user stories we wanted to focus on, which we used to develop specific screens in the product.
Prototyping & Testing
We conducted a variety of tests and quickly iterated according to tester feedback. Since our user base was a relatively small group of expert users, we also tested with designers at NASA Ames - who may not necessarily have the specialized knowledge, but are equipped with the general context.
After rounds of iterations, we flew to Marshall again to test our mid-fidelity prototype for usability and prioritize edits. Here is a sample of the design decisions we made:
