ezCater · B2B logistics · Jun – Aug 2026
Easing workflow friction for restaurant delivery drivers
Independently led, end-to-end research on how restaurant partners who deliver their own catering orders use ezCater’s delivery app.
- Problem
- Delivery problems were a leading source of negative partner sentiment, and the team didn’t know where self-delivery friction came from.
- My role
- UX research intern; owned the study end to end in 10 weeks, from brief to leadership readout.
- Methods
- Competitive analysis of 4 platforms; 8 remote semi-structured interviews; synthesis in Dovetail.
- Outcome
- Prioritized opportunity areas delivered to PMs, designers, engineers, and leadership.
Context
Self-delivery lets restaurant partners own the full customer experience on high-stakes catering orders, often within a narrow lunch window. The delivery app asks drivers to report progress along the way, and that data feeds how ezCater measures reliability. If the app doesn’t fit how partners actually deliver, both the partner experience and the reliability data suffer.
Approach
I ran the study in two phases. A competitive analysis showed what drivers are used to in other apps, and stakeholder reactions to it sharpened the interview guide. I then recruited partners through Rally and ran remote interviews, following each conversation where it went while still covering the team’s priority questions.
Study plan
- Research briefApproved by stakeholders
Defined the goal: understand the self-delivery driver’s experience and find opportunities for the delivery app.
- Competitive analysisUber Eats, DoorDash, Expedite, Instacart
Reviewed partner help articles, tutorials, and media to compare workflow milestones, tracking, multi-stop support, communication, and accessibility.Why: partners form expectations from the other apps they use.
- Readout and updated briefSecond approval
Shared the competitive analysis, then refined the interview focus based on what the team was most interested in.
- RecruitingRally screener
Screened, scheduled, and compensated 8 partners, from independent restaurants to multi-location franchisees.
- InterviewsRemote, 30–45 minutes each
Semi-structured 1:1 sessions on areas of friction, delivery windows, tracking milestones, customer communication, and how proposed solutions would fit existing routines.Why: let partners walk through real deliveries in their own words, including workarounds they might not think to mention in a survey.
- Synthesis and readoutDovetail
Coded transcripts into themes and presented findings and opportunity areas to the cross-functional team.
Findings
Phase 1: Competitive analysis
ezCater’s self-delivery app lacked several features drivers rely on in other delivery apps.
Compared with four major platforms, ezCater’s app was the only one without delivery reporting for drivers and partners, and it lacked in-app navigation and multiple language options. It also offered only limited support for multi-stop routes and communication between drivers and customers. These gaps shaped the interview questions.
Phase 2: Partner interviews
Partners want to provide an outstanding, reliable delivery experience. The tools provided need to enable that, not stand in the way.
- 1The two actions that define delivery tracking often require attention and cognitive effort at the moments when drivers have the least to give.
Tracking depends on two taps: one when the driver heads out and one at drop-off. The app added friction to this process: reminders arrived on a fixed schedule instead of based on where the driver was, the button could be hidden below the fold, a mistaken tap couldn’t be undone, and some buildings had no cell service to record the tap at all.
Tap 1: Start deliveryTapped when the driver heads out. 
Tap 2: Complete deliveryTapped at drop-off. On long orders, it can sit below the fold. The partner app, shown with demo data.
- 2Orders predictably send drivers into complicated delivery environments with inadequate information, forcing them to fill the gaps on the spot.
Drivers often get a building address without the suite, department, or a reachable on-site contact. Workarounds like calling the customer or walking building to building use up time within the delivery window, which can impact a restaurant’s reliability metrics and delay the next stop on a route.
From the readout: the specific details and site context drivers said were missing, from suite numbers to building access. - 3Delivery batching is how high-volume partners survive the lunch rush, but the product doesn’t know it’s happening.
High-volume partners batch deliveries, but reliability timing is calculated from the restaurant, not the driver’s last stop. Some partners hide live tracking rather than show customers something misleading.
How the app times each order How partners actually deliver Illustrative example. The app treats each order as its own round trip from the restaurant, so it expects Stop 2 to take 12 minutes. On a batched route, Stop 2 is only 5 minutes from Stop 1, so an efficient delivery gets flagged as impossibly fast.
Outcome
I shared prioritized opportunity areas with PMs, designers, engineers, and leadership: fewer manual tracking steps, reminders based on route and distance, better delivery details collected at checkout, and treating multi-stop routes as a real use case rather than an edge case.
Reflection
What I took from it: Most of the friction came from the app not accounting for the situations drivers were in. Tracking prompts arrived mid-drive. A complete address meant something very different at a hospital campus than at a single-suite office. On a batched route, delivery timing was calculated as if each order came straight from the restaurant. It reinforced how important it is to study the context a product is used in, not just the interface.