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.

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.

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.

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.

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: 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:  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: 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: 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:  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: 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.
 

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

" Cairo-based food discovery and ordering platform elmenus has raised $8 million in a Series B round, it announced today in a statement to MENAbytes.

The investment was led by Dubai-based Global Ventures and Cairo-based Algebra Ventures with participation from Tarek Sakr and Hamad Al Homizi, the co-founders of Kuwait’s 4Sale who recently partially exited their startup to NBK Capital. The round takes elmenus’ total raised to date close to $10 million."

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.