The Inventory System Worked, But The Workflow Didn’t.
Confidentiality note: This project was completed under NDA. EcoGlobe is a pseudonym, and company, product, and implementation details have been anonymized. Supporting visuals were recreated to represent comparable workflows without revealing proprietary information.
Lead UX/UI Designer
Enterprise inventory and operations platform
Industrial manufacturing and materials processing
Warehouse operations, production, quality, and operations leadership
Project manager, engineering, and client stakeholders
2023–2024
Discovery, workflow analysis, product direction, requirements, information architecture, interaction design, implementation support, and design QA
83% faster
Inventory processing reduced from approximately six minutes to one
87% fewer errors%
Manual data-entry errors reduced from 15 to two per 100 entries
80% faster onboarding
Employee onboarding reduced from approximately ten hours to two
Table of Contents
Original Problem
Replacing the Software Would Have Preserved the Problem
EcoGlobe, a metal processing facility, needed to replace an aging legacy application used to receive inventory into the business. Every incoming item passed through it before moving into production, laboratory, and other downstream systems; which meant that mistakes in this system would followed the inventory throughout the entire process.
The original brief sounded like a standard software-modernization project: update the interface, simplify the existing application, and prepare it for future growth.
But, once I saw the work inside the warehouse, it became clear that a cleaner version of the same application would not solve the real problem. The system technically recorded the work, yes, but it no longer supported employees while they were doing it.
My Responsibility
I Followed the Work From the Warehouse Floor Through Release
I led the UX and product-design work from discovery through implementation. I had the unique opportunity to be on site for three days, where I observed the operation, mapped the current workflow, identified where the software and the work had separated, and translated those findings into a new product direction.
From there I worked with the product manager on priorities and alignment, and with engineering on requirements, permissions, validation, conditional behavior, edge cases, and implementation QA. Client stakeholders provided operational and business input throughout the project.
Inside the Warehouse
The Official Process Wasn’t the Process Employees Used
My initial request to interview and shadow warehouse employees was declined. Leadership believed the process was already understood, and pulling people away from production was a legitimate concern. I proposed something smaller: let me follow the work, document recurring patterns, and ask brief questions without stopping production. That was approved.
I followed inventory through receiving, cleaning, photography, identification, documentation, laboratory analysis, and production. Three problems kept appearing.
The Software Was Separated From the Work
Employees spent most of the day moving with inventory, but the application assumed they worked at shared desktop computers. Recording an update meant leaving the task, walking to a workstation, entering information, and returning to the floor. Each trip interrupted production and delayed data capture.
The Product Exposed Its History Instead of the Current Task
Years of departmental requests had accumulated inside the application. Warehouse employees encountered laboratory features, reporting tools, and administrative options that had little to do with inventory intake. Experienced employees knew what to ignore. New employees did not.
The Real Instructions Lived With Experienced Employees
When employees were unsure how to identify a part, locate a serial number, or complete documentation, they rarely looked to the software. They asked someone who had been there longer. The operation depended on knowledge the product did not contain.
The Paper Work Around
During one observation session, an employee struggled with the application, reached for a sheet of paper, and said:
“You know what… I’ll just show you what I normally do.”
That paper process was not resistance to technology. It was the workflow the employee had created because the official system no longer matched the job.
The application had become a place to document completed work after the fact. It was not helping employees perform the work as it happened.
That changed the direction of the project. I worked with the product manager to bring the operational evidence to engineering and client stakeholders. We recommended redesigning the platform around inventory intake rather than rebuilding the structure of the legacy application.
From that point forward, we tested decisions against one question: Does this help the employee complete the work?
Redesigning the Intake
Three Decisions Moved the System Closer to the Work
1. Bring the system to the inventory
- What I observed: Employees repeatedly left their work to enter information at shared computers.
- What I changed: I redesigned the intake experience for rugged mobile tablets so information could be captured where the inventory was being handled.
- The tradeoff: This required hardware investment and changes to workflow progression, validation, and downstream behavior. It was more involved than making the desktop interface responsive, but it addressed the physical bottleneck instead of preserving it.
2. Put operational knowledge inside the product
- What I observed: Routine questions stopped the work and made newer employees dependent on experienced coworkers.
- What I changed: I added contextual instructions, annotated reference images, and task-specific guidance at the point where employees needed them.
- The tradeoff: Stakeholders were concerned that broader access could expose proprietary knowledge. I worked with engineering to define role-based permissions that protected sensitive information without removing useful guidance from the workflow.
3. Organize the platform around tasks, not departments
- What I observed: Employees had to sort through features belonging to other parts of the business before completing routine intake work.
- What I changed: I reorganized the experience around the operational sequence. Each step presented the information and actions needed for the current task, then moved the employee into the next one.
- The tradeoff: This meant revisiting navigation, permissions, validation rules, and system behavior rather than applying a new visual layer to the legacy structure. It increased the implementation scope, but it removed complexity from the employee’s side of the system.
System Behavior
The Workflow Had to Hold Up When Inventory Didn’t Follow the Happy Path
The design could not stop at a cleaner sequence of screens. Inventory had to move reliably through permissions, required fields, conditional rules, downstream systems, and exceptions that did not appear in the first version of the workflow.
I worked directly with engineering throughout implementation instead of treating the designs as a finished handoff. Reviews focused on how the product behaved under real warehouse conditions: what happened when information was missing, when a role lacked access, when an item did not follow the expected path, or when validation conflicted with the actual operation.
Design QA became a feedback loop. When an edge case exposed a mismatch, we refined the workflow or rule before release.
After Implementation
Inventory Intake Fell From Six Minutes to One
The redesigned platform supported the work where it happened and guided employees through the intake sequence without requiring them to understand the structure of the underlying system.
Client-reported results after implementation included:
83% faster inventory processing: Average processing time fell from approximately six minutes to one.
87% fewer manual data-entry errors: Errors fell from approximately 15 to two per 100 entries.
80% faster employee onboarding: Time to prepare employees for the workflow fell from approximately ten hours to two.
The larger result was that critical operational knowledge no longer lived only in the heads of experienced employees. It became part of a system that could support more consistent work, cleaner downstream data, and future growth.
What Changed My Approach
Employees Had Already Redesigned the Process for Themselves
This project changed what I look for when someone asks for a redesign. The visible interface may be outdated, but that does not mean the interface is the real problem.
The most valuable part of my work happened before I designed the final screens. It was getting close enough to the operation to see that employees had already redesigned the process for themselves, then using that evidence to help the team solve the right problem.