UX CASE STUDY --- Space Manufacturing10 months to redesign a manufacturing management system
How I designed and shipped a production floor management system for an aerospace additive manufacturing floor.
My role: UX Designer + PM + Product Owner
Project Context
3 people: 1 software dev, 1 machine operator, & me!
Team
150+ daily users across 6 roles
Users
450 - 2,000 engine parts produced weekly
Scale
10 months - hard deadline
Timeline
TL;DR
Long Story Short…
Situation
Our software was taken away with no viable alternative
A central Enterprise Technology team informed the Additive Manufacturing (AM) department that they would be disabling the software tools that we used to manage the AM floor including machine setups, build tracking, traceability, powder testing results, Non-Destructive Testing (NDT) results, anomalies, machine onboarding, and more.
In October of 2023, were told that this tool would be unavailable to us starting in July of 2024.
This gave us 10 months to come up with a new solution.
Task
Develop & implement a solution to keep the floor running
Identify or develop a new tool that can take over all of the function of our existing production floor management system, and ideally improve on known weaknesses in our process.
The tool should be built for use by over 150 users across 6 different groups including machine operators, materials and process engineers, managers, design engineers (AM customers), post-processing teams, and AM engineers.
Action
Design & build a new ITAR compliant system
Work in a team of 3 (myself, a software developer, and a machine programmer) to build a new system that is user-forward and meets all ITAR and quality requirements.
I pitched solutions and worked to obtain approvals from the enterprise technology team in order to move forward.
Ultimately, we needed to completely switch the operations team onto this new system by the sunset date of July so that there was no production downtime.
Result
Successful rollout with zero production downtime. Serving 1000+ users now.
The development and rollout was completed on time and with zero production downtime due to duplicating data inputs while we tested out the new system and made improvements.
The system now serves over 1000 users, and the head of IT at Blue Origin dubbed our solution “the perfect fit” for Blue’s needs according to a LinkedIn post.
Get ready to dive into…
The Long Story
PROJECT SUMMARY
Team Structure across AM customers & operations
Existing system shutdown in 10 months
This system ran the entire additive manufacturing floor
Hard deadline, if the software wasn’t fully replaced in time, the floor couldn’t operate
ITAR compliance and quality traceability are primary requirements
01 THE STAKES
02 UNDERSTANDING THE SYSTEM BEFORE DESIGNING
I was a Process Engineer, so I understood the system, it’s strengths, quirks, workarounds, and weaknesses
I was a user for the system I was designing. I was close with all users, giving me a strong design foundation
① I defined requirements with users, not for them
I ran requirements and sign-off through the actual end users instead of a formal approval chain, so alignment was built in from the start.
② I mapped where the old system was failing
The old system allowed for too much flexibility on the operator’s side. Many operators built custom versions of our approved processes, meaning that engineers downstream couldn’t tell which variation was followed.
③ I identified which users had the most power and pain
Since operators had the power to accidentally corrupt data, engineers had to work with the pain of untraceable parts or inconsistent data. This sometimes led to scrapped parts.
In my solution, I constrained operator inputs by locking input columns and removing customizable checklists. To read more about this, see my HCI Theoretical Analysis on this specific part of the project!
03 NAVIGATING AN APPROVAL MAZE
The most difficult part of this process was navigating an approval process that consistently moved the goalposts and offered no viable path forward.
Understanding how to keep making progress through that environment became just as important as any design decision I made.
ET initially directed us to use a simple spreadsheet tool, but what we needed was a relational database (a system where data could link across records and communicate in both directions). A spreadsheet fundamentally couldn't support that.
My team researched alternatives, identified Baserow + a low-code app builder as the right fit and presented a full requirements mapping to make our case.
ET approved Baserow, but blocked the low-code app builder we needed alongside it to handle custom logic and automations, citing budget concerns, even though I had mapped out the cost and the proposed solution cost significantly less than the system we were replacing.
When we asked for software engineers from their team to help fill the gap, they declined. When they redirected us to another internal team, that team was unresponsive. This pattern of surfacing a requirement, meet it, only to get blocked on something new repeated itself for months.
HOW I RESPONDED
1 - Build the business case formally
I mapped every requirement against approved tools and our proposed alternatives. I then presented them side by side, in plain language.
When that wasn't enough, I wrote a formal business case and brought in the AM director to present directly to CT's management.
2 - Start building before everything was settled
Waiting for approval would have meant never moving forward, so we started building before sign-off was final - a risk, but one I was willing to take to meet our deadline.
We did have to restart twice as requirements shifted, but each restart was faster and we learned quickly what features were truly necessary in the rebuild.
3- Cut scope and learn to code
With a 3 person team and our dev engineer at only ~20% capacity, losing our low-code option meant cutting every nice-to-have feature and building in React inside an existing internal app.
The machine programmer and I learned enough to help code, and I rebuilt the plan around what we could actually ship.
4 - Design for change
Because approvals kept shifting what we could build, I designed features to be modular from the start and used feature flags so we could ship incrementally. I kept technical documentation current with every iteration, both to speed up future approvals, and to keep the team aligned on where we stood and what could be deprioritized if needed.
04 DESIGNING FOR REAL PEOPLE IN REAL CONDITIONS
Designing for this environment required holding two very different contexts in mind at once. On the production floor, operators are moving between machines, wearing PPE, working with tablets in gloved hands in a loud environment. The old system had been designed for desktop with small buttons, multiple browser tabs, and with no consideration for how it would actually feel to use it in those conditions. At the same time, process and M&P engineers and managers were reviewing the same data on desktop computers, often looking across multiple records to identify patterns or anomalies.
01 - Glove friendly, mobile-first design for operators
I focused on large touch targets, simplified data entry, clear task completion states, and auto-save so operators didn't have to worry about losing progress. The previous system required navigating multiple interfaces to complete a single machine setup task. The new design consolidated everything into one interaction per task. I also made sure the experience translated seamlessly between iPad and desktop so we weren't maintaining two separate systems.
02 - Giving process engineers structure, not just visibility
Process engineers were responsible for identifying and resolving anomalies that often showed up long after the original issue occurred — missing powder sample data, NDT gaps, tensile failures without traceable context. They had visibility into a lot of information, but no structured way to flag problems and move them toward resolution. I designed a continuous improvement intake where anyone on the team could submit an issue alongside a proposed fix, and I led triage sessions with managers to delegate ownership of each item. It gave engineers a clear path from problem to resolution rather than leaving them as the informal catch-all for everything that went wrong.
03 - Spread out the good ideas
Something I hadn't anticipated going into this project was how much energy I would spend managing enthusiasm rather than resistance. Users had been frustrated with the old system for a long time, and they were genuinely excited to contribute to the new one. After every major constraint change forced us to redefine scope, I ran prioritization sessions with users to re-anchor the team to MVP and make sure the features we were building were the ones that mattered most.
Learning to say "not right now, and here's why" was one of the more important skills I developed on this project.
05 LEADING WITHOUT A TITLE FOR IT
My title throughout this project was Process Engineer II. I wasn't formally the project manager, the product owner, or the design lead. I stepped into all three of those roles because the work needed someone, and I was the person on the team who understood both the production system and the people who depended on it. What I've learned is that leading without a formal title means you earn trust through the quality of your decisions and your ability to give people clarity when things are uncertain, which is something I've always valued and tried to practice.
When scope had to be cut (which was more often than anticipated), I ran that conversation with users directly so the decisions felt collaborative rather than imposed. People were understandably frustrated with the pivots, but they remained genuinely invested in the project.
HOW THE TEAM WORKED
The machine programmer was fully dedicated to the project. I was splitting my time about 50/50 with other engineering responsibilities, and our software engineer had roughly 20% of his time available. We were a small team working with limited bandwidth.
One of the hardest challenges, honestly, was keeping scope contained when people were excited to contribute more than the timeline could support.
06 TIMELINE
Months 1–3: Discovery, requirements, and approvals
User research.
Requirements documented and mapped.
First software proposals submitted and rejected.
Business case built, and approvals loops began.
Prototyping started in parallel.
Months 4–6: Low-code tool rejected. Pivot to custom build.
Approval conflicts.
Team convened, scope cut to bare MVP in collaboration with users.
Project management reorganized to reflect new reality.
Machine programmer and I began learning enough to contribute to development alongside the software engineer.
Months 7–9: Build, test, and iterate
Modular feature development with feature flags.
End user testing sessions.
Both old and new systems running in parallel (for redundancy so that we still had room to fix, add, and remove features).
Continuous documentation for IT submissions.
March 2024: Pilot rollout
Controlled launch with dedicated training sessions by user group.
Refinement period built in before full rollout.
April 2024: Full rollout, with both systems remaining active
Old and new systems running simultaneously.
Data reported to both for full redundancy.
July 2024: Old system sunset
Full transition complete.
07 RESULTS
Outcomes at Launch
Standardized QA checklists
Reduced manual entry errors
Improved anomaly traceability
Delivered on time
One Year Later
Enterprise Technology had approved Baserow only as a partial component of a larger stack, not as the central hub we had envisioned and argued for. One year after the system launched, Baserow's founder posted publicly about the company's adoption of the platform at Blue.
The platform we evaluated, advocated for, and built on became the company's central hub for manufacturing data at scale. While it took a year for the outcome to prove that this was the right move for the company, I am proud to be one of the people that fought for it.
“Nearly 1,000 people across the Engines, Lunar, and Alloy teams now collaborate on Baserow. Production data moved out of scattered spreadsheets into a single real-time hub. Customers have full visibility into production order status. All manufacturing sites share real-time data, with secure on-premise and air-gapped deployments.”
The React-based interface tool we developed in tandem with Baserow is still in use today, and is continuing to be built upon to include all of our “nice-to-have” features we had to delay in order to build the minimum viable product on time.
08 REFLECTION
I left the company before the system went live, as part of a company-wide reduction in February of 2025. However, my manager's reflection on the project success afterward stayed with me:
"The reason it succeeded on rollout was because of the way you set up the project and the team for success."
I think about that a lot, because the outcome really wasn't determined at launch, it was determined months earlier, in how requirements were defined, how the team was structured around a shifting set of constraints, and how consistently users were treated as collaborators rather than recipients of something being built for them.