Understanding Bus & Shuttle

Bus & Shuttle is a product from tiket.com, where users can purchase Bus or Shuttle tickets to travel from one city to another.

The main flow of the product is:

• Landing Page: Users can input depart & arrival city, date of travel and amount of tickets.

• Search Result Page: Users select the type of Bus or Shuttle they want with ability to use our Filter & Sort features.

• Product Detail Page: Users can view the full details of their selected transport.

• Choose Seat Page: Users can select where they'd like to sit.

• Booking Form Page: Users input their passenger datas.

Identifying the problems

To further understand our low conversion rate, we conducted two research methods:
1. User Behaviour Analysis: Identify where user converts and drop-off through Amplitude's real-time data analytics
2. UX Room: Identify user pain-points through Live Usability Testing

Though we have identified multiple potential pain-points, we used a Impact x Implementation Matrix to rank which problems are worth solving with our given development time. To do this, we invited our Product Managers, Business Team and Tech team to help rank the problems.

Impact-to-Implementation Matrix

From our workshop, the top problem to solve and easiest to implement was: "Users often receive 'No result Error' in our Search Result Page". Hence, we can start breaking down the problem.

The Root Problem

"Users often receive 'No result Error' in our Search Result Page" is a result of our location data - the root problem. All of our Bus & Shuttle vendors come through a third-party aggregator and it comes with inaccurate location datas (as explained in the image below).

To sum it up:

• The Cause: Bus & Shuttle agents/vendors are able to define the name of their own depart location & arrival location, which creates multiple datas that are actually the same location but not grouped as the same location.

• The Effect: When users search Agent 1’s location along with Agent 2’s location, there will be no result in Search Result.

This causes a handful of no results in our Search Result Page when users are searching, which brings us to our 3 main Search Result Page Results.

Search Result Page Results

When users search for Bus & Shuttle product, there are 3 possible results that they'll get in our Search Result Page:

1. Result 1: Normal Result

   1. User searches City to City, Area to Area, Terminal to Terminal

   2. Results are shown in Search Result Page

2. Result 2: Error Result but with Alternatives Routes

   1. User searches Area to Area, Terminal to Terminal

   2. No inventory available but City to City level is available

   3. City to City Results are shown as alternative routes

3. Result 3: Error Result

   1. User searches City to City, Area to Area, Terminal to Terminal

   2. No Results are shown in Search Result Page

   3. Mostly due to RedBus Location Data

Based on our data analysis, 83.4% of our total Search Results end with either Result 2 or 3, mostly in Top Route cities, and 79.7% of them end up dropping off.

While we are solving the location data from our third-party aggregator, in parallel, we ideated solutions to enhance the experience of Result 2.

Breaking down the problem (Hypothesis & How Might We)

Before jumping into the designing process, I created hypotheses on the pain-points our users may experience, which can be broken down into 3 points:

1. Header Information

2. Error Message

3. Alternative Routes

Based on these hypothesis, I created a "How Might We" framework, to help guide me when I'm creating solutions to the hypotheses/problems. Through this framework, I am able to filter out important features to highlight when doing competitor's analysis and ideation.

Final Designs

After several design explorations, the designs are improved in the following 3 sections:

1. Header Information

2. Error Message

3. Alternative Routes

To validate whether my designs worked, we conducted an A/B Experiment to test both designs. The new designs resulted in the following results: