aBOM

ION Factory OS

Case Study

B2B SAAS

Sr. Product Designer

Read Time: About 5 minutes

Context

As First Resonance’s customers grow and mature, they are creating increasingly complex assemblies along with intricate processes that require the traceability that provides. ION’s as-built Bill of Materials functionality, unfortunately, wasn’t scaling well for these complex assemblies. What was once a simple tool for installing inventory or parts while capturing the necessary data needed to evolve into a management system for all the activities our customers require during an installation process.

Problem Statement:

The current aBOM functionality fails to effectively handle complex assemblies that contain hundreds of parts and consumables distributed across numerous and sub-steps in work instructions. This scalability issue creates unnecessarily time-consuming workflows for tasks that should be straightforward, negatively impacting efficiency.

Business Goals

Expand core functionality to match the workflows customers require as they grow and mature in their manufacturing processes.

Increase the speed at which a user can finish any task related to the , including searchability, installations, uninstallations, quality, and BOM management.

Further differentiate the aBOM and traceability features and BOM management from the emerging competition in the field.

Impact & Results

The redesigned Manager reduced human error and time on task for all users while increasing traceability accuracy and BOM to flexibility. This resulted in a 100% adoption rate within one month of the beta release.

Time Savings: By streamlining the installation process, greatly improving search, minimizing human error, and consolidating workflows, technicians and engineers spent considerably less time on task resulting in lower assembly costs.

Accurate Traceability: When building assemblies that are for R&D sometimes parts get swapped, added, or deemed unnecessary. By adding BOM management features, users could accurately update and versioning the BOMs to match the aBOM giving them accurate reporting and traceability for every assembly.

Flexibility at Scale: The new feature set enables customers to leverage during every phase of their manufacturing processes. Fine-tuning permissions for employees to access the appropriate features during the right processes means reducing time on tasks while ensuring the appropriate gates are used during mission-critical tasks.

Decreased Human Error: By extending the search capability to the part requirements list and combo-box components, technicians error rate when installing parts fell to below 5%.

Scalability: The ability to modify, swap, or create BOMs of assemblies at the time of build allows customers to fully utilize from R&D to final assembly.

The legacy installation right rail.

The manager displaying four parts installed to one requirement.

Role

As Head of Product Design, I led a team through the entire product design life cycle

Activities:

Ethnographic research and interviews at 5 customer factories.
Remote Interviews of 5 additional teams
Mined institutional knowledge of collogues with manufacturing backgrounds
Created a design strategy that informed and aligned with engineering’s execution strategy and feature roll-out
Facilitated continuous buy-in and alignment with the CEO and the Directors of Product, Engineering, and Customer Success
Created & maintained new design system patterns
Facilitated internal and external user testing throughout the design and development releases

Process

1 week

1 Sprint, 2 weeks

1 week validation,
1 week synthesis and redesign,
1 week validation

1 week

Ongoing: Ethnographic research, remote interviews, requirement consolidation (Product Board + Insights + Research), and the PRD activities were executed prior to design kicking-off

Research

We leveraged employees' expertise from hard tech companies like SpaceX, Toyota, and Boeing, understanding their workflows and pain points.

The design team visited five customer factories. These customers were building eVTOLS, satellites, microgravity pharmaceutical production plants, satellite buses, 3D-printed rockets, and electric watercraft. Ethnographic research was conducted with the entire project in mind, as well as the systems that impact it. Remote interviews were conducted for specific feature sets, such as the manager. We remotely interviewed 10 additional teams for the aBOM features in Run Execution.

Design, Product, and Customer Success (CS) rated and prioritized insights from ethnographic research, remote interviews, and feedback gathered through the application and CS. Data and trends from the application were also utilized to gain additional insights.

In large assemblies, finding the correct part requirement to install to is highly cumbersome. Search functionality only works for exact matches for part numbers requiring users to scroll through hundreds of part requirements to find the correct one. To further complicate this issues, reference designators increased the complexity of this manual process.

Picking the part to install on a part requirement is easy, but the combo boxes would not update the database on install. If the database wasn’t updated, then users would be able to pick the same serial numbers they previously used resulting in an error, a toast explaining the error, and the serial removed from the part requirement. Over the course of a large assembly this small amount of time per mistake accumulated into a noticeable time lost.

When uninstalling a part from a part requirement, the interface didn’t present any of the options for the typical uninstallation processes used by our customers. If a part was uninstalled, the user would need to go to another part of the operating system to update the location, status, or label. Users would also need to initiate any QC process from another part of the interface, and there was no “scrap” functionality.

Once an assembly and it’s BOM was associated with a , it was incredibly difficult to change it even though multiple assemblies and BOM versions could be associated with the work instructions. BOM’s couldn’t be edited either, resulting in incomplete aBOMs or over installed aBOMs during final inspection.

Customers were creating building work instructions and capturing data utilizing the red-lines feature. The user could start a blank , redline in work instructions and data collection, and then install into a blank BOM. They had no ability to create a new BOM or edit an existing BOM creating additional work for the engineers once their process was complete.

Design Sprints 1-2

When kicking off the first design sprint of a new feature set, we would have a meeting between the technical leads, product owner, CEO, design lead, and an SME or two. We would review the PRD, user flows, and and design artifacts. The outcome of these meetings would be three-fold.

Identify any blind spots or edge cases not in the PRD
Identify the scope of any engineering discovery processes
Set expectations and align on the north star for the feature set

During the kick-off meeting for feature set, the engineering team identified that some search features and persistent memory features for installations required additional research. While the backend restructuring for aBOM was already underway, additional discovery would be needed by engineering to understand the scope of the additional requirements.

For the part requirement list and part picker lists, there was a question about scale. What was the most efficient way to implement search at a large scale and still be performant (<500ms).

The same part requirement can be used over and over in a BOM. When a user installs a “serialized” (single use) part to a requirement, that serialized part can’t be installed again. At this time, server side updates took time, while installs could happen in quick succession. Prior to utilizing the future subscription feature, can we create a low effort implementation solution that will be robust enough for our largest customers and performant until the future subscription feature is complete.

Our philosophy behind modals were to focus the user on a complex workflow without taking them out of the greater context of work. We used the term “manager” since these complex workflows were a part of a larger system, but the user needed to be able to focus or manage this body of work prior to moving to the next logical step.

One of the components we used heavily in were cards. We used these cards for inventory, part requirements, tools, the “part to be built,” and for other objects where a card pattern fits the parent pattern. During the design process we needed to ensure the information passed in these cards were sufficient to perform all tasks while minimizing human error.

Part to be Built Card.

aBOM and mBOM tools

Part Requirement Card

Part Requirement Card with Part Installed Card

The aBOM manager is a collection of cards and tools that work in unison to give the entire context a technician or engineer needs to ensure their work is error free and can be completed without needing to leave the manager. Every piece of information and function allows these users to make informed decisions and pivot to secondary or tertiary workflows if and when they are needed. We took the time to guide the user through workflows by focusing on the next step (egs: auto focus on search for combo boxes, input boxes for non-serialized installs, and reference designator combo boxes). Edge cases were considered for every permeation of the design. While an “everything and the kitchen sink” approach isn’t always my tendency, the technician and engineer needed to know a ton of information about the part requirement and the inventory being installed.

Since our customers required anything from a little bit of information per part requirement (Name, Rev, Part number) to a ton of information (Name, Rev, Part Number, Multiple Substitutions, Reference Designators) and we needed to add links to the kit the inventory was in, a way to request the inventory, and a way to create an issue, the part requirement cards were becoming hard to parse. Our solution was to anchor key signals and the install functionality to the right side of the modal. This would provide users a glanceable area to understand what has or has not been installed, and it would be easier to install multiple parts without horizontal mouse movement.

Test Results

Once scenario in our unmoderated user testing prototype for the aBOM manager.

The current part requirement cards ordered the description first since that data point was typically used as the name of the part. This wasn’t nearly as useful as the part number. Our technicians typically memorized part numbers, and having a description instead of the number caused more frustration than not.

Since this was a Figma prototype, search was simulated. This caused a confusion and frustration (along with any other functionality that was beyond the scope of the test). It was noted multiple time that if search worked on part numbers, reference designators, and descriptions then this would be a huge win in the quality of life department.

75% of the feedback approved of the user interface for installs. Even though the cards were information dense, they allowed the technicians to make more informed decisions and thus less mistakes.

Due to the testing, we decided to move the part numbers to the primary position. Now users could easily glance through each card and ingest the information they needed in the proper order utilizing the Z pattern western readers typically use when ingesting an interface.

Conclusion

The redesigned Manager cut human error and saved time while boosting traceability accuracy and BOM flexibility, reaching 100% adoption within a month of beta release. It created financial value by streamlining installation, improving search, reducing errors, and combining workflows—all lowering assembly costs. When building R&D assemblies where parts get swapped or changed, the added BOM management features let users accurately update and version BOMs to match the aBOM, giving them precise reporting for every assembly. Customers gained flexibility at scale, using ION throughout their manufacturing process with fine-tuned permissions that reduced task time while maintaining critical safeguards. The improved search capability for part requirements lists and combo-box components dropped technician error rates below 5%, while the ability to modify BOMs during builds allowed customers to use from R&D through final assembly.

While this was a layup for the product team, it didn’t come without it’s own unique set of considerations. While I wanted to greatly simply the interface, our customers and our teams leaned heavily on “information is power.” When technicians and engineers are making decisions on mission critical assemblies, leaving anything to guesswork can greatly increase human error, create delays, and potentially have an assembly fail during a mission.

When discussing the importance of the Search functions, there was considerable push back due to the complexity of the full feature request. Did the feature really empower our users the way the design team envisioned? A few site visits and a few calls later, our engineers saw the real world pain some of the technicians faced when searching for the correct part requirement. These visits also super charged our engineers since they experienced first hand the incredible technology being built on the platform they build.

Prototyping in Figma can feel like magic, but the amount of time it takes to create a complicated and dynamic workflow with real-like data and interactions can be substantial. We couldn’t accurately portray the search experience, requiring our users to place trust in us. Once the feature was delivered, they felt empowered, and we gained a bit more trust.