
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

Driver App - WIP

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
-
Delivery services help to reach customers who otherwise wouldn't have been.
-
Analytics provided by third party services help restaurants understand their operations better.
-
Delivery times have been optimized due to improved logistics.
-
Having delivery options combat seating limitations, as restaurants can continue to generate revenue, even with a full house.
Cons
-
Outsourcing deliveries means relinquishing control over brand and quality.
-
Restaurants typically shoulder the burden of delivery complaints, even though it's not their fault.
-
Some delivery services are too costly and restaurants simply cannot afford it.
Drivers' Point of View
Pros
-
The job is flexible and allows for a lot of freedom.
-
Tips and earnings are usually good.
-
The job is easy and there's little to no barrier to entry.
Cons
-
Earnings are inconsistent.
-
There's too much downtime between deliveries.
-
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.

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_1_0.png)
_UD_1_0_jp.png)
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

Concept 1

Concept 2

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

Concept 1

Concept 2

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

Concept 1

Concept 2

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

Concept 1

Concept 2

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:
-
Request driver
-
Monitor delivery
TASK 1: REQUEST DRIVER - WHAT WORKED

1
2
3

4
-
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.
-
Main tasks have dedicated tabs on the side for easy access.
-
Traffic alerts allow restaurants to manage expectations with customers, reducing complaints.
-
Customer information is easily editable.
TASK 1: REQUEST DRIVER - WHAT DIDN'T

1
2
3
-
Important inputs such as Payment Method should be more visible and accessible.
-
"Ready for Pickup" needs a "Ready now" option for restaurants that can prepare food almost instantly.
-
"Deliver Within" period needs an ASAP option and will likely be defaulted to the quickest time frame anyway.
TASK 1: REQUEST DRIVER - APPLIED CHANGES

1
2
1
-
Delivery requests are usually for same day; this option was moved towards the bottom since it won't be edited often.
-
"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
-
Visual indicator of delivery status and timestamps help restaurants pinpoint exact details.

1
TASK 2: MONITOR DELIVERY - WHAT DIDN'T
-
Quick filters aren't as practical as a search bar when it comes to looking for an order.
-
Map view isn't as critical as the ability to recall the driver from this screen.

1
2
TASK 2: MONITOR DELIVERY - APPLIED CHANGES

1
2
-
"Quick filters" were removed and replaced with standard search bar.
-
"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:
-
Accept an order
-
Pick up an order
-
Drop off order
-
Add a receipt for credit card orders
TASK 1: ACCEPT AN ORDER

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

1
2
-
The "Confirm Order" checklist allows drivers to keep track of orders and feeds into inputs for the restaurant and administrative dashboards.
-
The "Confirm Pick-up" CTA is deliberate to prevent accidental pick-up confirmations.
TASK 3: DROP OFF AN ORDER

1

2
-
The "Finish Delivery" CTA is deliberate to prevent false drop-off confirmations.
-
Confirmation gives drivers a sense of completion and prepares them for the next task.
TASK 4: ADD RECEIPT

1

2
3
-
The option to add a receipt now or later gives drivers some flexibility.
-
Customer name alone is not enough to identify the order. Drivers want to at least add phone number to help identify the order.
-
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

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