Ted McDonald

Interaction designer
Incoming intern at NASA JPL

  • My Role
  • UX Design
  • UI Design
  • Team
  • Ted McDonald
  • Olivia Michaels
  • Laura Dickinson
  • Eduardo Rojas
  • Project
  • Duration: 4 weeks
  • Class Project

Faster Navigation for Delivery Drivers

Food delivery is growing fast, with a projected 1,900% long term increase (Morgan Stanley). My team chose to focus on pizza delivery since it represents a majority of the delivery market. Tens of thousands of new pizza delivery drivers are being hired every year to keep up with increased demand.

My team saw an opportunity to make the pizza delivery process more efficient by improving upon current navigation apps and addressing driver pain points.


DeliverEase reimagines navigation for delivery drivers. We designed a high-fidelity concept to speed up the delivery process by offering a quick method for multiple address input, easy route management, and useful data displayed on the map.

What We Made

After researching, ideating, and testing, we produced high fidelity mockups to demonstrate multiple address input, route management, and map data during navigation and arrival.

Multiple Address Input

Our research showed that drivers often take multiple orders per trip. They want to get going as soon as possible, so address input needs to be quick and easy.

We focused on voice because it is a fast, simple, and reliable method for entering addresses. Familiarity with voice commands made it a great choice for our delivery drivers. Of course, there's still an option for inputting addresses manually.

If there are multiple addresses, drivers can create a destination queue by clicking “add to route.” If there's only one address, drivers can click the “directions” button and begin navigation.

Adding stops to route is quick and intuitive. "Add to Route" allows drivers to create route from multiple addresses.

Route Management

The interactions on the route overview panel are similar to a music playlist. If the user clicks an address, the map will highlight specific segments of the route. If a route needs to be manually re-ordered, the user can tap and hold to drag the address to a different spot.

By default, the route overview panel shows two addresses fully and a glimpse of the third. Our research showed that two deliveries per trip was most common. Drivers can swipe up to show more addresses.

Route overview panel allows the driver to see full route or segments, as well as manually edit.

Navigation & Arrival

Since Google Maps was familiar among delivery drivers, we chose to adopt similar patterns for the navigation screen.

On arrival, building outlines are overlaid with address numbers so that drivers can find their destination quickly. The driver can also add notes for difficult deliveries, in case they need to deliver to the same address in the future.

When the driver is ready, clicking on “next location” will start navigation to the next stop on the route. The process is seamless throughout the entire trip.

"Start Route" begins navigation. On arrival, driver is able to see building numbers and navigate to next stop.

How We Got There

Our design process involved user interviews, field observations, competitor analysis, ideation, storyboards, information architecture, wireflows, testable paper prototypes, and high fidelity mockups.

Field Observations

To better understand the pizza delivery process, we conducted in-person ride-alongs with a local pizza chain. After a number of rides certain patterns emerged; delivery drivers were under stress due to time constraints on their deliveries, they had difficulty finding house/building numbers due to various factors (weather, lighting, overgrowth, new development), they often delivered multiple orders in one trip, and they used Google Maps regularly.


We conducted interviews to back up our observations with more qualitative data. During our analysis, we noticed speed remained the common theme. Many of the pain points our delivery drivers expressed could be attributed to slowdowns in the delivery process.

Synthesis of interviews and research.


The bulk of driver income comes from delivery tips, which creates an incentive to delivery multiple orders per trip. About half of the drivers we observed and interviewed had been driving for a year or less. For these drivers, having to deal with multiple addresses in an unfamiliar area was a major source of frustration.

Existing navigation solutions did not offer intuitive methods to quickly input multiple addresses. Inexperienced drivers with multiple orders would input a single address after each delivery. This process wasted valuable time between stops. Worse, drivers would often take inefficient routes, since they were not sure which address they should navigate to first.


To speed up the delivery process, we had to design a quick method of input for multiple addresses, offer intuitive route management, and make it easy for the driver to find their drop off point.

Some sketched concepts including image OCR, multi-route management, and building number overlays.

One of our early concepts for quick address input was to avoid having the driver input anything. Rather, the pizza company could hook their dispatching software into a routing API that would automatically create routes based on order timing and destination parameters. This would have involved an entirely different approach to our project, as well as further research, so we set it aside when converging on ideas.

Wireframes, Prototypes, Testing

As narrowed our scope, storyboards helped us imagine various paths a user might take through our app. This was helpful in creating our initial wireframes and wireflows.

Early wireflows included image OCR imput method which we eventually dropped.

We tested user flows with paper prototypes. These were quick to produce and we could create or edit screens during testing sessions as needed. To evaluate user flows, a series of user tasks were created for testers to complete, ensuring that flows were quick, intuitive, and absent of any gaps. We also gathered feedback on annotated wireframes, making changes as needed.

Testing early user flows and annotated wireframes being critiqued.

We tested concepts involving manual, voice, and image OCR (text recognition) input methods. Three methods of input proved confusing during paper prototype testing, so we dropped image OCR for manual and voice input.

Just a few of our wireframes, shaped by testing and critiques.


I learned a lot during this project and enjoyed the working in the mapping and delivery domain. I wish my team had more time to create a digital prototype as testing results would have been much richer, but I am confident in the quality of our research.

I also wish there was more time to explore alternative concepts, such as integrating into existing delivery dispatching software. This would have introduced new challenges and constraints, but it's something that could be explored if this project is further developed.

My team had the chance to present to designers from Amazon and Blink UX. The feedback was positive, especially on the intuitiveness of the route overview screen and the appropriate scope of the project. Certain concepts led to great discussions, such as the feasibility of using a camera for image OCR (text recognition) after sunset, which is when many deliveries take place.

I will continue to follow news coming out of the delivery space. It’s growing fast and it’s exciting to see solutions that are innovative and successful.