Fulfillment Center (FC) Handheld App
When I joined the team, Nogin’s warehouse team relied on manual processes, including pen and paper, and limited technology usage for their fulfillment tasks. Many hours were spent on manual WMS updates, error correction, and physical product investigations.
To solve these issues, I designed a custom handheld scanner app to streamline the manual processes, update the WMS in real-time, and improve operator efficiency.
My Role
Platform: Mobile, Web App, B2B, Fulfillment, eCommerce
I was the project lead for this app, wearing both PM & Lead Designer hats. I was responsible for the project from project definition, through design and testing, to handing off to engineering, and post-production support.
Project Goals
At the start of this project, the fulfillment center managers knew that using handheld scanners would be a crucial part of making the team more efficient and lowering operational costs. We set three discrete goals for the handheld app project.
We needed to streamline operations so that the app could be as efficient as possible.
The app should keep operators on task while moving through their work.
The app should eliminate as many human errors as possible.
Research & Discovery
When we kicked off this project, I spent a few days pouring over onboarding packets for new hires, shadowing FC workers as they did their jobs, and documenting everything I saw. We knew that we were going to build an app to support workers on the FC floor, and this research helped suss out the biggest pain points for workers and showed us the importance of fine-tuning the workflow of operators.
Understanding Warehouse Operations
During the research phase of this project, I documented the 4 main warehouse operations that we would focus on for the app:
inbounding products
outbounding products
investigating products
storing and retrieving products
When I shadowed workers, I asked a lot of questions to understand what they were trying to do, and why they did it the way that they did. A lot of the time, I was given perfectly valid answers. This is how I was trained. I pick all the items from this brand at once because they’re in one section. etc But there were a few places where I could ask probing questions that uncovered some gaps where if the process were tweaked a little bit, it could run more smoothly.
For example, when picking for Brand X, wouldn’t it be more efficient if the pick lists were in order so that you’re always moving forward instead of returning to previous locations?
I started to design flow charts based on the feedback I got from the FC leads and operators.
Workers relied on 10-15 page printed lists and highlighters to manage their work.
There was a 2 month backlog of products that needed to be processed.
While orders were signed off by hand, the WMS was never fully up to date.
Ideation & Concept Development
Updated Flows
The user flows I first made were quite complicated showing “if/then” connections. So I decided to simplify them by using journey maps. Journey maps are a great way to show the path of what users are doing, in relationship to everything happening around them. They don’t focus on the if/then consequences, but on the main path to achieve their goals.
These journey maps included:
What the FC Agent (our protagonist) is trying to do
What other people (NPCs like truck drivers) are doing that impact the Agent’s flow
Physical locations in the FC (where the action happens)
Software UI - what screens the agent sees
Automagical backend - what is happening in the data layer of the app
In my work, I’ve found that journey maps are a great way to get non-technical stakeholders to buy into the project, and they make it easier for engineers and designers to understand the correlation between the software and the real world.
I used dotted lines to show how external, internal, and backend actions can occur simultaneously and influence each other. Different color coding (blue and green) depicted the varied workflows of the two fulfillment centers, while highlighting the shared goals, locations, and agent interfaces.
Prototyping & Testing
To accompany the journey maps, I pitched wireframes laid out like a flow chart so that we could see every screen of the app (including error states) for each workflow. This helped the non-technical users visualize the app, and it also showed where the screens and steps could be refined.
Once I got buy-in on these wireframe flow charts, I built realistic-looking prototypes using Figma. When testing these prototypes, I was able to make updates to the comps in real-time. It was a treat to see the delight in testers as they were giving me feedback that could easily be incorporated.
I designed the app to urge the operator forward in their task, step by step. Screens update as users take action, and they only have the ability to move forward or backward in their task.
Keeping Agents on Task
In discovery, I found that agents were often distracted mid-task and much time was wasted trying to remember what they had been doing.
To help keep them focused, I designed an interface that shows them exactly what step they were on in their task, what they just did, and only allows them to move one step forward or back in their work.
Eliminate Errors
When the FC team used pen and paper to track their work, the WMS had to be manually updated, leading to potential mistakes. To solve this, I added automatic validation between steps.
For example, if an operator tries to assign products to a location already allocated to a different SKU, they are alerted to scan a different location or confirm the combination. With the app's automatic updating of the WMS, these types of errors were effectively eliminated.
Development & Build
For this project, we outsourced dev to an engineering company in India. While we had a good working relationship with the team, I had run up against issues with how long it would take to answer questions because of our time difference. Since this project was urgent and we needed to get up and running as fast as possible, I went a bit overboard on my documentation.
I created extensive documentation in Confluence, including photos I had taken of the warehouse, wrote out the epic and supporting tickets in Jira, and finally, I created video walkthroughs of the prototype and comps, explaining the design decisions, what users were trying to do, and the environment they were in. My whole goal was to be thorough enough (with whichever medium worked best for the engineer - a wiki, tickets, or video) so that they could implement the best solution possible with minimal confusion.
It worked! The team came back to me with only a couple of questions that were about very specific fringe cases I hadn’t considered, and they were able to complete the build within two sprints. We got to testing, and within a sprint of receiving feedback from the FC teams, we went live, and the team started to use the handhelds.
Final Results
The project was a huge success. When we started, the average order to pick-and-pack time was over 5 business days. After launch, that time dropped to less than 1 business day. The team had a 2-month backlog of inbound items when we started. At the end of the project, returns were processed in under a week, and new product was processed and ready to be picked within a day. Additionally, significantly less time was spent trying to triage misplaced items. The ability to scan any item with a barcode in the FC instantly told workers what it was, where it belonged, and who had handled it last.