Summary

Problem

Delivery drivers must pick up packages from a fulfillment center and deliver them to a customer safely, accurately, and efficiently. Data tracking should be used to improve this process over time.

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.

Outcome

Successful delivery of 8 packages and new business unit on launch day. However, with such a complex problem, other directions could have yielded better results over time.

Problem

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).

Process

My Contribution

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 determine future directions for the application based on this feedback.

Competitive Analysis

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

Amazon Flex
Multi-functional Driver Application.

• 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
• ​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
• Scan package before delivering and issue avoidance (e.g., flashlight for scanning and manual entry)

The main insight used in design decisions for the MVP was the bolded one, which ensured drivers could confirm packages they were delivering without a barcode. Additionally, inspiration of avoiding issues was used when implementing data tracking. 

Concept Ideation

Early concepts for route method

Storyboard for routing

Storyboard for package tracking

Early concepts for delivery zones and package tracking

Initial user flow for MVP, including vehicle assignment, navigation, and delivery confirmation

Requirements

Learning from the research, ideation, and business requirements, the following user requirements were established for the MVP.

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 all 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.

Solution

Design Decisions

Vehicle Assignment Flow

I advocated for the license plate number to be used for vehicle assignment because this number would seldomly change and require less administrative setup. Once the driver is assigned to the vehicle, the driver is shown their assigned vehicle (in case they made a mistake) and the next action they should take.

Vehicle assignment for accountability data and eliminating admin oversight

---

Flow for loading packages using checkboxes to promote efficiency over accuracy

Loading Packages Flow

​For loading packages, I preferred packages to be scanned, but after conversations with the team, we decided an approach that promotes both the accuracy and efficiency focuses was a better solution. Therefore, I used checkboxes, which also allowed different driver personas to perform the same task. Additionally, checkboxes were faster to implement in order to release the MVP and learn quickly. ​

---

Successful Delivery Flow

Because the team chose to launch into a third-party routing app for the fastest implementation, I created a modal after the user presses the Android "back". This was added as a protection for if the third-party app closed or crashed. ​

​I also added a modal after a user clicks "delivered" to support a branch in the flow to track data, where a user could confirm if they delivered the packages or not (see Unsuccessful Delivery Flow).

Modals for confirming arrival at a stop and packages as delivered

---

A branch in the flow for data tracking reasons the driver could not access an address

---

A branch in the flow for data tracking reasons the driver could not deliver the package

Unsuccessful Delivery Flow

After walking through the driver's delivery process, I discovered the reasons for not being able to deliver packages happened in two separate parts of the flow, meaning there were two categories of reasons packages might be undeliverable:  (1) issues accessing a delivery address and (2) issues with a single package.

Therefore, I modified the flow to have two steps where the driver could indicate the reasoning. 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).

---

Manual Entry Flow

​The competitive analysis revealed possible issues with scanning packages before delivering them, so I included a manual entry functionality, which solved a couple issues. 
First, the package could still be delivered if the scanner was not working.
Second, the package could still be delivered by manually entering the tracking number if there was an issue with the barcode on the package's label (e.g., when it's faded).

Functionality for manually entering a tracking number versus scanning the package

Outcomes

1

Successful delivery of 8 packages on launch day.

2

Data tracking of which driver was delivering that day.

3

Launch of new business unit:  Spreetail delivery.

Future Directions

Learnings

• ​Track reasons for not delivering a package (later implemented)
• ​Indicate where / with whom the package was left
  
• Ensure vehicle assignments can be altered for the next day's driver

Feedback

• Require driver to take a photo of the package for proof of delivery
  
• Develop a support unit in the business (and app) for drivers
  
• Add flow for organizing undelivered packages

Reflection

While the launch included successful delivery of 8 packages, there was an opportunity for us to use or purchase third-party software to accomplish this goal. There are several companies that have already solved this complex problem, nearly to the point of mastery, resulting in the custom-built software being quite rudimentary. 

Back to Projects