top of page
Last Mile Delivery

Last-Mile Delivery

Challenge:  Customers want products faster, and expensive transportation costs with a lack of knowledge about a package's location affect the bottom line. Delivering packages to customers ourselves cuts costs and allows us to deliver to them on the same day of their order.

My role:  UX Researcher/Designer

The Team:  1 VP of Technology, 1 Director of Technology, 1 Product Manager, 1 UX Researcher/Designer, 1 Engineer, 1 Delivery Manager

The Timeline:  3.5 months (from team formation to first implementation)

Overview

The problem:  Delivery drivers need to be able to pick up packages from a fulfillment center and deliver them to a customer's door safely, accurately, and efficiently, and data should allow us to improve this process over time.

The solution:  Create a minimum viable product (MVP) application that supports delivering packages to a customer's door and tracks multiple pieces of data, including data to be used for accountability purposes. ​​

Business Focuses

  1. Safety

  2. Accurate

  3. Efficiency

Definitions

Some of these definitions were informed by current supply chain operations, and do not reflect definitions created

by this specific team and project. Definitions created specifically by this team are demarcated with an asterisk.

*Route:  A collection of stops.

*Stop:  A physical location where a driver parks temporarily to make one or more deliveries.

*Delivery:  A single door or address, which may contains one or multiple packages.

Package:  A single unit with one or multiple items.

Item:  A single UPC or SKU.​​​​

Order:  All items made at a specific time by a customer (which could ship together or separately on a route).

Design Process

Design Thinking - Nielsen Norman Group.png

My Role

Researched a competitor's software and noted the differences based on the type of delivery driver (e.g., employee or contractor). Analyzed the business requirements and determined the minimum requirements for the MVP. Received feedback from other designers and executive professionals to improve the MVP and suggest what feedback should be used as future directions for the application. 

Deliverables included:

  • Storyboards and Conceptual Ideation

  • Competitive Analysis

  • Industry Research Notes

  • Requirements Identification

  • User Flows and Prototype

Storyboards & Concept Ideation

Checking Packages In & Out.png
Generating A Route.png
Flow.png
Sketch 2.png
Sketch 5.png
Sketch 3.png
Sketch 4.png
Sketch 1.png

Competitive Analysis

Amazon Flex 2.png

Amazon Flex

Flexible driver application.

Key functions/features, UI elements, and UX aspects were analyzed to provide a better sense of current products' capabilities. 

Insights

  • Support for drivers while they are delivering, such as helping them find an address.

  • Different methods for viewing deliveries (e.g., list and map views).

  • Giving drivers quick access to "break" locations, such as supermarkets and convenience stores

  • Confirmation of the driver parking (safety) and controls for if the GPS isn't working.

  • Access to customer information needed upon delivery, such as a gate code

  • Displays where in the vehicle a package is located and the type of package

  • Scan package before delivering and issue avoidance (e.g., flashlight for scanning and manual entry)

  • Agreement to reading the notes from a customer

  • Confirmation when there are multiple packages to deliver per stop

  • Swiping to finish a delivery versus a button

Requirements

Minimum User Requirements

  1. Driver must choose a vehicle to assign themselves to in order to track who delivered a certain package (as well as promote accountability). 

  2. Driver must be able to view packages to know which packages are their responsibility (can be in list or map form).

  3. Driver must be able to route to a single stop at a time in order to deliver the packages for that address.

  4. Driver must be able to mark each package as delivered or undelivered. For undelivered packages, the driver must be able to indicate why it was not delivered in order to manage these undelivered packages correctly.  

Flows & Prototype

Vehicle Assignment

Design Decision

The license plate number was used as the initial vehicle identifier as this number would seldomly change. After, the driver is shown the vehicle they checked into (in case they made a mistake), and the driver is also shown the next action they should take.

Frame 337.png
Frame 360.png
Frame 339.png
Frame 340.png
Frame 341.png
Frame 341-1.png
Frame 342.png
Frame 342-1.png
Frame 342-2.png
Frame 342-3.png
Frame 343.png

Loading Packages Flow

Design Decision

Checkboxes were used instead of a scan to promote both the accuracy and efficiency focuses. Checkboxes were also faster to implement in order to release the MVP and learn quickly. ​

Frame 343.png

Design Decision

A modal was added after a user clicks "delivered" to support a branch in the flow, where a user can confirm they delivered the packages or not.

Frame 344.png
Frame 343-1.png
Frame 362-1.png
Frame 364.png
Frame 364-3.png
Frame 364-2.png

Successful Delivery Flow

Design Decision

Kicking the user into a third-party routing app was fastest to implement, so a modal was added after the user presses "back" as a protection for if that third-party app closed or crashed. ​

Frame 343-2.png

Unsuccessful Delivery Flows

Design Decision

The reasons for not being able to deliver packages were separated into (1) issues accessing a delivery address and (2) issues with a single package.

 

Therefore, the first was a branched flow after a user confirms they could not deliver the packages (top), and the second was moved to when each package needs scanned for the stop (bottom).

Frame 364-3.png
Frame 364-4.png
Frame 364-5.png
Frame 365.png
Frame 364-4.png
Frame 364-5.png
Frame 385.png
Frame 364-3.png
Frame 390.png
Frame 378.png

Manual Entry Flow

Design Decision

Adding a flow for the driver to manually enter a tracking number instead of scanning a package before delivering it solved a few issues. First, it allowed the package to still be delivered if the scanner was not working. Second, if there was an issue with the barcode on the package's label (e.g., when it's faded), the driver could still input the tracking number in order to bypass the scan and deliver the package.

Frame 365.png
Frame 376.png
Frame 377.png
Frame 377-1.png
Frame 378.png
Frame 364-2.png
Frame 343-2.png

Feedback

Future Directions 

 

From Learnings

  • Track reasons for not delivering a package (implemented)

  • Location where the package was left or person it was left with

 

From Feedback

  • Picture proof of delivery

  • Business unit for supporting drivers

  • Flow for helping the driver organize undelivered packages

bottom of page