Redlines

ION Factory OS

Case Study

B2B SAAS

Sr. Product Designer

Read Time: About 5 minutes

What are Redlines?

At First Resonance, we enhanced a crucial feature the Run Execution module of ION Factory OS called "Redlines." In technical drawings, redlines signify changes or corrections to be made to a project or document. ION Factory OS delivers work instructions to technicians, and the Redlines feature allows users to update those instructions in real time to correct mistakes during hardware production.

Problem Statement:

Engineers struggled with the Redlines feature in the Run Execution module, wasting up to 8 hours manually merging work instructions across multiple production runs. The platform-wide inconsistent approval processes, repetitive manual submission and merging processes, and lack of change history visibility made it difficult to manage appending build instructions effectively. These problems sometimes led to delays and repeated mistakes, particularly during parallel production of multiple units.

Business Goals

Simplify repetitive processes and wayfinding to decrease time on task for all redline workflows. Add automation to reduce human intervention.

Implement contextual decision support and configurable approval gates. Target 50% reduction in processing errors through improved UI guidance and automated validation.

Develop priority integrations with customer tech stacks (e.g., ERP, CRM). Create unique workflow automation features for redline processing to drive 30% efficiency gains over standard solutions.

Impact & Results

Time Savings: The time spent merging redlines across multiple runs decreased from 8 hours to under 5 minutes.

Streamlined Review Process: The unified review workflow automated adding required reviewers. Decreased errors through familiarity and glanceability. Gave organizations granular control over review gates.

Improved Transparency: Engineers can now access the entire history of changes along with all comments made during the process increasing accountability.

Scalability: The new merging feature allowed changes to be easily propagated across multiple work instructions, making the system scalable for factories producing hundreds of units simultaneously.

Actual footage of me using the beta Redline featues, rendered at 1.5x for the 2024 roadmap video.

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

2 Sprints, 2 weeks each

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 5 customer factories. These customers were building eVTOLS, satellites, microgravity pharmaceutical production plant, satellite busses, 3d printed rockets, and electric watercraft. Ethnographic research was conducted with the entirety of Run Execution in mind and the systems that impact it. Remote interviews were conducted for specific feature sets. For Redlines, we interviewed 5 teams remotely. Insights were also gathered and graded in product board from multiple sources, and a curated list of insights were compiled with the research findings.

The legacy Redlines workflow with key areas of opportunity. Link to FigJam.

Create a streamlined feedback loop to increase context and capture feedback in one location per redline and merge. Deploy customized notifications based on user preferences. Keep context between reviewer and author.

Requiring Authors to submit approved redline changes is an unnecessary and expensive human intervention when the system can auto-submit approved Redlines and Merges.

Standardize the Review UX across the platform. Indicate which teams and personnel are responsible for reviewing the content and processes.

Stretch Goal: “Approve from Anywhere” approval manager allowing reviewers to quickly access and review all requests (redlines, merges, quality, procedures, standard steps).

Allowing for bulk actions while assigning Reviewers will reduce time spent on tasks.

Allowing users to Merge one redline to many Runs and Procedures will reduce time on task.

Reviewing all Merged Redlines in one place would greatly reduce time on task.

Showing the changes that have occurred and displaying those changes in a history tool will further enable decisions around Merging and versioning.

Stretch Goal: GitHub style live Diff

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, design artifacts, and technical feasibility.

During the kick off meeting for Redline feature set, 2 features were identified as requiring additional or extensive backend engineering time: Live Diff Tool and Auto Submit.

Due to the ION’s architecture, there was no way of showing a live Diff currently, and any changes made to the step(s) during the Redline process could only be shown after the Redline(s) were submitted after the approval process.

There was no server-side functionality to auto-submit Redlines after approval or after Merging Redlines to other Runs.

During the first design sprint, I was able to streamline the design workflow to concentrate on the review, history, and merge user flows. One of my goals was to give reviewers the context they needed to make informed decisions without a live Diff tool until we were able to complete that feature in the future.

During the engineering discovery for the Diff tool, we discussed solutions that wouldn’t require user intervention. Ultimately, these solutions would require more engineering work and thus take time from other efforts, including the Live Diff effort.

The solution that satisfied our engineering constraints and user needs was to create a new “state” for the step. Technically, “Redline” was a “state” of the step, and changing the state of the step would commit all changes to the step. If we created a “Redline Review” state, then the changes in the Redline could be added to the history of the step, the step would be un-editable until put back into the “Redline” state, and all of the other dependencies would still remain. From a technical perspective, this was a win win since it required minimal backend engineering work and the Reviewers would see the Diff in the history component.

The updated Redline and merge workflow. Link to FigJam.

To further streamline the functionality, we decided to combine the Review and Merge workflows into one component with the History component showing the Diff. This would allow for the Author to not only request a review of the Redline changes, but also a review for Merging to Procedure and Run Steps.

The final Review and Merge modal would allow for reviewer management, contain the step history and diff, allow for communication, manage Merges, and allow for bulk operations.

Redline Review and Merge testing prototype.

Test Results

The new Review step state, while a compromise based on our technical review, did not meet the needs of most of our customer’s workflows. It was viewed as an unnecessary gate and needless extra click. The Diff state is important, but until we were able to show the live Diff, our customers would rather use the communication tool in the Review modal to indicate any updates.

Approving Redlines and Merging Redlines are two separate workflows for 90% of users. While the function of Merging Redlines was easy, the functionality caused more confusion than clarity.

80% of the feedback indicated that the approach seemed easier to manage than what was in the legacy application. Being able to manage Reviewers in one place while identifying separate reviewers per redline in one place simplifies the process. The heatmaps and playbacks backed this up by indicating users were able to clearly identify each section and it’s functionality.

The Redline and Merging workflows for beta release. Link to FigJam.

Due to our customer’s feedback, we decided to remove the “Review” step state and separate the Merge functionality from the Review functionality. This delineated the two processes, matching the mental model of our users.

Since Merging a step can take place any time after a Redline is approved, we combined Merge tool with the Redline history tool to give the user more context during the process.

The Engineering team was able to allow Merges to auto-submit upon approval.

Review gates across the platform were upgraded to give the organization more granular control over credentials and automate the process.

Review teams or users could be automatically added to required Reviews
Reviews would not be required for users with the correct credentials
Review gates could be turned off completely
Approved Merges could be set to auto-submit upon submission.

Redline Review and Merge testing prototype.

Conclusion

This project exemplified the impact of thoughtful UX/UI design in a complex, high-stakes manufacturing environment. By leveraging user research, iterative design, and collaboration with engineering, we transformed a tedious process into an efficient and scalable workflow. The redesign saved significant time and enhanced the transparency and traceability of changes, empowering users across the organization.

One hurdle I faced during this process was managing the bias presented inside of institutional knowledge. There were many points where I received pushback from our SMEs about features or parts of the workflow that didn’t align to their past lived experiences. While these biases still informed our decision making, I was able to broaden the conversation with ethnographic research, customer conversations, and user feedback in prototypes and surveys.

While researching and testing remotely with customers, feedback was typically positive. We were blending their feedback with the rest of the research we collected, and our solutions were typically met positively. The feedback from these leadership teams would often differ from the reality on the manufacturing floor. Without unmoderated user testing, we would still operate inside a smaller vacuum of ideas and truths.

As you read, there were hurtles that needed to be crossed before the full feature set could be released into production. By including a backend engineer in every milestone meeting, and by conducting discovery meetings with them, we were able to identify issues and mitigate possible solutions early in the design process.

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. Also, the more real the prototype feels to users, the more they are to explore areas that are not inside the Figma prototype. Being able to test a coded prototype using customer data in their sandbox, just like an alpha or beta release, would have opened the door to better data and feedback.

The live Diff view requires changes to be “streamed” as they happen and display where they happen on any screen that is displaying the step. Other technical hurtles will need to be overcome for this feature to become available.

The live History view requires changes to be “streamed” as they happen. The changes will be captured in the History component. The Redline History component can be viewed from the Redline Review modal and the Merge modal to add context to decision makers. The Review modal can be opened from a notification anywhere in the application, allowing decision makers to explore changes, navigate to where those changes occurred, and approve or reject from anywhere in the operating system.