Project Objectives
-
Create the first legal taxi-hailing platform in Thailand in partnership with taxi unions in 5 months
-
Create an app for taxi drivers to select orders, communicate with riders, and complete trips
-
Provide an easy driver ID verification and registration process for early recruitment
Role
-
Lead Service Planner (UX, PM)
A service planner is a hybrid UX designer, part project manager, part product owner and more.
Schedule
-
Kickoff in Mid May 2017
-
Partial release in Aug 2017
-
Full feature release in Oct 2017 (5 months till release)
Project Challenges
-
Partnering with outdated taxi unions in a highly competitive market with Uber and Grab
-
Limited time with only 1 server engineer and 1 service planner for both rider and driver systems
-
Managing feature negotiations and aligning goals with various stakeholders in both countries
-
Working in a multicultural/multilingual team with frequent business trips (bi-weekly)
Process
The overall process was a flexible waterfall method with many of the processes occurring in parallel or reiterated as necessary.
The project was kicked off with many of the business requirements and strategy still being defined, requiring me to define much of the product requirements and strategy on behalf of the local business team. A lot of my resources were also spent on facilitating communication between the Korean and Thai offices and negotiating with various internal and external stakeholders on product features and partnerships (e.g. taxi union, LINE pay team)
Research
For the driver app and platform, with the help of the local operation and business managers for translation, I conducted a combination of user research, desk research, and competitor research.
Interviewing at a gas station
Testing early builds
Interviewing Grab/Uber drivers
Group interviews at a local taxi union
-
For user research, focus groups and expert interviews were conducted through the local business and operation teams in order to understand the industry, working conditions, and complaints drivers had with existing platforms in Thailand.
-
We also sought the opinion of taxi unions and drivers to understand their expectations in a taxi driver app from LINE and what they hoped to accomplish through the partnership.
-
Desk research included researching online driver forums (i.e. Uber) and looking into various content released by taxi platforms in Korea and the US to get an understanding of how drivers engaged with the platforms
-
The local operation team focused on gathering information on driver management and incentivization, while I researched the various features and experience of the driver apps.
Key Findings
Tech Unsavvy and Financially Driven
-
Most unionized taxi drivers were of older age and were unfamiliar with mobile apps and common app UI.
-
Many taxi drivers were using low-end devices, in some cases using multiple low-end devices.
-
Drivers were mostly financially driven and a lot of existing platforms were prone to drivers abusing payment and incentivization schemes.
Small screen/low spec devices
More Complicated Than We Thought
-
After researching competitor driver apps, we realized that the scale of the necessary system was bigger than what we anticipated, especially with payment and finance management features involved.
-
Some additional features aside from choosing and executing rides included driver verification, trip management, issue reporting, financial reporting, balance management, and mobile payment.
Grab driver app in action
Driver Visibility and Interaction
-
Drivers needed to be able to browse through and choose incoming trips at a glance while driving.
-
A lot of unionized drivers were of older age with poor eyesight, some explicitly stating their preference for larger text and bolder colors.
Observation of a Grab driver
Design Approach
Fully Online and Foolproof Registration
User Problems
-
Registration drop-off by drivers unfamiliar with mobile apps or being too bothered
-
Registration drop-off resulting from requiring offline submission of documents
-
Rejection due to minor mistakes or the submission of wrong information
Approach
-
Allowed the submission of documents by uploading photos in the app, unlike our competitors that required offline submission.
-
Forced a visual guide popup every time the image upload button was pressed by drivers to visually remind them of the right document.
-
Provided a button to immediately call the call center in all steps of the registration process to provide support whenever necessary and minimize drop-off.
Wireframes for vehicle info input
Wireframes for ID info and photo input
Obvious and Explanatory Interface
User Problems
-
Difficult to train all drivers and make them remember each step, menu and features
-
Older drivers being unfamiliar with common icons and mobile interfaces
Approach
-
Made the key buttons as obvious and self-explanatory as possible by using mostly text labels
-
Requested the use of a skeuomorphic design for the primary on and off duty button for it to stand out to older drivers and help them easily recognize their status
-
Focused on making the features as simple as possible with plans for more advanced features to be added in future updates.
Released designs of the off duty, on duty and on trip pages
At a Glance Feed
User Problems
-
Drivers facing difficulty in interacting with the interface while driving
-
Drivers failing to recognize new orders and on/off duty status while driving
Approach
-
Instead of showing a list of trips, each trip request was provided in an automatic slideshow format to allow drivers to check incoming trips without needing interaction with the app
-
Used contrasting background colors (white, black) between on and off duty statuses to make the status immediately recognizable and visually distinct
-
Designed a distinct notification sound to ring for each trip request to make it more recognizable
-
Used bold contrasting colors with larger than usual text sizes to make it easier to read
Released designs of the on-duty requested trips page
Partnership and Integration with LINE Pay
User Problems/Limitations
-
Not enough resources to create our own payment solution
-
Drivers not registering to a mobile payment solution and not knowing how to use one
-
Drivers being too bothered to register their bank account information
Approach
-
Convinced the local business team to partner with LINE Pay (LINE messenger's payment service) to use it as the mobile payment solution to pay and receive payment from drivers (the local team initially opposed the idea due to internal issues).
-
Negotiated a solution with LINE Pay to register drivers automatically to LINE Pay upon approval on our platform with the drivers' LINE messenger ID (LINE is the dominant messenger used by most smartphone users in Thailand).
-
Provided shortcuts to key LINE Pay functions and help content relevant to drivers on our platform through the driver app.
Released designs of LINE Pay related pages in the driver app
Other
-
Negotiated with the UI team to modify the designs to make them flexible enough to fit in smaller screens
-
Supported creating a LINE messenger official account as an additional communication channel for the operation team to communicate with drivers and provide incentive and help content.
-
Defined requirements to make certain labels and functions modifiable via the backend to make the interface flexible for change after going live.
Prototype of Main Flow
You can see the major flows of the driver app in the following prototype video made with principle. You can view the deposit coupon feature, going on-duty, accepting a trip request, and completing a trip in the video.
Backend System Design
I was also responsible for defining the requirements of major parts of the backend system for the taxi platform. These tasks ranged from defining in-app analytics to financial reporting requirements. The following are some of the more memorable ones.
Trip Assignment Algorithm
We had to create a trip assignment algorithm to distribute trip requests to drivers based on their geographic location, with a distribution radius that increased as time progressed. However, due to the lack of experience the team had in developing trip assignment algorithms and the lack of driver data (since we were making a new service), I asked to create a trip assignment algorithm that started simple but could be modified in the backend as we aggregated real service data.
For the initial release version, since the trip assignment system needed to work for the operation team, the drivers and the engineers, I had to step in to understand their requirements and define the initial specs to satisfy all parties as much as possible for the release version. After a lot of back and forth communication and changes made during the testing period, with the help of the server engineer in charge, we were able to make the system flexible and later modify the variables of the algorithm to increase the driver and rider match rate.
Registration Verification Admin
One of the most important features of the driver app was the registration process, and since I was responsible for defining the information that needed to be submitted with the local operation team, I also had to define the validation rules and methods for the registration process. Some of the information could be automatically verified (e.g. phone number), however, many of the information had to be visually checked through the submitted photos by the operation staff with further checks conducted with the taxi unions and the department of land and transport.
Managing this task made me more knowledgeable of the limits of certain validation rules and how additional checks and methods may be necessary, including the use of human operation resources, to be thorough with getting the correct registration information.
Driver Related Finances
The negotiation process of the business model was managed by the operation and business development managers with the related stakeholders. However, many details necessary to design the product were not being defined, including the financial transactions occurring between the driver and our platform (i.e. fees, wallet topup)
Running short on time for development, I defined the flow of financial transactions and the product requirements based on the already discussed conditions, discussed with the relevant stakeholders and LINE Pay team, and modified the details as necessary to confirm the method to process the transactions and report them to our partners.
Diagram of flow of financial transactions between parties
Outcome
Phased Release with Driver Acquisition
The driver app was released in Aug 2017 with only the registration process to start early-bird registrations for the alpha and beta testing period, as driver recruitment was a top priority. However, the testing period was extended to continue driver acquisition before the official launch with the rider app. During the extended testing period, additional fixes were made while I focused on designing the backend and operation systems, a behemoth that took a lot of time to define its requirements with engineers.
1 Million Trips in 5 Months!
In March 2018, the rider app was launched as a public beta test and later promoted with mass online and offline marketing for the official release in May 2018. After the release, various operation issues ranging from abusive drivers to certain users canceling hundreds of trips a day had to be addressed as we operated the service.
However, the good news was that the service exceeded internal targets by more than 10% and demonstrated continued organic growth. After I left the team, within 5 months of the official release, the team celebrated a total of 1 million completed trips, a monumental feat that I was so proud of for the team as we all poured our sweat and tears to make the service possible.
Driver App Tutorial Video
Reflection
Although the service was successful in gaining a lot of user traction and growth, it was unfortunate that the release had to be so hurried without a strong operation system or onboarding experience. There were also compatibility issues with certain smaller low-end devices, leading to driver complaints and development resources being expended to support incompatible devices. The operation team later partnered with a telecommunications company to provide free phones to drivers.
"Satisfied drivers are pivotal in creating
a reliable service for riders"
During the design process, I learned that creating a stable pool of satisfied drivers was pivotal in creating a reliable service for users, leading to a shift in my priorities towards making the driver experience better. However, despite the stressful conditions, I enjoyed the challenge of designing the user experience and backend system of an entire taxi platform and became appreciative of all the drivers who were engaging without our platform and making it possible.