top of page
TaxiIcon.png

Taxi Hailing App

LINE TAXI

Design and develop a new taxi hailing service in Thailand with all standard market features in 5 months

Objective
 

  • Create the first legal taxi hailing platform in partnership with taxi unions in Thailand in 5 months

  • Create a taxi hailing service in LINE MAN allowing users to request pickup and drop-off in the desired locations

  • Deliver an app that is on par with existing services and market expectations in the short time

Schedule

  • Kickoff in Jul 2017

  • Internal Launch and Testing in Oct 2017

  • Beta Launch in Nov 2017

  • Official Launch delayed to Mar 2018

Project Challenges

  • Providing all standard features available in competitor apps with limited time and resources

  • Working on the driver app, backend, and operation systems in parallel as the only service planner for the entire platform

  • 1 month to negotiate the requirements and design the user experience before development

  • Only 1 server engineer for the entire platform (lead server engineer left mid-project)

Role

  • Lead Service Planner (UX, PM)

A service planner is a hybrid UX designer, part project manager, part product owner and more.

Research

  • Due to the limited time and clear expectations from management to create a service that is on par with competitors in the market, I focused my time on conducting competitor research and finding points of differentiation in the interface.

  • Research was mostly focused on understanding existing services, the reasons behind their design choices and their operation policies and systems.

  • I researched services where I could test the full flow in Thailand and Korea, including Grab, Uber, Kakao Taxi, and Poolus.

  • I also referred to the designs and features of other notable hailing services, such as Lyft and Didi Chuxing.

Competitor_screens.png

Key Findings

Alike yet Slightly Different

  • Most hailing services had the same flow of selecting the pickup and drop-off points, choosing trip options and finally requesting a trip.

  • Minor differences existed in the interface design, the types of ride options available, and the information and features provided during an ongoing trip.

similarbutdifferent.png

Too Many Options

  • A lot of existing services were progressively expanding their vehicle lineup and ride options; I was expecting to see the same thing happen to LINE Taxi.

  • Grab was having difficulty with fitting in all of their service options in the existing interface, leading to long lists in a scrollable modal.

transportationt ypes.png

Cluttered Options in Grab

Communication is Crucial​

  • Communication between the rider and driver was a major function in competitor apps that played an important role in reducing unexpected conflict and trip cancellations (also noted in Grab's tech blog).

  • Many services provided both in-app chatting and phone call options.

  • It made sense to have a channel aside from calling as we later discovered that a lot of people in Thailand frequently changed their phone number and may fail to update their number in our system.

speechbubs.png

The Sensitive Issue of Cancellation

  • Cancellation is a sensitive issue for both drivers and riders.

  • Each platform had different cancellation policies, but one commonality was that most provided various pre-defined cancellation reasons to choose from, with each reason resulting in a different penalty.

  • I realized that it was difficult to have a policy that satisfied both parties from the beginning and prepared to tweak our policies as we operated the service.

Grab Cancel Chat.jpg

A heated exchange on Grab

Design Approach

Similar Flow, Different​ Look

Considerations

  • Wanted to avoid making a visual copy of our competitors

  • Wanted to maintain some consistency with the existing UI in other services in the LINE MAN app (e.g. food delivery service)

Approach

  • With the lead UI designer, we tested various design layouts and chose one that was somewhat differentiated with a flow that required the same number of steps as our competitors.

  • We purposely used an interface that had key similarities with the rest of the LINE MAN app to strengthen the brand image and make the experience familiar to users of our existing services.

Released designs of the main flow

fullflowuser.png

Easily Expandable Options

Considerations

  • The business and operation teams were already planning additional vehicle options and mobile payment methods (cash only for release).

  • Needed a flexible interface where minimal frontend development and design changes were needed to add more features/options.

Approach

  • Brainstormed with the UI designer for an easily expandable page and tested various designs.

  • We settled on a simple modular UI where additional options and features could be added in a list-like section in the scrollable trip options page.

  • At the bottom of the page, users can check the estimated time and price information and immediately make a request, all taking place in one page.

Released design and wireframes of trip options/summary page

TripSummarywithOptions.png

Best Effort at an Alternative Communication Channel

Limitations

  • An alternative communication channel was necessary for when phone calls were unavailable for the driver or rider.

  • Engineers determined that they were unable to create an in-app chat feature within the limited timeline

Approach

  • Since developing a full chat feature was out of the question, I designed an experience with a list of pre-defined status messages that we expected to be most frequently used based on the research conducted by the operation team.

  • I defined the requirement to have the list of pre-defined messages modifiable via the servers to change them as needed based on user feedback after the release.

Wireframes for status messages and phone calls

communicationattempt.png

Flexible Cancellation Policy

Limitations

  • It was difficult to define the cancellation reasons and penalties without prior user data or operation experience.

  • I was worried about the risks of having automated penalties for different cancellation cases and the potential backlash from both riders and drivers concerning the severity of the penalties.

Approach

  • I asked the engineers to make the cancellation reasons modifiable via the backend to change according to customer support feedback and user data.

  • For the initial release, I purposefully did not assign any automated penalties and after consulting the operation team, made it possible for them to detect irregular cancellations and manually suspend or ban abusive users.

  • I planned to refer to real user data generated after the release and implement automatic suspensions and penalties after we develop a sound policy.

Wireframe for trip cancellation flow

cancellationreasons.png

Unfortunate but Necessary Consolidations​

Limitations

  • With only 1 server and 1 client engineer available, many features had to be delayed in order to meet the deadline.

  • We also needed to minimize market disappointment with the release of a taxi-hailing service by the largest messenger platform in Thailand (It was also LINE's first major local service in Thailand).

Approach

  • Although additional vehicle and payment options were excluded from the initial release, I purposefully added a small popup to show users we had them planned in our pipeline.

  • As a taxi service released by a messenger platform, a full trip share feature via LINE was expected. However, due to limited time and resources, instead of taking out the feature I simplified the specs to a text message with driver and trip details sent via LINE with a richer experience planned for a future release.

  • The features and layout of the "driver on the way" and "on-trip" pages were simplified with minimal interactive components to meet the deadline.

Notice on future payment and vehicle options

taxitypespopup.png

Simplified trip share feature

Sharefunctionuser.png

Other

  • I added a feature for users to cancel and report a driver if the driver updates the status as pickup complete when the rider wasn't really picked up. This scenario was the result of a common form of abuse used by drivers to meet the requirements for incentive campaigns on other platforms.

  • Instead of making trip cancellations immediate, we showed a cancel confirmation popup before actually canceling the trip to make the user reconsider and minimize the opportunity costs incurred by drivers.

  • I added a banner section in the first page of the taxi service as a flexible medium for any important communication needed for unexpected issues after the release, including maintenance issues, promotions and weather issues.

Outcome

Market Success 

  • After the official release, we reached all internal targets and received positive feedback for providing one of the biggest government-approved taxi fleets for a hailing service.

  • With minimal changes in the user interface made since my leave from the team, the service celebrated a milestone of 1 million trips in October 2018.

"Chat app Line is launching a taxi-booking service to rival Uber in Thailand"

Techcrunch (Aug '17)

A Funny LINE TAXI Ad

Reflection

  • It was unfortunate that we didn't have enough time or resources to develop more differentiated user features and provide all the tools needed by the operation team.

  • We later discovered many abusive riders on our system, some from our competitors, who were making hundreds of cancellations a week; I later regretted not adding more automated user restrictions and ban policy in the initial release.

  • I was proud of being able to handle designing the backend and frontend systems of an entire taxi-hailing platform as the lead UX designer.

  • I also realized that I couldn't have completed the project without consolidating some of my responsibilities, seeking quick feedback and resorting to the opinions of the local team.

  • After my experience with this project, I became a more strategic negotiator and became adept at prioritizing and modifying specs as needed to develop a minimum viable product.

bottom of page