top of page
Simple Calligraphy Monogram Nail Logo.png
Deliveree_Devices.png
DELIVEREE

Designing an order tracking platform for restaurant staff and delivery drivers. 

My Role

UX Designer

Main Goal

Understand and clearly communicate mission-critical content.

PROJECT OVERVIEW
ABOUT THE CLIENT

Deliveree is an on-demand, third party courier service that supplies restaurants with drivers, effectively eliminating the need for an in-house fleet of delivery drivers. Restaurants use an MVP tablet application to request drivers, who are then manually dispatched by Deliveree. 

THE CHALLENGE

Redesign the restaurant side application and create the companion driver side app. 

TEAM

3 UX Designers
1 Creative Director

TIMEFRAME

3 weeks 

SOFTWARE

Sketch
InVision

DELIVERABLES
  • Domain research 

  • Competitive analysis

  • Wireframes

  • Click-through prototype

  • User journey maps 

  • Personas

  • ​Test plan

  • Usability test results 

THE PROBLEM

Restaurants need a way to monitor delivery details without unnecessary communications through Deliveree. Drivers need a way to optimize deliveries and minimize unnecessary communications in order to maximize time and earning potential.

The biggest pain point for Deliveree is having to manually monitor requests and dispatch drivers. Once drivers are dispatched, any communications from the restaurants to drivers and vice versa are funneled through Deliveree, creating a bottleneck of information.

Realizing the need for automation and streamlined communication, the client came to us with the intent of improving their restaurant app and developing a driver side mobile app. The need was urgent as they were in the midst of expansion and wanted to be better equipped to handle a larger volume of deliveries. 
 

We were provided with screens of the existing restaurant app and WIP mockups of the driver side app. 

Restaurant App - MVP 1
Deliveree MVP.webp
Driver App - WIP
Driver Side WIP.webp
THE PROCESS

We ran a 3-week sprint, dedicating each week to a part of the design process. 

  • ​​Week 1: Research & Definition

First, we familiarized ourselves with the industry and how Deliveree fits into the market. We also used this time to identify opportunities and build empathy with users. 
 

  • Week 2: Ideate & Design

Next, we ideated various concepts and leveraged those to quickly validate assumptions and determine a direction for the final design. 
 

  • ​​Week 3: Prototype & Test  

Lastly, we built a click-through prototype with the final design to test for any glaring usability issues.

RESEARCH & DEFINITION

We leveraged domain research, competitive analysis, and user interviews to get a full understanding of the problem.

Our goal was to gather background information and insights that we could use to evaluate our design decisions later in the process. We started by examining the industry, the competition, and the users. 

UNDERSTANDING THE INDUSTRY

Through our research, we were able to identify common perceptions of third-party delivery services from both the restaurant and driver perspectives.

Restaurants' Point of View 

Pros

  1. Delivery services help to reach customers who otherwise wouldn't have been. 

  2. Analytics provided by third party services help restaurants understand their operations better. 

  3. Delivery times have been optimized due to improved logistics. 

  4. Having delivery options combat seating limitations, as restaurants can continue to generate revenue, even with a full house. 

Cons

  1. Outsourcing deliveries means relinquishing control over brand and quality. 

  2. Restaurants typically shoulder the burden of delivery complaints, even though it's not their fault. 

  3. Some delivery services are too costly and restaurants simply cannot afford it. 

Drivers' Point of View 

Pros

  1. The job is flexible and allows for a lot of freedom.

  2. Tips and earnings are usually good. 

  3. The job is easy and there's little to no barrier to entry.

Cons

  1. Earnings are inconsistent. 

  2. There's too much downtime between deliveries. 

  3. Uncontrollable factors such as traffic, parking, weather, construction, etc.

UNDERSTANDING THE COMPETITION

We did a market analysis of Deliveree and similar services in the Chicago area and concluded that Deliveree’s differentiation is in its unique business model of not offering just a service, but a partnership with restaurants. They pride themselves in being an extension of the restaurant by upholding quality and reputation with each delivery. Each driver is vetted individually and undergo training in order to understand the delivery routes and each restaurant’s operations. 

 

We compared the biggest players in the space and identified UberRush as the most direct competitor. That said, they crowdsource their drivers, which means losing control over the quality of customer service. This gives Deliveree a competitive edge.

Competitive Analysis.webp
UNDERSTANDING THE USERS

We met with a few of the partner restaurants' staff and Deliveree's drivers to get an understanding of the major pain points in the entire delivery process. We also asked drivers to provide initial feedback regarding the WIP driver app mockups that the client provided.

RESTAURANT INSIGHT #1

ACCOUNTABILITY IS KEY.

They want to identify which drivers are delivering which orders so they can get in touch in case the customer cancels the order or there's a forgotten item. Currently, they have to contact Deliveree to obtain that information.

RESTAURANT INSIGHT #2

EVERY SECOND COUNTS

As soon as food leaves the kitchen, the quality declines. Some food also don’t transport well. Staff wants to ensure that drivers are ready to go as soon as the food is packed up.

​

RESTAURANT INSIGHT #3

DETAIL IS KING.

While the tool provides high level important information, it's missing a level of detail that would help restaurant staff address customer concerns without having to call Deliveree to find out. 

​

DRIVER INSIGHT #1

EVERY SECOND COUNTS. 

More deliveries = more tips. Drivers want to arrive at the restaurant just in time to pick up food and to optimize their routes for subsequent pick-up and drop-off locations. The biggest waste of time right now is returning signed receipts to restaurants if customers choose to pay by credit card.

DRIVER INSIGHT #2

DON'T REINVENT THE WHEEL.

When asked about their opinions of the WIP mockups of the driver side app, most referenced their experiences working for similar services. We also learned that many of these drivers did not speak English fluently, but were able to learn quickly due to similar functionality and patterns across apps.    

DRIVER INSIGHT #3

INFORMATION IS SCATTERED.

Drivers balance several key pieces of information via a string of texts or phone calls. There's no centralized location to reference during or post-delivery. They're also interested in tracking their earnings and deliveries, mostly out of personal interest, but also as protection against false complaints.

MEET THE USERS

We created personas to embody and highlight our users' goals and frustrations. This helped us make our design decisions throughout the process. We were able to think through features and suss out what would truly be helpful to Dylan and Hallie. 

UD_Driver Persona (Dylan)_UD_1_0.webp
UD_Restaurant Persona (Hallie)_UD_1_0_jp
GUIDING PRINCIPLES

Before diving into the design, we defined 3 guiding principles to serve as the backbone of our design for both audiences. These incorporate Deliveree’s values as a company and our understanding of what users need.

  • Details at your fingertips

There's not a second to lose in the food delivery business. Both restaurants and drivers need quick access to the most important details to ensure smooth operations. 

  • There when you need it 

Deliveree prides itself on being an extension of their restaurant partners. They're always available for questions and even in the event of an internet outage, they're still committed to fulfilling orders by phone. The digital platform should exude the same kind of support and customer service. 

  • Mission accomplished

Customer needs are first and foremost. Every element of this design should help both restaurants and drivers best serve the customer. 

IDEATE & DESIGN

We explored concepts for both restaurants and drivers and used them to validate assumptions for the final design. 

We visited restaurant staff at their locations and tested our concept prototypes on tablet devices to emulate their current experience with Deliveree. From these sessions, we were able to further parse out features relating to time management, glanceability, and access that would be useful to them. We also received insights regarding main tasks and the best way to search/input user information.

TASK: REQUEST DRIVER
Restaurant_Request_3.webp

Concept 1 

Restaurant_Request_1.webp

Concept 2 

Restaurant_Request_2.webp

Concept 3

I want to start by searching for a phone number, that's it. The next page can show me more info.

- Restaurant Manager

TASK: MANAGE ORDERS
Restaurant_ManageOrders_2.webp

Concept 1 

Restaurant_ManageOrders_3.webp

Concept 2 

Restaurant_ManageOrders_1.webp

Concept 3

Oh this is really nice. Having pickup and delivery time helps the restaurant and the drivers. Sometimes the drivers have to wait for the order and I don’t want to waste their time.

- Restaurant Manager

The biggest challenge on the driver side was balancing necessary information that would feed into the restaurant platform, without overwhelming the drivers during their deliveries. We learned that they want easy access to relevant information, an idea of what's coming next, and contextual details. 

TASK: ACCEPT DELIVERY
Driver_PickUp_1.webp

Concept 1 

Driver_Pickup_2.webp

Concept 2

Driver_Pickup_3.webp

Concept 3

I think you need the time: when it needs to be picked up & when it needs to be delivered. Every time the delivery pops up, I want to see that so I can manage my time. It’s really important, you don’t want to lose customers.

- Deliveree Driver

TASK: MANAGE ROUTE
Driver_EnRoute_3.webp

Concept 1 

Driver_EnRoute_2.webp

Concept 2 

Driver_EnRoute_1.webp

Concept 3

I know all of the streets and shortcuts but I still want to see it on a map so I have a general sense of where I need to go. I can mentally plan.

- Deliveree Driver

PROTOTYPE & TEST

Leveraging our findings from concept testing, we determined a direction for the final design and tested it for usability. 

We found that users on both sides favored any element of the design that allowed them to plan ahead and find information when needed. With those learnings in mind, we converged the concepts into one final design for usability testing. 

We asked restaurant staff to evaluate the design based on 2 key tasks within this application: 

  1. Request driver 

  2. Monitor delivery 

TASK 1: REQUEST DRIVER - WHAT WORKED
Final_Restaurant_RequestDriver_1.webp

1

2

3

Final_Restaurant_RequestDriver_2.webp

4

  1. Restaurant staff prefer to initiate a delivery request by searching for a phone number. There's a high chance of pulling up the right customer information since people don't change phone numbers often.

  2. Main tasks have dedicated tabs on the side for easy access. 

  3. Traffic alerts allow restaurants to manage expectations with customers, reducing complaints.  

  4. Customer information is easily editable. 

TASK 1: REQUEST DRIVER - WHAT DIDN'T
Final_Restaurant_RequestDriver_2.webp

1

2

3

  1. Important inputs such as Payment Method should be more visible and accessible. 

  2. "Ready for Pickup" needs a "Ready now" option for restaurants that can prepare food almost instantly. 

  3. "Deliver Within" period needs an ASAP option and will likely be defaulted to the quickest time frame anyway.

TASK 1: REQUEST DRIVER - APPLIED CHANGES
Final_Request Driver - Credit Order.webp

1

2

1

  1. Delivery requests are usually for same day; this option was moved towards the bottom since it won't be edited often. 

  2. "Payment Method" and delivery times are critical and more likely to be variable information; they were moved towards the top and were simplified. 

TASK 2: MONITOR DELIVERY - WHAT WORKED
  1. Visual indicator of delivery status and timestamps help restaurants pinpoint exact details. 

Final_Restaurant_ManageOrder.webp

1

TASK 2: MONITOR DELIVERY - WHAT DIDN'T
  1. Quick filters aren't as practical as a search bar when it comes to looking for an order. 

  2. Map view isn't as critical as the ability to recall the driver from this screen.

Final_Restaurant_ManageOrder.webp

1

2

TASK 2: MONITOR DELIVERY - APPLIED CHANGES
FInal_In Progress Orders.webp

1

2

  1. "Quick filters" were removed and replaced with standard search bar.

  2. "Map" function was replaced with "Recall driver" function. 

I like the progressiveness of this timeline and how clear the breakout of the steps is. This is awesome.

- Restaurant Manager

Similarly, we asked drivers to evaluate the design based on key tasks: 

  1. Accept an order

  2. Pick up an order 

  3. Drop off order

  4. Add a receipt for credit card orders

TASK 1: ACCEPT AN ORDER
Final_Driver_PickUp_1.webp

1

  1. Since drivers have to pay for cash orders with their own money upfront, they like the cash indicator so they know if they have enough cash to be able to accept the order or not.

TASK 2: PICK UP AN ORDER
Final_Driver_PickUp_2.webp

1

2

  1. The "Confirm Order" checklist allows drivers to keep track of orders and feeds into inputs for the restaurant and administrative dashboards.
     

  2. The "Confirm Pick-up" CTA is deliberate to prevent accidental pick-up confirmations. 

TASK 3: DROP OFF AN ORDER
Final_Driver_DropOff_1.webp

1

Final_Driver_DropOff_2.webp

2

  1. The "Finish Delivery" CTA is deliberate to prevent false drop-off confirmations. 

  2. Confirmation gives drivers a sense of completion and prepares them for the next task. 

TASK 4: ADD RECEIPT
Final_Driver_Receipt_1.webp

1

Final_Driver_Receipt_2.webp

2

3

  1. The option to add a receipt now or later gives drivers some flexibility. 

  2. Customer name alone is not enough to identify the order. Drivers want to at least add phone number to help identify the order. 

  3. There's not a case where multiple receipts are required, so this function is not needed. 

FUTURE CONSIDERATIONS

While we were able to get learnings around the core functions, there are still outstanding features to consider for the driver app and the administrative dashboard. 

For the driver side app, we need to optimize the Add Receipt flow and further pressure test the core functions of picking up and dropping off an order. The notion of scheduling shifts or tracking earnings are things that driver would find useful and can be explored in future iterations.

It would also be beneficial to think about how the administrative dashboard would look and what kind if inputs are required to make that an effective tool for Deliveree to use. 

LEARNINGS

This project taught me the importance of designing for context and multiple sets of users.

The core of this product needed to facilitate communication between two primary types of users in their mission to fulfill deliveries. Understanding what each side needed from each other in order to complete this task greatly influenced the design of the application. 

Designing for context was crucial in this project. Getting a glimpse into the chaos of a restaurant setting and the nuances of delivery driving helped us prioritize information and serve up the right amount of data at just the right time; enough for each party to successfully do their part. Since time is of the essence, we wanted to ensure that users were able to make quick choices or obtain the information they needed without too much cognitive overload. 

This also made us think more critically about where we could help users prevent errors and where we could introduce a little bit of friction to enforce the behavior of taking deliberate actions. 

OTHER PROJECTS
Disco_QuickLink.png
DISCOVER

Sample work for the Discover site and app.

 

The Right Hook Quick Link.png
THE RIGHT HOOK

A web assessment for bra measurements and online orders.

Meals with Mandy Quick Link.png
MEALS WITH MANDY

A recipe finder skill that allows users to search and make recipes with a voice assistant.

CONTACT ME

Lena Tran

LEAD PRODUCT DESIGNER

​

Phone:

773-733-2211

 

Email:

lenatran.813@gmail.com 

​

  • Black LinkedIn Icon

Thank you! I'll be in touch soon!

© 2020 By Lena Tran. Proudly created with Wix.com

bottom of page