Redlines
Factory OS
Lead Product Designer
Lead Researcher
Design System Lead
Read Time: About 4 minutes
Redlines? Like Those Redlines?
At First Resonance, we enhanced a crucial feature the Run Execution module of ION Factory OS called "Redlines." Redlines in the technical world differ from the UX definition. In UX, "redlines" are often spacing or sizing guidelines, while 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.
We aimed to streamline and enhance the Redlines workflow, improving usability and reducing time-consuming manual processes for technicians, engineers, and quality assurance (QA) teams.
Actual footage of me using the beta Redline features, rendered on a MacBook for the 2024 roadmap video that I directed, filmed, edited, and rendered. Watch the entire roadmap video on YouTube.
Problem Statement
The legacy Redlines feature in the Run Execution module—where technicians follow step-by-step instructions to build hardware—was cumbersome and inefficient. Key issues we identified through audits and customer research included:
- Cumbersome Workflow: Redlines were initiated quickly but required significant effort to complete.
- Data Collection Issues: Issue tickets didn't show the related redlines, making tracking and troubleshooting difficult.
- Approval Confusion: Approval processes varied unnecessarily across the app, lacking clarity and consistency.
- No Redline History: Users couldn't see the history of changes made during the redline process, leading to confusion.
- Inefficient Merging Process: Merging redlines across multiple work instructions was time-consuming, often requiring up to 8 hours for a single engineer to manually merge steps across several runs.
This inefficiency led to wasted time and frustration, mainly when factories produced multiple units or prototypes simultaneously, where similar mistakes occurred across all builds.
My Role
As Head of Product Design, I led a team of two through the entire product design process, which included:
- Research & Synthesis
- Requirements gathering
- Design strategy
- Creation & maintenance of the design system
- Persona development & user flows
- UX/UI design & UX writing
- User testing, beta testing, and post-release research
This project spanned roughly a month, with an additional three weeks of testing, iteration, and finalization for handoff to engineering.
This is the first prototype I created for redlines. My first theory was to group reviews and merge into one component. During testing and additional research, I discovered that as our customers grew, they would want engineers to approve redlines, and then, senior engineers would need to approve merges separately. I also found that the history of a redline is more critical for merging. The new components were arranged into the "Redline Review" and "Merge and History" modals.
Solution
To tackle the inefficiencies, we redesigned the Redlines feature from the ground up, focusing on:
- Mirroring the Procedure Interface: The interface now mirrors the one engineers use to write work instructions, making it more intuitive and consistent.
- Improving Traceability: We connected redlines to issue tickets and data collection forms, enabling better tracking of changes.
- Unified Approval Flow: A universal approval process was implemented across the platform to ensure consistency and clarity.
- Redline History & Diff Tool: A history component was added to track every change made, and a diff tool was developed to highlight modifications for easy review and approval.
- Streamlined Merging: The merging process was revamped, reducing the time spent merging redlines from 8 hours to just under 5 minutes.
The improvements drastically reduced manual effort and increased accountability and transparency across teams. Engineers could now quickly approve or reject all redlines in one place, with full access to the history and comments associated with each change.
By simplifying redundant manual tasks, improving redline and issue traceability, increasing the transparency between user transactions, and introducing a history component the new Redline feature set minimized time on tasks for our customers.
User Flow: The Redlines Process
- Identify the Issue: If a technician notices an error (e.g., installing the wrong part), they put the step into redline mode.
- Stop Execution: Redline mode halts work on the affected and dependent steps.
- Create Issue Ticket: A ticket is created to document the problem. The redlines are automatically referenced in the issue ticket, and the redline references the issue ticket number.
- Add New Work Instructions: The technician or engineer adds one or more steps to correct the issue and assigns the task to the appropriate team.
- Approvals: Reviewers are selected and added to each redlined step in the Run. Reviewers and authors can leave and track comments. Reviewers can reject or approve with or without comments. Once approved by all reviewers, the redlines commit allowing users to start the step.
- Merge: Any approved redline can be merged to other runs. Users select every run/step the redline will overwrite. Depending on the organizational permissions, a review might be required. Each redline is committed to every run/step all at once.
Research & Insights
We began with a thorough research phase, engaging with both internal teams and external customers:
- Institutional Knowledge: We leveraged employees' expertise from hard tech companies like SpaceX, Toyota, and Boeing, understanding their workflows and pain points.
- Customer Research: We interviewed 24 users across eight customers. We conducted ethnographic research for three customers, visiting factory floors to observe their workflows and identify challenges firsthand. Since the other customers were scattered across the US and Australia, we depended on virtual meetings.
Key Findings:
- The approval and merge processes were tedious, often taking hours to complete if there were many merges.
- The lack of a "Redline History" and diff tool made it difficult for users to understand what had changed.
- Merging redlines across hundreds of steps and multiple runs was manual and time-consuming.
These insights formed the foundation of our redesign, prioritizing efficiency and usability.
The original "Redline History" and "Merge and Review" modals seen in the prototype video above.
The "Review Redlines" modal and the "Redline History and Merge" modal that went into production. The "Review Redlines" modal shows a comment being written and a comment that has been left. The "Redline History and Merge" modal shows the redline merging into three steps on three separate runs.
Design Process
We followed a structured design process that included:
- Design Sprints: We conducted sprints and internal reviews to validate the designs with stakeholders and engineers.
- Prototyping: Over 90+ Figma artboards and complex prototypes were created, highlighting key workflows.
- Testing: We ran internal and external testing using Useberry for unmoderated tests and Figma prototypes for moderated sessions.
- Iterate & Improve: After gathering feedback from customers and stakeholders, we iterated on the design, fixing pain points and making final adjustments before handoff to engineering.
Implementation Challenges
Figma Performance:
Managing all feature components and workflows in a single Figma file led to performance issues. We resolved this by simplifying design system components, cleaning up design debt, and splitting prototypes into separate files. This allowed us to work more efficiently and run prototypes smoothly.
Testing Complex Features:
Some features, such as the new rich text editor for work instructions, were challenging to prototype in Figma. However, we successfully tested all other features, like the approval and merge workflows, with internal teams and external customers.
Results
The redesigned Redlines feature significantly reduced the manual effort of approving redlines and merging redlines. We also increased the transparency of the data by introducing history and communication components. Key benefits included:
- Time Savings: The time spent merging redlines across multiple runs decreased from 8 hours to under 5 minutes.
- Improved Transparency: Engineers could now access the entire history of redlines and approve or reject changes along with all comments made during the process from a single location, increasing accountability.
- Streamlined Approvals: The unified approval workflow simplified decision-making and reduced team confusion.
- 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.
The "Review Redlines" modal shows all redlines that have not been fully approved. The user can easily see which reviewers haven't approved, add reviewers, see all feedback, approve/reject all, or manage these features per redline.
The history component used in the "Redline History and Merge" modal is a filtered view of the history of the Run. The user only sees the history of the changes during the redline process. While this was the phase 1 approach, Phase 2 would allow users to see the history in the Review modal as changes were made. In Phase 3, we planned a full "Diff" feature.
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 of my esteemed colleagues suggested creating a "movie poster" for each feature set we were redesigning. These 13"x19" posters were framed and hung in the office. The names have been changed to protect the innocent.