Captain interacts with the new feature.
Nicole Lombard
UX Writer
High Density Locations
Making it easy and seamless for drivers to find customers in very busy places.
The problem
Less than 2% of Careem's pick ups are from the airport and these trips are usually just once off (per customer). This is very worrying when looking at our competitors. For example, 20% of Uber India's revenue is from airports and another ride-hailing company in India, Ola, spends an estimated $90k to run its operations at Chennai airport alone.
It's difficult for Captains (drivers) and customers to meet each other in very busy locations like malls, airports and festivals this has led to some of the lowest rated trips at Careem. The goal here was to significantly improve the pickup experience at HDLs (high density locations) with both operational and app experiences.
The solution
Make sure that the Captains know that they are in a queue system and what their position in the queue is. They should know that the area is very busy and that they're likely to get a booking if they stay in the queue. There would also need to be a person physically present to direct Captains to designated parking bays depending on their position in the queue.
The process
I went through existing designs (with placeholder copy) and amended and simplified where it was needed. Changed the word "Dismiss" to "Stay in queue" so the Captain knows exactly what he's doing. I was quite unsure about using the word "queue" since our Captains are not all fluent in English. We kept "queue" for the first test since the same word was used by Uber and many Captains also work for Uber so they might be familiar with the term. It was clear that we had to test with Captains to determine their understanding of the feature as well as the language.
Iteration 1a (above) testing
We went out to interview some Captains and to see their interaction with the feature. Luckily our Project Manager could give the Captains context in Urdu, as most of them are from Pakistan.
Captains seem to understand the queue concept but not necessarily the word. They didn't understand the concept of a customer having to give them a PIN. (This is the first time they're exposed to this, so makes sense.) All Captains think that the indicated time is driving time, don't understand that it's waiting time.
(Upon seeing the middle screen above). They understood that their position in the queue has changed. Some Captains didn't know what "#" meant.
We needed to explain the PIN concept since it's new, there will definitely be some onboarding in terms of this. After explaining, the Captains easily understood what to do.
Iteration 1b
We then showed them what would happen if they were to drive out of the queue/area. (image on the left) Some Captains understood that they were leaving the queue and that if they returned they would get a new queue number. Some believed that they would still get outside bookings (not queue related) while in the queue.
All Captains found the process easy but repeated that they need to be introduced to this feature during their training. Of course the need for education is not ideal since the designs should speak for themselves but I believe this is different when the target market are not fluent in the language used and are in some cases not completely literate.
Iteration 2
Based on the Captain feedback some design changes were made. The copy was also amended.
I changed "Dismiss" to "Stay in queue" for some additional clarity. The "#" symbol was replaced by the word "number" since some Captains weren't familiar with the symbol.
The word "ride" was changed to "trip" everywhere for app consistency.
The copy on the push notification was also amended, since the existing copy didn't make that much sense. ("See your expected wait time, or exit the queue.") Changed to "Wait for the indicated time or leave the queue."
Iteration 3 (see below)
We had a meeting to catch up on the latest copy and design for the HDL feature and made some changes based on aspects that we thought could be added or improved.
Firstly, we realised that there might be a chance of a Captain just driving close to the HDL area and that he would not necessarily want to join the queue. So we added an opt-in screen.
On the PIN entry screen- we realised that the PIN might be confusing since the Captains have a PIN that they need to use when logging into their Captain Careem app. So we added the word "customer" to clarify.
Made some copy changes on the "Leave queue" to make the message clearer. It said "You will be able to receive all bookings after exiting." The phrase "all bookings" sounded a bit ambiguous so I changed it to say "You'll still be available for bookings outside of the queue."
For the push notification when asking the Captain whether he'd like to join, I recommended that we needed to give him a good reason to do so. What's in it for him? So I changed the body copy of the message to "You're likely to get a booking here."
Final testing
We unfortunately only had time to test with one Captain but the feedback was promising nonetheless.
He understood that the indicated time was waiting time. The queue number indicates to him where he stands and also lets him know that he will get a booking. The Captain understood what it meant to leave the queue and that he would get a new queue number on return to the area.
We had to give context about the customer PIN bit, as expected. But he understood everything else.
So the MVP is ready. We'll need to do some training on the PIN aspect and test the feature at a later stage so we can iterate and improve it where we can.
Final design and copy:
Solved the confusion over the wait time being the time to the destination by moving the time range onto the map so it wouldn't be so similar to the waiting time that they're used to see. (Also added "Wait time")
The instructions on what the Captain needs to do (Wait nearby) and where he needs to do it (Level 1 parking), are clear in bolded text.
Made sure that the Captain knew that we are referring to the customer PIN and not their own app login details.
