Redesigning the booking flow
This feature improved demand identification, achieving 80% occupancy across three launched buses, increased confirmation page conversions and boosted revenue by 7%.
Imagine your favourite go-to breakfast place, the person behind the counter is a familiar face that acknowledges you with a smile. You are about to tell them your order and before you could say anything, they hand you your parcel - the everyday regular that you prefer.
Feels good, right? Feels familiar and relieving that you now have to take one less decision, one less thing to worry about, one less thing to check up on as it’s been taken care of.
We wanted to reciprocate the same feeling when our users signed up on our platform - showing them exactly what they needed without sending them on a scavenger hunt.
What is Cityflo?
Cityflo is an app based bus commute service trying to solve the problem of a substandard daily commute across India's metros by providing a high-quality solution that's innovative and simple. Our Benz AC buses have led to professionals giving up their cars to travel to work.
Cityflo users are primarily professional white-collar employees who work at companies located in corporate hubs such as BKC, Lower Parel, Colaba, Andheri E., Goregaon, Powai. Cityflo is targeted towards users who previously drove to work and expect high-quality service levels.
Some context -
The current booking flow was rudimentary. Even after asking for necessary information from the user during onboarding, we still made users choose from list of locations and timings without giving them a helping hand. This list means users having to choose from 12-15 cards depending on the route they were on.
Secondly,
Another important reason to take this up was to help growth team with demand identification.
User patterns we were aware of -
Old booking flow
Let's take a scenario: Our user Bhavana is a Bank manager who stays in Thane & goes to work at Nesco IT Park, Goregoan. She starts her day at around 8:30 in the morning to avoid traffic and reaches office at 9:40 am.
She recently got to know about Cityflo when her colleague referred her the service. After onboarding the app and giving all the necessary information, the app does not help her.
She now has to read through all the possible route options, decide which one would work best and then again repeat the same process to select the time that works for here even when she had already given this information.
💭 Some open questions that Bhavana might have, considering she's a new to the platform-
- How far is the stop from my home?
- What route is the bus going to take?
- How do I identify my stop?
- What if I miss this bus?
How did we go about it?
To begin with, it was imperative to understand what information did our users needed before making a decision of choosing a bus. What were the preconception our users had and how will the app help them with the same.
- Recommending buses that will help users reach their home/office on time.
- Grouping information so that it helps user take a decision easily
- Showing relate secondary information which is easily accessible
- Ability to tell users suggest timings that they would prefer a bus to help with demand identification
To understand it a little further, I wanted to see how Mumbai local's indicator worked. They seemed to have similarities with what we wanted to achieve - make a choice! At first I did feel the information was overwhelming but it was important to make an informed decision, one which is going to impact the routine for the day.
The tough nut to crack
When a user signs up on Cityflo, it is important for the user to make sense of Cityflo as a service and start using it. The questions that Bhavana had, had to be handed to her in way that is easy to understand and lastly, helps her book a ride.
Why cards? The contextual dat displayed in these bite-sized chunks successfully displayed the right information, in the right context, for this use case. It provided organised, systematic clubbing of information in digestible amounts.
The final card, a summary of information about a particular unit.
Initial Prototypes
While I was tinkering the card layout, it was also important to tackle the issue of demand identification, understanding and getting suggestions from our users itself. These flow were tested internally and we realised that the first one worked best, reasons -
- Not every user is going to have to suggest a time, it was for some users and on some routes only
- Showing the large list of timings was overwhelming & confusing, for some
Recommendation Logic
When a user searches from point A to point B, in the results, we will always show a maximum of 3 stop combinations, with a relevant time pre-selected. This is to make the choice simpler for the user as there are unlikely to be more than 3 relevant pickup stops for the user.
These 3 stop combinations could have a ’tag’ to help the user identify with the choice and understand it better, or they could be without a tag.
To get the results and recommend the best option to the user, first, we will get corresponding valid stop pairs and check to see if we can get any of the following preferred options of stop+time combinations -
Final flow & the impact -
What improved?