Model-Based Definition

 

Informing the creation of a standardized 3D model design to save millions in the rocket production process and enhance the experience for 10,000+ employees.

 
 
 

Contributions

 

Research

I was the research lead for this project, responsible for coordinating, conducting, and analyzing all 60+ interviews into a consolidated report for delivery to stakeholders.

Design Requirements & Deliverables

I was responsible for translating the research into design requirements that would be passed to stakeholders and designers for execution as a final deliverable.

 

Team

Sofia Larson
Lead Researcher

Caryn Kieszling
Support Researcher

Duration

3 Months

Tools & Methods

  • Figma

  • Literature Review

  • User Interviews

  • Fly-on-the-wall

  • Personas

  • Journey Maps

  • Infographics

  • Workshop


 

Context & Problem

Context

In the aerospace industry, the standard is to produce two pieces of documentation to create hardware that will go on a rocket. One, is a 3D model of the hardware. The other, is a 2D engineering drawing of the hardware. These two artifacts in combination hold the design requirements that will be used by those creating the hardware to ensure the hardware is built to expectation.

Problem

These models and drawings are not static. As hardware is reviewed, redesigned, and built, changes to the design are bound to occur.
This presents a couple of challenges.

  1. Design engineers must update both artifacts with every approved change.

  2. Those using these artifacts for work, engineers, technicians, warehouse workers, buyers, etc. must double-check to ensure they are using the right version of the drawing with the model.

  3. The above two problems make for a poor, distrusting, user experience but also utilize much of their time. Time cost directly contributes to negative impacts on our launch schedules.

 
 

Stakeholder Proposal

Our stakeholders for our research, TPMs and a group of Systems Engineers, then proposed that the way the industry solves these problems is through what is called a Model-Based Definition (MBD). In short, in this model, 2D drawings are completely depreciated, and all of its information is captured within the 3D model. The 3D model would be the only source of truth for the definition of a product.

 
 
 

 

Research Approach

To address the problems associated with this project, I created a few goals to put our research efforts towards in the development of my research plan. These goals helped us define scope to guide, facilitate feedback from stakeholders early on in the process to ensure we were headed in the intended direction.

 
 

Goal One
Identify existing 2D/3D usage at Blue.

 

Goal Three:
Identify concerns and potential negative consequences with transitioning to an MBD.

 
 

Goal Two:
Identify types of employees that would be impacted by an MBD.

 

Goal Four:
Identify edge cases where a 2D drawing may be absolutely necessary

 
 

Ultimately, these goals were created to ensure we had the data necessary to provide validated input on whether or not an MBD could be put in place at Blue in a way that would help, rather than hinder, employees.

Once goals were set an approved, I begin to develop a thorough research plan to reach these goals. This involved utilizing a variety of methodologies (literature reviews, interviews, fly-on-the-wall research) as I visited a multitude of different Blue Origin sites responsible for producing and launching our rockets over the span of 3 months. A majority of these trips were done solo, with the exception of Texas, where I was accompanied by a fellow researcher working on a different initiative.

 
 
 
 
 

Literature Review

Prior to this research, I had very limited knowledge on the design engineering process. To further my understanding to make informed interview questions, I compiled existing information surrounding design engineering in both Blue and the overall industry context into a literature review.

Interviews

To ensure we were considering those who actively use drawings and models today, we did a series of in-person and online interviews to understand the current use cases of these artifacts today. Each session was 30-60 minutes and included factory tours. 60+ interviews were conducted across the nation.

Fly-On-The-Wall

I also wanted to consider edge-cases where users utilize drawings and models that may not be top of mind. So when visiting sites, I would walk around the facilities on my own, observing various areas where these artifacts were being used or displayed upon the factory walls.

 

 

Key Findings & Visual Deliverables

After approximately 3 months worth of research, I was able to uncover the following through two weeks worth of qualitative analysis.

 
 

2D drawings load faster
Some users of 2D drawings ONLY utilize drawings. This is because it’s a lot faster to pull up a drawing for the information they need, as opposed to a 3D model.

 

Many are unfamiliar with navigating models
Employees who have been in the industry longer tend not to have as much experience navigating a 3D model. Particularly, technicians and machinists.

 
 

Some drawings must remain
Due to technical model difficulties, government contracts, and electronically classified areas on test stands, not all drawings can be depreciated.

 

Many saw the benefit of an MBD without prompt
Even without researchers mentioning an MBD, about 40% of interviewees brought up the idea of moving to an MBD on their own accord

 
 

These findings were especially prevalent, as they would have the most impact on how 3D models may have to be designed and accessed for employees to find them just as valuable as a drawing would have been. These findings, along with many others, were then delivered in the form of various deliverables, to help communicate important findings at a level high enough for director-level stakeholders to glimpse and get enough information for strategic decision-making.

** Deliverable images are just representations- as the actual deliverables created are considered proprietary to Blue **

 
 

PERSONAS

In total, 12 personas were created to represent the various types of employees (roles).

Each persona came with a high-level overview of their role functions, their level of usage of 2D drawings and 3D models, their rationale behind their usage of these artifacts, the specific data they utilized these artifacts for, and their concerns regarding moving towards an MBD.

 

JOURNEY MAPS

Each persona was accompanied by a journey map, going through the various instances in which the person would utilize a drawing or model during their job responsibilities.

Each journey map documented the process of using a drawing/model, pain points in the experience, the various pieces of software being used to access the artifacts, the pieces of data being referenced in the artifacts, and the opportunities we have for improving the experience.

 

INFOGRAPHIC

A infographic was also created to provide an even higher-level view of the information, in case personas and journey maps were too role-specific. This would serve moreso as a tool to raise awareness around the project, rather than fuel decision-making. It encourages a deeper dive.


This infographic contained a summary of the how the data was collected, a list of the key findings from the project, and an emphasis on which roles tend to use drawings and models most heavily.

 

PRESENTATION

Finally, a presentation deck was created to go over the findings from this research within a 60 minute time frame. This would serve as the deepest-dive report available for stakeholders to review (80+ slides)

It contained a list of the various roles identified in our research, the processes and behaviors that currently exist at Blue for consuming drawings and models, common concerns for if we moved towards a MBD, benefits of moving towards a MBD, and our recommendations for designing a MBD future based upon these inputs.

 
 

 

Workshop Delivery

These findings were then presented in the form of a workshop to our stakeholders, utilizing a combination of the aforementioned presentation and an activity. For the activity, our goal was to ensure our stakeholders would leave with one, a better understanding of why its important that we account for even the smaller edge cases of our users, two, how those edge cases would impact our execution of an MBD, and three, a list of requirements of the data that must be captured within a MBD to appeal to all use-cases.

To accomplish this, the activity required each attendee to select a persona to represent out of the 12. They would get time to read and familiarize themselves with the person. Then, utilizing the information on that person, they used a shared mocked-up 3D model to write/draw how they as that persona, would find the model most convenient to view the necessary data specified in their persona card.

 
 
 
 
 

At the end of the activity, we now had a mocked-up model with all the total requirements for an MBD that would be necessary for all roles. This was actionable for our director-level stakeholders, for now they had a concept and defined list of data requirements that could help them formulate a plan for execution to propose to C-level leadership.

This was also actionable for our design team, who wanted to get a head-start and create another mockup that was interactive and incorporated actual 3D elements to prove that from a technical standpoint, the model created in the workshop would be possible to replicate and view in a fast enough manner to support our users, as that was a major concern the director-level stakeholders expressed during the workshop.

 
 
 
 
 

 

Solution

I then worked with the 3D Designer and UX Designer assigned to this concept by going over my research with them and providing them the insights and recommendations from the presentation that I felt would impact the solution they created the most. This was done through another run-through of the workshop, providing access to my research deliverables, and a series of conversations and check-ins over the span of two weeks.

 
 

3D-optimized view for faster loading
Referencing a drawing takes seconds- since its in the form of a PDF. Our models must be optimized enough (in a reference only setting) to match that load time.

 

Notes must be tied with 3D orientation
Notes on a model are tied with locations, to provide context on where a note may apply on the hardware. Maintaining that relationship by orienting the model accordingly when a note is clicked will be a time-saver and reduce navigational burden on users.

 

A 2D print option must be available
There are constraints that require 2D drawings to still be available for some edge cases. We need to maintain that functionality for those incidents.

 

Web-accessible
Not everyone is familiar with / has the software used to open 3D models. We need to provide the ability to reference a model in a web-view format for these users.

 

 

 
 

** This is a representation of the solution. Actual could not be shown due to proprietary info.

Group 171.jpg