Team Far Out

Generative Research

To understand our problem domain, we conducted a variety of research and synthesis methods to identify key insights and pain points.

Overview of our work thus far

Getting to know our problem space

Starting off, our team knew close to nothing about either space or systems engineering, we started with a list of questions to answer through background research, including the mission of Space Launch System (SLS), functional analysis and graph databases.in functional analysis.

Visualizing our initial understanding of systems engineering in the context of SLS

Analogous Domain

After developing a general understanding of the problem space, we were able to identify domains that share a similar context and work flow with NASA systems engineers. We focused on fields where multiple teams collaborate to work against a wide variety of requirements in complex systems over time. We conducted 8 interviews with people whose roles ranged from NASA systems engineer to manufacturing engineers:

Architecture, Civil Engineering, Construction

Architects, civil engineers and construction workers come in at different phases of bringing a building to life. These projects timelines often span multiple years and involves many stakeholders.

Manufacturing

Manufacturing relies on an understanding of how different parts fit together and requires heavy cross-team collaboration to deliver a well-integrated product.

Systems Engineering at different NASA program

Systems engineers working on other NASA projects shares the general NASA context, and are also responsible for integrating different subsystems.

To better understand our findings, we created journey maps to represent the processes, with a focus on their relationship to dependencies, collaboration, schedules as well as their pain points.

Key Insights

Teams face roadblocks when they rely too heavily on institutional knowledge.

In face of uncertainty, people use judgement and make assumptions.

The more stakeholders there are, the more important communication becomes for project success.

Too many dependencies can create delays in completing projects.

With the domain context and insights we gathered from analogous domain research, we were able to start preparing for our contextual interviews onsite.

Zooming into NASA

We visited the Marshall Space Flight Center in Huntsville, Alabama and conducted semi-structured interviews and contextual inquiries with the SLS engineers. We talked to both systems engineers (who focus on the integration and the interrelationship of different parts/disciplines) and engineers who are responsible for designing specific parts. These interviews revealed contrasting perspectives.

We sythesized our research by building sequence models (which helped us understand engineers' work processes and identify our knowledge gap) and an affinity diagram (which allowed us to uncover themes by grouping the data).

Sequence Models

Affinity Diagram

Here is the affinity diagram we created from our 10 interviews/contextual inquiries.

Requirement "Journey Map"

As we furthered our research, we realized our problem scope and likely solution were more about how multiple stakeholders interact with a requirement, as opposed to individual processes. To identify potential opportunities for our solution to come in, we created a “journey map” for a requirement.

Key Insights

The adoption of new processes, systems, or tools at NASA is difficult, complex, and often unsuccessful.

Engineers at different levels hold different priorities with regards to SLS.

A formal process or repository of knowledge sharing was not observed.

Interdependent processes run separately, resulting in redundancies.

Walk the Wall

Every member of our team independently reviewed all of the research work we had conducted thus far, coming up with unmet needs and design opportunities. Synthesizing these identifications, we came up with the following guiding questions.

Design Opportunities

How might we help engineers understand and visualize their part in terms of the SLS whole?
How might we improve knowledge sharing across different teams?
How might we enable the tools to adapt to engineers' existing workflow?

From research to rapid ideation

We used different rapid ideation methods, including Reverse Assumptions, 20 Questions, and Crazy 4's, to generate over 100 different possible solutions for our initially discovered needs.

We affinitized these ideas to identify overarching categories and then narrowed to the top 4 that were the most interesting and impactful to out problem space:

Promote knowledge sharing
Align priorities across levels
Track progress in configuration management
Create context-aware tools that adapt to engineers’ specific workflows

The identification of these problem areas marked the end of our generative research phase and the start of evaluative research that would allow us to validate these needs.

EVALUATIVE RESEARCH