Iris

Improving discipline collaboration to reduce delays.

Iris is a web application that helps NASA engineers move efficiently in rocket design by aligning design assumptions early and often.

Role
Design Lead
Product Designer
Research Co-Lead
Timeline
01.2019 - 08.2019
Team
Gaby Gayles
Rudy Iyer
Katherine Jiang
Allana Wooley

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:

Scaling with a design system

We created a design system in Figma, which allowed the designers on our team to effectively collaborate.

Final Deliverables

1. Homescreen

When requirements are being formulated and change frequently, engineers can refer to the requirements hub to interact with them.

2. Relationship Diagram

As engineers start their work cycle, they can discover and understand relationships and dependencies with the help of the diagram.

3. Usage Context Cards

As engineers use models and analyses to verify that their designs fulfill the requirements, they can quickly access how different teams are using data that might influence their work.

4. In-context Commenting

Engineers can raise and address concerns regarding specific usage context in this designated space for discussion and stay on top of decisions.

Features anatomy

You can read about our full process in this series.