Nassim Hadj benali
Yassir is a super-app with 8M+ users across six countries, offering ride-hailing, intercity travel, parcel and food delivery, flight booking, and digital financial services.
Open this case
Project Title:
Ride Radar feature
Operating on:
Mobile: Android/ iOSWeb: Config Dashboard
Project Description
Ride Radar (or Trip Radar) is a shared list that lets eligible drivers view and accept trips missed by standard dispatch. Despite early challenges with trust and consistency, the launch of Radar V2 significantly improved driver adoption and trip acceptance rates.
Client Name:
Yassir Inc., United States
Goal:
The idea behind this feature is to motivate and engage drivers to perform better, provide excellent service to customers, and ultimately increase customer satisfaction.
Location
United States, South Africa, Algeria, Egypt, Senegal...
Role:
Defined the experience principles for how Radar should coexist with traditionaldispatch.
Partnered heavily with Product, Engineering, and QA on rollout and iteration.
Used quantitative data and qualitative driver feedback to prioritize UX improvements and roadmap direction.
Timeframe:
September 2025 - 3 months
Understand
Yassir’s Ecosystem
My contribution at Yassir
Product
Services/Squads
Projects I worked on
B2B
Dash OPS
InterCity
Foundation Colors(Revamp)
Rider app Revamp
Food Delivery
Financial services (Wallet)
Airline Booking
Patterns
Components
Foundations
B2B Ride Hailing
Admin Panel
Ride Hailing
(VTC)
Driver Challenge
Ride Radar
Onboarding businesses
...
...
...
...
...
Driver Retention
& Performance
Driver Onboarding
Trip Request
Driver App
Super app(B2C)
Design
System(SEFAR)
...
We are here !
Acquisition
How might we improve trip allocation by giving drivers more control,...
without increasing confusion, distraction, or risky driver behaviour?
Problem statement
In a classic dispatch model, drivers receive ride requests one by one. When a trip isn’t accepted after several attempts, it can remain unserved—reducing trip utilization and degrading the rider experience.
Goals
Improve conversion for trips that fail initial dispatch attempts.
Increase driver engagement with the dispatch system.
Make Radar understandable quickly.
Preserve driver trust through consistent decision-making information.
Radar’s Key Design Moments
First things, first !How rides enter Radar?
Rides start in normal dispatch. If not accepted after a predefined number of attempts, a trip becomes visible in a shared Radar list to eligible drivers within pickup radius
Driver 1 Declines
Driver 2Declines
Driver XDeclines
Ride dispatch
Drivers receiveindividual Ride requestas an overlay
Ride radar
Ride lands in a market/pool to increase its chances to be taken
New Mental Model
From “push-only” → “pull + browse”
Before: Dispatch interrupts you. You react.After: Radar lets you browse options and choose intentionally.
“The biggest UX conflict”
Browse mode vs interruptive requests
A ride request overlay can block the Radar list and push drivers to reject rides just to continue browsing, increasing the risk of penalties.
Renaming to 'Best Choice' Outperforms 'Exclusive Ride'
Drivers must understand whether a request is:
Exclusive: only one driver is seeing it.
Non-exclusive: it is already in Radar and visible to multiple drivers.
This distinction changes urgency, competition perception, and the information drivers need to decide.
Later, we could noticed the distinction was too technical for drivers, therefore, we tried another wording in collaboration with UX Writing team.
Discoverability without noise
Introduced a home entry point with lightweight tooltip onboarding.
In order to enhance the experience to an ideal safety for users, we implemented a chat feature. users can communicate only after acceptance and no need to exchange private contacts
Data + User insights
ETA-to-pickup is a key acceptance driver. Our main findings “If ETA exceeds ~8–15 minutes, drivers often will not accept the ride”
“I never accept far pickups, it’s a waste of gas and I know, the ride won’t be so profitable”
Live inventory expectations
Radar must feel “real-time enough”:
Accepted rides should disappear quickly. Timed-out rides ought to be removed as well. This will guarantee this feel of “Live inventory” for the users by automatising the management of cards and a refresh of the list for “X seconds”.
90%+
Driver engagement increased from ~75% daily average to 90%+
↑
Significant increase in radar acceptance / fetched rides
x2
Radar acceptance vs regular acceptance nearly doubled
Radar Deployment
Early signals reported:
User Flow
x1.4
x1.2
x1.1
x1.1
x1.2
x1.3
x1.3
x1.1
x1.4
x1.1
1 250 DA
Ride radar
x1.4
You’re online
Swipe up to view all notifications
Home
Rides
Earnings
Balance
Ride Radar
Searching for rides...
Please wait while we find you nearby ride requests.
Ride radar
Scheduled Rides
3
600
DA
Amine
•
4.5
(56)
Cash
3 min • 1,2 km
Saïd Hamdine, 09 Rue de Yassir...
35 min • 9,2 km
Bab Ezzouar, 05 Cité Rabia Tahar...
Accept Classic
600
DA
Amine
•
4.5
(56)
E-Payment
3 min • 1,2 km
Saïd Hamdine, 09 Rue de Yassir...
35 min • 9,2 km
Bab Ezzouar, 05 Cité Rabia Tahar...
Accept Classic
UI Design
Revamping Card Information Architecture...
...& Accessibility, especially since our drivers are not tech-savvy and mostly drive.
This was the stage in which UI plays a big role. our 100k partners are aged mostly between 35-50, aren’t familiar with technology and they are mostly in their cars, sometimes even parked on roadsides. Readability and quick scan of information are key.
Original Trip request Card
NEW card
Shrinking the card size was essential since it was the primary limitation; the cards must contain all key information for the driver’s decisions while also fitting as many cards as possible on the screen.
Default
1st Section
2nd Section
CTA
Ride details
Rider information
Number of drivers viewing
Price
ETA + Address
Itinerary details
Main CTA
Edges cases
1st Section
2nd Section
CTA
Ride details
Rider information
All tags are grouped together to inform for Service, ride type, commissions & Payment Method
Price
ETA + Address
Itinerary details
Main CTA
Dynamic Button Biggest funnel, easy acquisition, clarity, attracts attentionThis button component has many layers of animation, all play a role in acquisition.
adding to the pulse a subtle animated stroke to enhance the effect of the radar scanning.
The button toggles between collapsed and expanded state after ‘X’ seconds to show the user the number of available rides.
The Pulse is the pumping heart of the UI
Radar Card
The Radar card is one of the most complex patterns in our library.
Payment Methods
Main header component contains other nested components such as: Price, payment methods, commissions, rider information,...
Price Component
Rider Information component
Address list component
Main header component contains other nested components such as: Price, payment methods, rider information,...
Boosting the “Boost feature”
Revamp of the pricing component by adding our brand new green tokenWe later seized the opportunity of a very high adoption of the Radar and introduced a slight change to the UI of the pricing component to try to solve the low adoption occurring in the boost feature during the rider’s trip request and increase awareness of th feature.
Home
Up
Next Case
