SO Logistics: making warehouse records dependable

SO Logistics needed to replace paper recording across four warehouses without slowing the dock. Operators had to capture vehicle details and photographs while checking goods, speaking with drivers and keeping queues moving. Those records also had to hold up later, when a delivery or damaged-goods dispute needed investigating.

As the sole product designer, I worked from remote discovery and comparative testing through build review and rollout. The work covered how operators completed a task, what happened when something went wrong, and which details the record needed to retain.

Through conversations with operators and the warehouse team, I mapped a process that left one vehicle movement in three places: a paper entry, separate photographs and a later cloud entry. Missing information was difficult to reconstruct during a dispute. Without enough evidence, the warehouse sometimes absorbed the cost.

A photo-focused app was discussed as a smaller starting point. It could make pictures easier to find, but would leave paper errors and duplicate entry in place. I proposed bringing the details and photographs into one task, with a record that could survive interruptions and reach the warehouse even when the connection failed.

Operators initially preferred a long form because fewer screens and Continue actions appeared quicker. I was concerned that scrolling between details and photos would make omissions harder to notice. Rather than settle this through preference alone, I designed both a long form and a stepper for comparison.

Around 20 operators from incoming and outgoing teams across all four warehouses used both builds repeatedly over four days, during real vehicle movements. I held remote debriefs, grouped recurring issues by workflow stage and reviewed them with developers and the warehouse manager.

The stepper separated details, photographs and review. We accepted the extra Continue actions because operators could check one stage at a time instead of searching a long page to decide whether the task was complete. This was a decision based on repeated use and feedback, rather than a measured speed improvement.

The pilot also exposed incorrect entries and missing evidence. I added field-level validation, changed pallet quantity from typed input to a 1–24 dropdown, and used photo examples to show the required truck angles. Continue stayed disabled until the mandatory details or photographs were present.

Review brought everything back together before final submission, because submitted records could not be changed later. The extra check was deliberate: operators needed an opportunity to correct the record before committing it.

Not every problem could be solved by blocking progress. A missing required photo was clear; whether a dark or blurry image was still usable was less certain. We made the quality warning advisory, with Retake and Use this photo, so an incorrect warning would not stop a valid job.

The same distinction mattered for an unsecured outgoing load. The recording operator did not strap the load. A hard block could encourage a false Yes just to finish, so the app warned, asked for confirmation and recorded the actual unsecured condition.

Connectivity varied between warehouses. Waiting for a connection could leave operators tied to a task after the driver was ready to move on. With the developers, I defined separate states for work still in progress, a submitted record waiting to send, and a record the server had received.

Closing the app preserved an unfinished task as a draft, including its details, photos and current step. Final Submit moved the completed record into the Outbox. The app retried automatically when connectivity returned, but showed Logged only after the server confirmed receipt. Saving on the phone and reaching the warehouse were kept distinct.

On shared phones, submitted records kept the original operator's name, even if someone else signed in before the record was sent.

This recovery behaviour mattered in use. Operators at two warehouses reported records moving from the Outbox to Logged after the connection returned. Others reported reopening the app after rare freezes and continuing from the saved task. These reports informed follow-up conversations and build checks.

I documented validation, warnings, offline behaviour and recovery alongside the screens and prototypes. During build review, I checked the main tasks and recovery scenarios, recorded gaps and rechecked fixes with the developers. Before release, I focused on fixes that prevented missing evidence or lost work and helped operators resume interrupted tasks.

The rollout began at all four warehouses, with roughly half the operators using the app and half staying on paper for the first month. This kept daily work running while the product stabilised. I spoke with operators weekly and worked with developers on recurring problems as adoption expanded.

By month three, the warehouse manager confirmed that all new records were arriving through the app. Routine paper re-entry had stopped, leaving the desk operator to focus on exceptions and administration.