WMS - Release Trailer

The Home Depot
Enterprise UX | Supply Chain
2024

Replacing a multi-step, multi-user process with one seamless flow

Jump to Final Design

Overview

September - October 2024

The Release Trailer project drove process efficiency for Stocking Distribution Centers (12 buildings) by leveraging cross-app integration to give users a straightforward flow that shaved 30 seconds off each empty trailer removal.

Lead UX Designer
(Inbound Receiving Team)

My Role

YMS Product Team
WMS - Outbound Team
DC Operations (Inbound)
Yard Operations

Stakeholders

App Context

This project supported an Enterprise Warehouse Management System (WMS) used by internal associates in 90+ buildings across 3 distinct DC platforms (~9000 Monthly Active Users)

  • Expand supply chain capabilities to serve customers as quickly & cost-efficiently as possible

  • Reduce company costs incurred from using 3rd party WMS solutions

  • Deliver a best-in-class experience for distribution center associates

Product Goals

  • Software that tracks & optimizes the flow of goods within a warehouse

  • Features span receiving, inventory tracking, order fulfillment, and more warehouse operations

  • Supports directed tasking flows to guide users through daily operations

WMS Explained

Users were dealing with 2 fragmented systems — the WMS and the YMS*. Actions taken in one needed to be duplicated in the other to keep operations synchronized between departments.
(*Yard Management System; Tracks/manages trailer movements and yard storage)

Like a game of telephone, manual coordination eventually breaks down and suddenly you’ve lost a trailer. Or worse, one gets pulled off the dock unexpectedly while an unloader is still working inside it.

Not only is this a huge safety risk, but it causes delays and wastes labor on needless rework when the wires get crossed. It was basically a lose/lose process:

  • Doing it right: time consuming, needs multiple screens/apps to complete, highly reliant on word-of-mouth

  • Doing it wrong: time consuming, needs multiple screens/apps to resolve, highly reliant on word-of-mouth, risk of bodily harm or death

Problem

A multi-phase WMS/YMS integration to improve efficiency & system accuracy was underway. High-level tech design was defined and some phases already completed, so I worked with dependent stakeholders to confirm current state flows and extract project requirements from the larger strategy.

The Brief:

  • Create a systemic way for 1 WMS user to coordinate empty trailer removal from inbound doors

  • This action should only be completed after the inbound load is fully received

  • This action triggers a backend message to the YMS, which then auto-generates a trailer move

  • Design should be scalable to future phases for outbound trailer moves

This left a lot of open questions about the experience itself. Who would the primary user be? Should it be part of an existing flow, or standalone? Should it be desktop or mobile?

APPROACH

Flow diagram sketching out user and system touchpoints

When building features that will rewrite existing SOPs, you have to get involved with Operations to nail down people, process, and exceptions. I collaborated with Logistics Managers in Miro on the drafted E2E process map to clarify requirements:

✅ Stand-alone function needed due to conflicts with user permissions, scalability, and edge cases in the Receiving flow

✅ User access should be restricted to leadership roles only

✅ Mobile flow only, to be completed while physically at the dock door

I went straight to mid-fidelity in the first wireframes using established components & patterns from our mobile library. For the “Close Trailer” flow I designed as few steps as possible, with the main interactions being to scan the dock door & confirm it was the correct trailer before proceeding. I decided to include a warning message to highlight the changes for users who wouldn’t be used to their actions impacting the YMS.

Mid-Fidelity Wireframes

The prototype tested well with Operations teams at 4 different warehouses for straightforwardness, but users surfaced several process concerns:

❌ Terminology Confusion: They believed “Closing” a trailer = “Closing” the inbound load (an irreversible step), this misunderstanding made users hesitant to complete the flow

❌ Exceptions Handling: Limiting the feature to only trailers whose loads are fully received is too restrictive, teams need flexibility to remove empty trailers even if still working problem freight

❌ Safety Risk: The warning message felt too subtle, and leaders worried about unsafe shortcuts


We learned about past issues in a different DC platform where associates using the same type of feature were copy/pasting door barcodes from a desk rather than physically verifying empty trailers — leading to critical safety incidents. Our WMS was open to the same SOP-breaking loophole via browser based device transactions.

Extra guardrails were needed to build confidence with stakeholders and safeguard the process. Considering we planned to leave the manual options in place as an edge case workaround for operations, user adoption was also at risk — The feature needed to feel foolproof.

FRICTION

Renaming the flow from “Close Trailer” to “Release Trailer” was an easy vocab fix and my team supported architecture changes to decouple trailer removal from receiving status, allowing the flexibility needed to process exceptions without creating bottlenecks in the move queue.

The issue remaining was how to harden the guardrails:

  • Strengthen language in the warning to highlight safety consequences of the action?

  • Add a checklist step to require explicit safety confirmation?

  • Block the feature from appearing in the WMS’s browser device transactions?

The safest option would be blocking the feature entirely from the browser to enforce physical scanning, but I didn’t know if this was possible — It would be a first for the app.

While my PM & Lead Engineer researched the technical feasibility of Option A, I made research-backed refinements to the prototype and ran additional tests in case we needed Option B.

Stakeholders were satisfied with the proposed design; if we couldn’t hide the function on browser, the safety checklist would do to drive accountability with associates.

ITERATE

Wireframes for safety checklist in the flow

Solution

My team successfully found a way to block the Release Trailer function from the browser, so we scrapped the checklist from the final design in favor of simplicity. We shipped a standalone, permissions restricted device function requiring a dock door scan to initiate trailer release.

Completing the flow triggers cross-app messages to generate trailer moves — allowing for seamless inbound workflow without having to log into YMS manually or call the Transportation office. What used to be a multi-user process could now be completed swiftly by a single user.

Due to Enterprise priority shifts, there was a yearlong delay in deploying the feature — I had switched teams by then and wasn’t even directly involved in the pilot. Supply Chain operations evolve rapidly, so it’s easy for designs to grow stale over a long development cycle. Would the design hold up?

The pilot recorded time savings of 30 seconds per trailer compared to the legacy process. A busy DC can process 15-40 inbound loads per shift… scaled across 12 buildings x2 shifts, 30 seconds adds up quickly in the context of labor hours.

By focusing my approach in collaboration with Operations, I shipped a resilient feature that survived a year long gap between design and deployment.

Value Drivers:

  • Reduced manual steps diminishes manual coordination needs between departments

  • Streamlined 1-user process boosts operational efficiency

    • Pilot recorded 30 second reduction in task completion time compared to prior process

  • Physical verification requirements improve safety by reducing risk of accidental trailer pullouts

    • Potential Indicator: # safety incidents before vs. after feature rollout

Impact