top of page
aaa.jpg

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

flowicon.png

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.

load1.png

Load Example - Outgate from the Port

load2.png

Load Example - Empty Return

Challenges

Group2-2.png

Existing workflow to manage dry run is manual and complicated.

Group2-1.png

No streamlined and standard process, operators are using various hacks

Group2.png

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.

Monitoring Room

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.

allworkflow.png

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.

Group 248wrong.png

Illogical Load Example 1

Group 249wrong.png

Illogical Load Example 2

Stake Holder Feedback

Group.png

"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

Group-1.png
Group-2.png

"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

Groupicon.png

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. 

​

​

Data • Before & After

Enhancement

After

Before

Task

Saved 80%+ (clicks)
Saved 90%+ (time
)

Mark as Dry Run

10~26 (clicks)
2~4 (minutes)

2~4 (clicks)
5~30 (seconds)

Properly Recorded Dry Run

100%

0

100%

bottom of page