Your ride will start soon…or will it?
Beat offers an amazing transportation experience 24/7. All you need to do is to hail a Beat at the tap of a button and get picked-up in just a few minutes. In this article, we explain why we decided to invest effort in re-designing the passenger’s request screen and what’s the design process we followed to craft our MVP.
Introduction
Committed to providing an extremely user-friendly experience for our passengers, towards the end of last year, we released a new iteration on the Passenger Request screen. This is the screen where passengers wait for a driver to be matched. It is a critical screen for our conversion metrics as the last thing we want is for the passengers to feel they need to cancel their request while we are trying to match them with a driver.
Problem Statement
Looking back to our data, we discovered that about 24% of passenger requests were canceled by passengers themselves. And not only that, but a lot of times those passengers ended up re-requesting within a span of seconds which makes us think that passengers don’t really understand what’s happening behind the scenes and they feel they have better chances to find a driver with a second or third attempt to request.
At Beat we have a whole domain — named after the task, i.e. the Matching domain- that works specifically on deploying the best solutions to help both passengers and drivers, reducing wait times.In the Matching domain this step is critical in all algorithms that try to match a passenger with the best driver.
Forming our hypothesis
The first thing we did was to develop a hypothesis: if we reduce the number of passenger request cancellations and make the passengers feel comfortable to wait a bit longer on this screen, we would be increasing our request conversions to rides.
Forming a hypothesis is our starting point because it allows us to focus, to have data-informed behaviour, but also to think of unexpected negative scenarios in advance i.e. what if passengers behave in the opposite direction than the one we think they will do?
Meanwhile, we became a meme
What was our approach?
The method we followed to solve this problem was simple. We first conducted a survey in order to identify the passengers’ pain points and also collected reviews from app store and google play. Then, we gathered quantitative data to better understand the users’ behaviour and started ideating. After wireframing, we tested with users in the local markets in order to validate our hypothesis and come up with the MVP.
User Research
Our next step after identifying this drop in the funnel and forming an initial hypothesis was to dig deeper into our insights, -both qualitative and quantitative- and understand all the triggers that make a passenger cancel their request.
For a bit of context, this is how our screen looked like before:
One thing that is obvious is that the screen is quite static and does not convey a lot of information. There is only a spinner and the only action available to the user is to cancel their request.
Survey
Our next step was to go out, talk to some of those passengers and understand why they canceled their request. Damaris Egaña, who at the point of this research was our Product Operations Specialist in Chile, went out, talked to our real passengers and ran a survey.
At that point, what we learned is that:
- Users consider the screen as static or frozen.
- Users cannot understand if their request is still in progress.
- The current screen does not provide the necessary information to passengers.
Beat Reviews
Here is what one particularly dissatisfied passenger had to say about the experience on that screen:
My ride will start soon… Well, after waiting for half an hour, I guess your app doesn’t work today. Or else you could say “looking for a taxi”, but I guess this would cause the client to stop the search, so you prefer lying…
1 star for the message “your ride will start soon”, which sets wrong expectations… It only adds to frustration when waiting times are high.
Quantitative Data
Post-covid demand has increased massively in our passenger app as people are looking for safer transportation in the city. So the combination of slightly higher than expected waiting times at peak hours with a static request screen that gives out no information, is detrimental to passengers.
Here is what our data told us:
- The amount of request cancellations correlates with our market share. Meaning that in markets where passengers know they will find a trip, they don’t mind waiting a bit longer.
- Passenger waiting tolerance reaches a peak at 1 minute.
- More than half of our passengers end up re-requesting a ride after they have canceled their previous request within minutes.
Empathy Map & User Journey Map
In order to synthesize all the insights from the user research, we created both empathy and user journey maps.
Ideation
Brainstorming
Having all insights in place, we facilitated a brainstorming session with participants from the Product and Engineering teams as well as colleagues from the local markets who are closer to the end-users. Reverse brainstorming techniques led to innovative and out of the box ideas! With crazy 8s we refined them and turned them into solutions.
Wireframes
First, we started sketching out some ideas on paper to see how we could approach the new UI in order to resolve the problem. Then, we proceeded with low-fidelity designs to discuss and receive feedback both from the team and in design critiques.
The next step was to filter out the less effective solutions and start working on mid-fidelity prototypes to test with users in Latin America.
Usability testings
We came up with 2 prototypes for the first wave of user testing to validate the hypothesis that if we show the progress of the request and provide transparency to the users they will stay longer in that screen. As a result, we will increase our conversion to a ride.
Studies have shown that when you wait for something to happen or you are in a hurry, the perception of time is distorted, you might feel that time passes way faster and that this process is too slow which might lead to early cancellations.)
We also know that motivation increases as users believe they are nearing a goal (Endowed Progress Effect)
1st Wave of Usability Testing in Mexico
So in order to change that and to also add some transparency in that state, we tested 2 different prototypes:
Prototype A included a drawer with:
- Car animation.
- Interesting facts about their journey.
Prototype B included a drawer with:
- Information related to their request (service, pricing, and the payment method).
- The Estimated Time of Arrival (ETA) to their final destination.
- Radars on the map indicating the available drivers in the area.
We also added a progress bar to both since we knew that the lack of progress indication was one of their key pain points. In addition to that, we deprioritized the cancel button as in the older version was the most prominent element in the screen and according to some users “almost appealing to tap”.
In the first wave we tested with 4 users from Mexico who had recently canceled a request.
The participants showed a strong preference for the prototype B, with the more essential information. Based on that and additional feedback, we iterated and tested again with another group of people.
2nd Wave of Usability Testing in Mexico
In the 2nd wave of usability testing, we kept the progress bar,the trip related information and we also added car avatars on the map showing the nearby drivers to validate whether this extra information would provide assurance to them that they might get a ride soon.
Final Solution
Based on the latest feedback and also taking into consideration technical limitations both from the mobile and Backend side we defined the MVP that included the progress bar, the service, the price, the payment method and the duration of the trip.
Validation / Outcomes
After developing our MVP, we put our hypothesis into test. We a/b tested the new screen across our markets. We observed a drop in passenger request cancellations and indeed an increase in the conversion of completed rides due to the fact that passengers felt more reassured and in the meantime we were successful at finding them a driver.
Conclusion
With our hypothesis being validated and positive feedback from passengers, we realised that users appreciate the transparency and are willing to extend their waiting tolerance for it.
At Beat, we are always up to build solutions for a flawless customer experience. Placing the customer first at everything we do, in the future we plan to add more relevant information on the screen that will make passengers excited for their upcoming ride.
If you found this article interesting and you are looking for your new challenge, check out our open roles.
About the Authors
The Product team within Beat’s Matching domain is a cross functional team that includes Product managers, Product designers and Data analysts working together to find the best passenger and driver matches. In our domain we combine engineering, machine learning and user experience principles to create scalable solutions to benefit our users.
Afroditi Katika is Principal Product Manager at Beat. Before joining the company, she worked in the UK for organisations such as Transport for London and BBC. She left everything behind in exchange for an office location with a view to sunny Athens and Beat’s mission.
Ioanna Marasioti is Product Designer at Beat. She designs new features with a user-centred and data-informed approach. Her prior experience is in building user interfaces and digital products as well as animations and marketing visuals. She works remotely from Rhodes.
