Unifying maintenance and warehouse fulfillment workflows
My role
Lead Product Designer
Timeline
July - August 2026 (8 weeks)
My team
4 client stakeholders, 1 solution architect,
3 back-end engineers, 1 front-end engineer
"That's part of the reason what sent us down this path — that disconnect between the warehouse and the maintenance ticket."
-- Ryan · Director of Information Technology
01
CONTEXT
40% of repairs wait on a part that lives in another system.
Club Car Wash ran two systems side by side. Store managers reported maintenance requests in FMX. The warehouse managed order fulfillment in FlowTrac. Nothing connected the two.
So from requesting a part to chasing its status, a store manager or technician had to email or call the warehouse before any work could start. The warehouse paid for it too — answering the same questions by phone all day, with no way to point anyone at a status they could see for themselves.
I led the end-to-end product design from discovery to implementation, using an AI-assisted development tool to build a prototype in code that accelerated product delivery in 8 weeks.
02
WHO & WHY
5+ interviews reveal the frustration and costs of invisibility
I ran contextual inquiries with technicians and warehouse staff, and interviews with the people who own the process. The pattern was the same everywhere: the coordination that mattered happened outside the software. A technician would drive to a site and find the part wasn't there. The warehouse spent its day answering the same question — where is my order — because nobody could see the answer for themselves. Both cost real money.
Mapped the journey end to end
After the user research and the workflow walkthrough, I drew the full path from a fault being reported to a job being closed. This enabled not only internal alignment but also stakeholder for the end goal.
The diagram links both technician's side and the warehouse's side:
create → assign → request parts → fulfill → complete → close.
Defined the roles and what each one does
To cater to the diverse user needs, I defined and aligned with the stakeholders to meet the business rules and the real-world context. The system serves both the frontline teams and the operations team. Each team has multiple user roles for different permission models. The personas in this case study are simplified to strengthen the distinction between different responsibilities.
Technicians
(Frontline)
-
Request parts
-
Execute the work
Warehouse team (Frontline)
-
Fulfills, Packs, Ships
-
Receives against procurement
Store manager/ Operation
-
Create / manage maintenance task
-
Submit store order
-
Oversee work status
Restructured the workflow with what people actually need
From the walkthrough, I saw the platform's features got in the way or workround instead of helping:
Respond was doing four different jobs at once — communication, expense, redirect, report work completion. I grouped every function with stakeholders based on real usage and surfaced the actions that deserve an individual status to give a clear read on what happened and what comes next.
03
FOUNDATION & IA
6 modules, 2 modes that support the multi-persona needs
One product, several roles, very different situations. A technician is standing at a machine with wet hands; a manager is at a desk looking across sites. Rather than build two products, I split the interface into two modes — execution and management — and let role and context decide which one someone gets.
Information architecture & Navigation map
Worked with engineering on the underlying structure, since the product leans heavily on ServiceNow's architecture and data model. Agreeing it early meant the IA and the backend matched instead of being reconciled later.
The optimized interaction pattern
Execution mode is built for speed and error prevention — few choices, hard to get wrong, usable one-handed. Management mode is built for depth — filtering and drill-down that don't overwhelm.
The client wanted the emphasis on execution and on-the-go editing, so frontline users can adjust a work order to match what's actually in front of them.
The actions that move the record, and gated by the context
The status barely expresses the work status in the real world. The work order stays in "Open" status, and users have to open the record to see the status in the response.
Request parts and Complete work aren't only features. Each one advances the record to a stage: Awaiting parts the moment a part is requested, Resolved the moment the work is reported done. The status now carries what happened, so anyone scanning a list knows where every job stands without opening a single one.
Only the actions that apply are shown. A closed work order offers Re-open and nothing else — and only to a store manager.
04
SOLUTION
One shared record, one status chain
The same record connects the technician who needs a part and the warehouse that fulfills it. Each role then sees only the part of it that matters to them: the technician requests, the store manager tracks the order, the warehouse traces which job it came from.
Step 01 · Technician (Mobile)
Request the part from the job
Technician orders parts when reviewing the request, the parts readiness controls the work request: Awaiting parts or Ready to work.
Step 02 · Tablet · Warehouse
Pick from a queue to fulfill
Only orders that can actually be filled allow users to start picking orders. Users can transfer the order to another warehouse with sufficient stock to avoid delaying fulfillment.
Step 03 · Technician (Mobile)
Resolve the job with what was actually used
Parts used and hours worked are captured in the same step that closes the job, rather than in a form afterwards. This ensures the stock system reflects the actual consumption.
Step 04 · Operation Team (Desktop)
Only the actions that apply, for the people allowed to take them
Everyone works from the same record, but the buttons change. Request parts, Resolve, Close, and Re-open appear only once a job has reached that stage, and only for someone permitted to do it.
