Re-Visiting GrubHub’s Usability

Many college students, including myself, find food delivery services life-saving. We use GrubHub as a convenience to save time, cherish our favorite meals together, or not have to worry about our next meal. Yet, what are some of the issues GrubHub consumers find annoying to deal with? How can we better the overall experience of food delivery?

After conducting user interviews, I came up with two main areas of user pain points, as demonstrated:

1. Communication: there are many gaps between users and drivers.
2. Group Orders: it’s hard to facilitate group orders with the current model.

Understanding Why GrubHub Lacks Communication:

“A lot of the times I’m using one of these services is because I’m too hungry or tired or too late to go out. It would be a point where I’m basically starving. I’m anxious whether the order is even going to get here… also when is it going to get here.”

“Me as a consumer I have no way to know what’s going on.”

GrubHub establishes two types of communication: direct and indirect. As for the direct, users have access to in-app instant messages with drivers. Unfortunately, information exchange is limited by virtue of drivers not being able to use their phones while driving. As for the indirect, users have access to drivers’ real-time location, which covers for when drivers are not actively on their phones. However, real-time location doesn’t tell much. The driver could be getting closer then farther away from the destination and for all we know, we cannot infer anything.

1. direct communication is targeting right after ordering (starting) and drop-off (ending) related communication.
2. indirect communication is targeting while-delivering (throughout) related communication.

With that paradigm preserved, it becomes easier to brainstorm various efficient solutions, falling within either category, to promote consumer-driver communication.

1—Driver’s Path (indirect communication)

“[taking on multiple orders] probably makes it more worth their time from their end… but as a consumer, I feel like it stretches my wait time beyond what I’d like to wait for my food.”

Consumer-Based Flow

• No major changes introduced: solution is an extension of Real-Time Map feature.
• Currently: map doesn’t show driver’s path (or stop locations, if multiple deliveries).
• Effects: A non-complicated feature like this could have major effects on consumers stress levels waiting, while also make it transparent what are the next trips/ deliveries for the driver before reaching the final destination of the consumer.
• Feature already seen in market: DoorDash, for example.

2—Drop-Off Picture (direct communication)

With drop-off picture, I’d like to introduce two possible variations of application that would yield the same result yet one is more user-friendly than the other.

Consumer-Dependent Version Flow

Consumer-Dependent: Once driver drops off food, they usually take a picture of the food and send it (through SMS) to consumers as a way of order verification. What if drivers send the picture to consumers via GrubHub instead and let consumers rate the location of drop off (pass or fail). Next order, the new driver gets the earlier “pass” picture as an up-to-date instruction left by the previous driver as to where to leave food.

• Solution substantially relies on the already-existent incentive for drivers to shoot a picture of situated food post delivery. In other words, I’m not introducing, or eliminating thereof, any incentive factor.
• Drop-off pictures are passed-in through SMS, an external platform. I propose the native integration of this feature into GrubHub, which brings forth positive effects and opportunities we’re after.
• One positive outcome is enhanced accuracy for drivers drop off locations (consumer benefit). Another is cleared confusion for drivers drop off locations (drivers benefit)
• Not no mention faster, safer, and more efficient delivery, attractive to both consumers and drivers, while also providing a lucrative amount of data collection for GrubHub to use.

However, the implementation of this gets counter-intuitive and dense really easily. Let’s shift this to be Driver-Dependent.

Consumer-Dependent Version Flow

The Driver-Dependent implementation of this would require the consumer to intervene only and only once in the entirety of the process; that is when consumers upload a one-time picture of their desired drop-off location.

With that in mind, it has all the benefits and is more implementable and rather intuitive than the former version, yet it eliminates the advantage of GrubHub acquiring a pool of data on how accurate their deliveries are. Good news is: this could be a different feedback-dependent feature for another discussion.

Understanding Why GrubHub Inhibits Group Orders

In group settings, [GrubHub] becomes a little bit more of a hassle.”

Many consumers found GrubHub hard to deal with in social contexts for:

1. There’s no clear stream line of procedures to initiate group orders.
2. Due to the current app structure, the responsibility of a failed delivery lies entirely upon the one initiating the group order.

Shareable Member ID

Solution is based on assigning an individualized Member ID that can be shared and used to facilitate group orders. In other words, it’s like splitting the bill with your friends, albeit online.

• No major app changes required: a Member ID could be tagged in the profile/ account page.
• User-friendly and intuitive solution.
• Effect: Humanizes the app and makes it more social.

Conclusion

With the current status quo of the food delivery industry, it’s an uneasy task to expect at which direction the market is pushing GrubHub or other similar services in terms of convenience, features, and quality of service. Not to mention how limited this industry is in terms of funding and resources. I hope that the above discussion have provided even the slimmest of light as to where possibly GrubHub could be heading.