
Container Dry Run Management
In this UX design venture, I delved into the intricacies of dry run management within the dry run industry, recognizing the pivotal role it plays in optimizing logistics operations. Focused on alleviating challenges associated with dry run occurrence, I designed multiple iterations to reduce the possible steps for a user to mark a trip as a dry run. With this approach, our internal operations are able to save an average 24 clicks (80% gain) or 4 minutes (90% gain) when a dry run occurs.
The Team
Project Manager
Product Designer
Engineering Team
Operations/Carrier Team
My Role
Lead user research and product discovery
Defined the problems and goals
Analyzed the existing business workflow
Designed an improved/automated user experience
Aligned with the project manager & stakeholders on the project
Worked with the engineering team through the development cycle
Time Spent
3 months
Year of 2020
Product Goal
Build a container dry run management product in NEXT TMS (Transportation Management System) to enable easy and accurate tracking
Background Knowledge
The driver starts by driving his/her own tractor to the port and hook a chassis so that he/she can mount the container on it. After the container (with the chassis) is delivered and emptied by the customer, driver picks up the container and return it to the port.
Container Life Cycle
What's a Dry Run?
The driver is expected to complete all the instructions[1] in a load[2]. Due to various reasons, a driver might not be able to complete certain instructions. In those cases, a dry run will need to be logged and all following instructions need to be adjusted accordingly to ensure proper delivery.
[1] : Instruction is the combination of action, equipment, location and other info (not all shown in the visual).
[2] : Load is the smallest unit of a job that should be completed by a single driver at one time.

Load Example - Outgate from the Port

Load Example - Empty Return
Challenges
Existing workflow to manage dry run is manual and complicated.
No streamlined and standard process, operators are using various hacks
Results in container track & trace inaccuracy and exceptions.
Design Process
Know the User - Operator
An operator's job is to work with the carriers to ensure the container has accurate track and trace records, as well as logging any exceptions in the system.

Current Flow (SOP) Research
I worked with the operators via shadowing & interviews to fully understand how they are managing the dry run currently. I then distilled the insights and complied all the current workflows so that we don't miss any use cases and user needs.

Initial Design Direction
After gone through the current workflow for all the load types[3] , we learned that what's missing for the users is the way to edit the instruction.
​
[3] The sequence of different actions determines the load type.
Load Type: Hook-Mount-Drop
Failed Action: Mount
Users Need to: Edit Equipment
Load Type: Hook-Mount-Live Unload-Dismount
Failed Action: Live Unload
Users Need to: Edit Equipment&Remove Instruction








Concerns
Allowing user to freely edit the action/equipment potentially create loads that don't make sense. It may cause a lot of downstream issues: such as populating illogical to the marketplace, completing loads with dirty data, failure to bill the customer because of the inaccuracy of container tracking, etc.

Illogical Load Example 1

Illogical Load Example 2
Stake Holder Feedback

"When looking at a load, I only check if the set of actions makes sense or not, if one of the equipment goes off, it will be difficult for me to find out."
----- Operator (Direct User)
"We want to reduce human error but also maintain the team's efficiency at the same time, therefore, the feature shouldn't require us for doing multiple check for every single load."
----- Director of Operation


"We use all the data in the system to track our business health, if any data comes in incorrectly, it will be extremely difficult for us to rule out those dirty data."
----- Analyst
"Allowing editing instructions is conflict with our existing Load Type concept, Load Type helps us to make sure the action/equipment within a load is accurate."
----- Engineer Team
Iteration
After collecting the feedback from different stakeholders, I decided to turn the design direction into a more automated fashion which requires less human thinking and interactions. This would also reduce potential human errors. The bonus part was that the engineering team could use less time to develop and maintain a good part of the existing code structure.




Final Delivery
Old Design - Step 1 :
The old mark as dry run process requires a lot of clicks
Old Design - Step 2 :
After the user marked the dry run load as completed, a follow -up load needs to be created because the container was not able to dropped at the right location and user needs to schedule another appointment to deliver the load. In the old design, this process is very manual and time consuming.
Old Design - Not able to see the load has been marked as dry run
After the user marked the dry run load as completed, there's no visual clue indicates that the load is a dry run, the only way to find out is to go to the event tab and find the journal entry that was created when the user marked the dry run load.
New Design
With this new design, instead of manually adjusting instructions, users only need to specify the failed instruction. The system will not only update the load's action & equipment automatically, it will also adjust the corresponding loads to reflect the accurate tracking instructions.
​
It also shows to the user a clear visual indicator that a dry run has happened, and which instruction is failed due to that. This allows anyone who's not familiar with the particular shipment to know the true story of the container journey. In addition, the user will be able to know what actions needs to be taken based on the information given.
​
In addition to the improvement of user interaction and system data integrity (and its benefits), we are also able to capture the dry run reasons. This allows the team to analyze and reduce the occurrence of dry run fundamentally.
​
​


