Building a faster delivery app for elmenus couriers
A self-directed exploration, done while working part-time at elmenus, into an in-house fleet app for their delivery couriers, tackling confirmation overload, low-spec devices, and GPS accuracy along the way.
Shipped
Seeing it in the real world
After a few months from this work, I placed my own order through elmenus. When it showed up, the courier at my door was carrying the elmenus Fleet delivery bag and running the app I’d designed. Genuinely good feeling, seeing it out in the world in someone’s hands.
ROLE
Product Designer
PRODUCT
Elmenus Mobile app
MY PART
Market research,UX, UI design
Overview
Scoping the problem and the challenge
About elmenus
Elmenus is a food discovery platform that helps people in Egypt decide what to eat and order it. Over 7 years it grew into the country’s leading food discovery platform, reaching over a million users a month with information on more than 8,000 restaurants, and has taken online orders since September 2018.
The challenge
Build a fleet and delivery app for elmenus’ own couriers, an in-house app in the spirit of UberEats or Deliveroo, so elmenus could complete its delivery ecosystem and serve its Cairo user base with a full dining experience end to end.
How this project came about.
I was working part-time at elmenus to help improve their app. This particular exploration, researching, designing, and taking a courier-side fleet app to high fidelity, was self-directed within that role rather than an assigned brief, and I sat down with elmenus’ actual product manager and delivery fleet manager to ground the direction. Properly understanding drivers also calls for dedicated UX researchers and a research budget, which I didn’t have, so rather than reinvent the wheel, my call was to lean on observation: reading reviews on platforms already running at scale instead of running my own moderated studies.
Process
Running research, definition, design and testing as a loop
I’m a big believer in user-centered design, so I set a few steps to guide the work: understand the problem and challenge first, then iterate and validate before calling anything final.
Part 01
Mapping the ecosystem, then observing 3 competitor apps
Mapped the three-sided marketplace behind every order and read how riders talk about three competing delivery apps.
Every order moves through three actors who never see each other’s screens: the customer placing the order, the restaurant preparing it, and the courier who is the only one physically present at both ends of the trip. Any friction in the courier’s tools shows up as a slower, less reliable delivery for the other two.
Customer
our customers are the trigger of the process, they are using our app to order thousands of orders per day 24/7 days and we do our best and provide a usable process in the app in order to make their experience as frictionless as possible.
Restaurant
The main partners of elmenus. We provide tools and services that make their experience as frictionless as possible. They are receiving the order via elmenus Merchant tablet and start preparing the meals and update the status of it continuously.
Drivers - Main persona
who are also the partners of elmenus, they are the main persona here, So I need to create an experience that fits their need to receive, Approve, and deliver the order with no mistake and without frustration.
Context
Naming who, how and where before the challenge
There is so much missing data about the context, And it is better to understand the context on where/when/how the app will be used to define the challenge and the clearly needs.
Who: Only the verified driver by the agency (third-party), Most of them have experience in food delivery, working on shift bases most probably with UberEats - and others have no experience.
How: Using only cheap android phones and most probably with 3g coverage.
Where: The app will be used while riding to different pick-up and delivery locations on their motorbikes in order to get more accurate instructions and to be able to update the status.
Who
Only verified drivers brought on through a third-party agency. Most have food-delivery experience, working shifts, most likely with UberEats; some have none.
How
Real employees get blocked or repeatedly asked to re-verify their identity: frustration, lost time, help-desk tickets.
Where
On a motorbike, riding between pickup and delivery locations, needing accurate instructions and the ability to update status on the move.
Discover and understanding the user
Choosing observation over research I couldn’t afford
Properly discovering and understanding users takes more resources, UX researchers and a suitable budget, and I didn’t have either. There was no need to reinvent the wheel, though: plenty of platforms were already up and running at scale, so my decision was to go with Observation.
1. Gathering user feedback
Plenty of food-delivery apps around the world had already solved parts of this problem well, so I went online to read how riders described the strengths and weaknesses of three of them.
Deliveroo Rider.
Reviews flagged battery drain from constant tracking. Riders called the app simple to use overall
DoorDash Driver
Reviews cited order glitches and dropped connectivity. Complaints about the app being slow to load on order pickup.
Fleet by Postmates
Notification and phone-number-change issues reported often. Riders wanted an easier way to reach support from the app
How to use Doordash, UberEats & Deliveroo apps step by step
2. Training videos on YouTube
YouTube had plenty of onboarding and training videos for courier apps like Deliveroo, DoorDash, and Ubereats. Watching them helped me empathize more with the user flow, and understand more of the context, challenges, and needs users might have.
3. Collaborate with PM and delivery fleet manager
After the reviews and training videos, it was time to collaborate. I sat down with the product manager and the delivery fleet manager, who’d previously managed a fleet at another delivery company. I’m a believer in pairing the product designer with the product manager: the PM represents the business, so the company’s goals matter as much as the user’s needs. A unified design-only perspective sounds good in theory, but it doesn’t hold up in real life. You need more than one perspective to solve the problem and satisfy both the users and the company.
Part 02
Tracing delivery delays back to 4 root causes
After a lot of discussions and going through the user reviews, various contextual situations, and interviewed the fleet manager, I assume the following are some of the pain points I can tackle in order to elevate the end-to-end user experience.
Too many confirmations
it was obvious there are too many confirmations required from the driver ( arrived at the restaurant, Picked up the item, on my way, etc ), there is a call to action for every single movement that the driver makes. It was a very frustrating thing for the driver especially when he drives.
An old device with low GB Ram and perform on low-speed networks
the main persona - a shift bases driver - have low incomes and for the sake of technology limited and the weak infrastructure of telecoms network in the country, We assume the driver will use the cheap android device and 3g connections for most of the time.
Geographic distribution
Our solution will be based on time-shifts and order bonuses. So we need to make sure that the driver is in the right place and ready to receive orders.
GPS accuracy
a cheap device will give you a cheap GPS chip which will reflect on the accuracy, So we need to reduce the use of CTA based on GPS locations and switch to be automatic ( Set a radius or range might be a solution ).
Walking the order-to-delivery journey step by step
The goal of creating the user journey is to understand how to operate the app in order to accept and complete the jobs, I split up the experience into six stages/parts, each one of them has its own requirements and challenges. The flow starting with opening the app and waiting inside the hotspot in your area:
1
Accept job
Driver taps
Accepting the incoming request for a new order through some sort of alerting view having some summary info about the order.
2
Arrived at Restaurant
Automatic
For the sake of reducing the performed call to action, we need to make it an automated process by drawing a radius circle on the google map around the restaurant location, and when the driver being into this circle, the server will get a confirmation that the driver in the restaurant or at least near of it.
3
Pick-up The Food
Driver taps
The restaurant be prepped the meal and packed to make it ready for pick-up and the driver arrives at the restaurant and pick-up the meal, A confirmation flow will be performed in this stage. Also, he will need to capture pic from the receipt.
4
Out For Delivery
Driver taps
A confirmation action will be performed in this stage by the driver to show the customer info ( Name, Address, and Phone number ).
5
Arrived at Customer Location
Automatic
For the sake of reducing the performed call to action, we need to make it an automated process by drawing a radius circle on the google map around the customer location, and when the driver being into this circle, the server will get a confirmation that the driver in the customer or at least near of it.
6
Deliver the package
Driver taps
A confirmation will be performed by the driver to inform the server that the order has been delivered.
Part 03
Ideating with the PM and fleet manager
Sat down with the product manager and delivery fleet manager to turn the two biggest pain points into solution directions.
Brainstorming with the product manager and the delivery fleet manager gave me a chance to explore ways to fix the pain points directly, rather than design against them in isolation.
Too many confirmations
Reduce the confirmation taps by making arrival automatic: draw a radius around the restaurant location, and once the driver’s GPS enters it, the server logs the confirmation on its own.
Geographic distribution:
Since the model runs on time-shifts and order bonuses, a driver needs to be in the right place to receive jobs. A heat map became the solution: a courier only shows online and eligible for orders while inside the heat map’s range.
Decision
Trade-off
Wireframing the map-first active-job screen
After I had a better understanding of user behavior and the process, I have listed some key features of the app in order to create high-fidelity wireframes. Wireframes gave me some ideas on how things would look like and made my work for visual design easier.
Status Indicator & other info
This is designed to give the rider a quick indicator of his status online/offline and how many jobs/deliveries he did in the day.
Swipe CTA
swipe button is among the most important, It gives the driver the access to accept the job and start his journey.
Summary Card
display essential information to drivers like the restaurant details, estimated fare, estimated time duration to help them make decisions.
Restaurant location and radius
the idea is to draw a radius circle on the google map around the restaurant location, and when the driver being in this circle, the server will get a confirmation that the driver is in the restaurant or at least near it. No more CTA
Part 04
Designing the flow a courier runs on every trip
Took the wireframes to a light, glanceable interface built for one-handed use mid-ride. With the structure validated, I moved into high fidelity, keeping the palette light and the map as the dominant surface on every screen, since a driver checks it more than anything else in the app.
#1 Splash & Login Screens
#2 Incoming Request & Pick-up
#3 Drop-off the food
#4 Order History, Profile & Menu
Measure success & Validation
How I validated it
A solution isn’t worth much if I don’t know whether it worked, so I ran usability testing on the high-fidelity prototypes: giving people defined task scenarios and measuring KPIs like task completion time and task success rate. The results themselves are confidential, so I can’t share the numbers here, only the method.
What I’d do next.
Widen usability testing to drivers on the lowest-spec devices in the field, since that’s where GPS accuracy and network speed matter most, and validate the automatic-confirmation triggers against real geofence performance rather than assumptions.
We got a new investment
Seeing it in the real world
After a few months from this work, I placed my own order through elmenus. When it showed up, the courier at my door was carrying the elmenus Fleet delivery bag and running the app I’d designed. Genuinely good feeling, seeing it out in the world in someone’s hands.
Conclusion
This was a genuinely fun project to work on, and working with the elmenus team was a great experience, especially the collaboration and communication. I’m happy to walk through the research or any of the trade-offs in more depth.