To further chart the course for both our products, we created a series of design principles. These priniciples would ensure that we maintained a consistent balance of user needs:

Defining our Product

After user interviews, we had a lot to shift through. With two sets of users, we found ourselves trying to balance various user needs against each other to meet a common end goal: speedy deliveries. Deliveree had told us to place emphasis on restaurants, since restaurants were their direct clients, but we noticed trends that suggested that drivers and restaurants couldn't be wholely divorced. We saw that time is everything in the restaurant business. Food begins declining the second that it comes off the line; it gets colder, soggier, and loses quality the longer it is not eaten. For restaurants, what this really translated to was reputation. Restaurants maintain their business through the upkeep of their product and their reputation depends on the quality of the food that they their serve their customers. Drivers also cared about optimization. Wasted minutes on the road made the delivery process collectively more stressful. Every minute counts, so it’s best for all involved if food gets to its destination in a speedy manner.

We also knew that restaurants cared about accountability. As restaurants were handing their product off to a third party, they saw it as essential to have some sort of control over the product; they currently maintained this through driver familiarity. With further digging, we realized that it was not necessarily the familiarity that was important, but the underlying aspect of accountability. Familiar drivers were more easy to be held accountable, but with Deliveree expanding to include unfamiliar, crowdsourced drivers restaurants would be losing this familiar (and reasurring) touch.

With these two tenents defined, we found ourselves in a hierarchy of user needs. We needed an efficient, delivery-tracking application to serve restaurant needs but it's features would hinge on input from the driver application. We also needed to consider drivers' needs, in that they needed a streamlined way to manage multiple deliveries and best optimize delivery routes. It was going to be balancing act of playing the users, and our dual products, off of each other in order to create a successful user experience for both.

Considering these new insights, we revisted our initial problem statement to define the full opportunity that our product would be solving for:

While restaurants need a streamlined way to request drivers and monitor deliveries and drivers need a way to effectively manage and optimize deliveries, both users need a way to get on the same page surrounding the delivery process.

Exploring Solutions

For our initial designs, our concepts were built around features that we assumed would be the heaviest touch-points during the delivery ordering process for both drivers and restaurant owners. Prototyping meant thinking in flows and interactions between the two different devices, instead of just screens.

Drivers

For our driver users, we defined both flows and features. We wanted to know what information was necessary (and at what parts of the delivery process) and how to best display multiple deliveries. We started by addressing the issue of multiple deliveries. From our interviews I noticed that our driver users often had many deliveries at one time, so I defined how the two situations would look. Drivers were placed in one of two scenarios: 1. deliver several different orders from one restaurant, which reauired one pick-up with multiple stops; 2. deliver different orders from different restaurants, which meant drop-offs interchanged with pick-ups. To test both delivery scenarios, we built out two flows and tested with users.

We also needed to account for our restaurant's needs in relation to the driver product. To provide the accountability for restaurants, we built “checkpoints” in the form of CTAs that drivers had to "check-off" before they were allowed to continue on with their delivery. Drivers would be required to stop and "swipe" to indicate completion after picking up and dropping off each individual order so that restaurant could monitor delivery status. In order to ensure that drivers recorded these check-points, we strategically built so that the next piece of information in their delivery would be hidden until the check-point was recorded. This feature was the most necessary step in ensuring that restaurants received the necessary information to track-orders from their end.

We then honed in on individual features. We wanted to define the best visual layout and pertinent content for two key "crux" screens:

1. New order requests - what a driver would see at the beginning of a delivery, with the option to "accept" or "decline" the job.

2. The delivery "line-up" - the full number of stops (including order pick-up and drop-off) that a driver would be making to complete a delivery.

New Order Request:

Here drivers prefered a visual card. A more spaced out, visual representation was eaiser to scan than a heavily stacked text view. Since drivers would be referencing this information quickly, drivers needed information to be scannable, with pertinent content spaced out rather than stacked in heavy text.

Viewing Delivery "Line-up":

In terms of viewing a delivery line-up, drivers again preferred the more visual version (the map view). We learned that most drivers thought about deliveries in terms of a map, so the map view jived well with their existing mental model. With multiple orders to be managing, a map also allowed drivers to mentally plan their route and gave them a line of sight for their entire delivery.

Restaurants

For restaurants, we needed to refine content. Generally we wanted to test the process of requesting a driver and the process of monitoring orders. Specifically we wanted to define what information was most important (and where) and what information was necessary for tracking orders.

Requesting a driver

The driver request process would start with the process of entering customer information; users would either "search for" or "add a customer". For our concepts users were presented with a direct CTA to search by phone number, or the option to input customer information in directly. Users preferred the direct CTA "simple search" because it gave them a clear task. Busy hostesses and wait-staff wanted one, clear input feild where that they could quickly tap and access customer information.

Monitoring a delivery

For monitoring orders, users were presented with the option of a visual "timeline" that showed progressive order status, or a more text heavy list view. Users preferred the visual status bar because they could quickly glance at the screen and get order status through the visual check-points. Another feature that resonated with users was the map tracking feature. While ETA was a "must have", the map feature was concurrently necessary to verify that the ETA was accurrate: users trusted the map location more than ETA, but found ETA more necessary a first glance. The map could be hidden from view and used when a user wanted more details.

The final feature revolved around preferences for showing order status. We showed users two versions: categories (such as "picked-up", "en-route", etc.) of orders housed in left-side navigation or a "tabbed view" that housed orders under one screen, with tabs to toggle between their specific state. From users we learned the simpler the better. Users preferred to have a single side navigation (no tabs), but with "en-route" orders and "delivered" orders housed on separate tabs.

Final Design

After some adjustments, we presented a second round of prototypes to our users for usability testing. Taking the feedback from both our restaurant and driver users, we finalized our design.

Drivers

❮ ❯

Restaurants

❮ ❯

Moving Forward

Since this project left us with a large amount of data from both user sides, we had some forward looking recommendations for Deliveree as a business moving forward.

Further Recommendations

Like most projects, there were issues and insights raised in our usability testing that we were not able to tie up before handing off our deliverables. Moving forward, there were several considerations that we had for our product.

For our drivers we wanted to further consider:

1. "Re-call driver" flow: This concept was something was brought to our attention by our restaurant users during user testing. Sometimes the restaurant makes a mistake with an order or the customer calls to make an adjustment. From this, we added the option to "recall a driver" for restaurants, but the full flow needs to be considered from the driver's perspective.

2. Shift scheduling: Since Deliveree's expansion will involve crowdsourcing drivers, we foresaw that drivers would need a way to schedule shifts themselves. Deliveree's management would no longer would need to be directly involved. However this feature needs more research and testing.

3. Profile + account page: users expressed the want for a profile page that contained personal information and shift schedules. In case of a lost phone, we reasoned that having this content be PIN protected would be a reasonable means of security, but both the content of the account page and our PIN protection measure would need to be further tested with users.

For our restaurants we wanted to further consider:

1. Recalling a driver: Since this issue was brought up during our usability testing, we did incorporate it into our final design. However, we did not get a chance to test the flow with users and such it requires further testing.

2. Viewing uploaded reciept + confirming tip amount: While the "upload a reciept" feature was something that we encorportated into our driver product, we did not fully flesh out what this process would look like from the restaurant side. We envisioned that the flow would require flagging order reciepts for review, with the restaurant then tasked with confirming the driver's tip amount virtually. Unfortunately we did not have time to build out this flow, but still see it as means to further increasing efficiency for both parties.

3. Searching for customers: as opposed to our "filter orders" feature, users told us it would be quicker (and more intuiative) to search for customers directly. While we encorporated this feature into our final design, it still needs further testing.

Next Steps

At the end of our three weeks we were able to present our designs to our clients and hear their thoughts. Collectively this project was a huge success for us and Deliveree. We started with a existing product that left restaurants in the dark and drivers using a complicated and archaic text-messaging system; we ended with a full set of flows for both users that not only streamlined the delivery process, but also didn't leave anyone in the dark.

Two different UI concepts done by our UI team. Right screens by Melivin Latham; left screens by Sabrina Gagliano.

Along with our research findings, we were also able to pass our annotated wireframes over to a UI team. It was incredibly insightful to work with designers who were looking at our product for the first time. I had to explain the reasoning behind my designs to a fresh audience, which was a challenge in recongizing areas that we had left holes and defending our final decisions. Our final designs (with UI polish) are currently set to go live in a few months.

Final Thoughts

As we ended this project, there were many valuable UX intricacies that I felt like I learned. Chief among these was accounting and accommodating different user bases simulataneously. While building for two user bases was something that I had had previous experience doing, this project was different in the sense that our user types (and eventual products) were so tightly intertwined. Since both of our products hinged on direct actions that must be taken by the other user, the product’s success was determined by trying to both understanding and balance the needs of different users, but also understanding that there was one goal that must be collectively achieved by both products. Since our clients were definitely most interesting in the restaurant facing application (the product for their current/potential customers) we had to stick up for the needs of drivers. Since user experience encompasses the needs of all users, it was a balancing act of accounting for both sets of users while maintaining a cohesive, end plan.

This project taught me the process of building and thinking strategically in terms of two different products and two different flows. Since we needed to explicitly build to give restaurant users the status of deliveries, we had to really strategize on how to fold those necessary features into the driver application. Through this I also learned how important it is to identify and account for the most extreme/fringe use cases (such as a driver managing 6 deliveries at one time).

Overall, this project was incredibly challenging and insanely fun. I learned alot about the restaurant business and was able to further build up my UX skills (and learn a few more along the way). In the end we created a solid product that one user said was "so easy my grandpa could use it." Mission accomplished.

Special thanks...

Special thanks to my teammates Lena Tran and Jeanette Wu. Cheers to three weeks of fast-food filled screen flows and eventful usability tests in crowded restaurants booths #blessedforolven