Company
Lalamove
Duration
Feb – Mar 2022
Role
I led all design activities as the lead Product Designer
Teams collaborated with
Product, User Research, Engineering
Lalamove focused on on-demand delivery services in different markets. To grow the business widely, we also provided other services to serve different users’ needs (e.g., express delivery, purchase service, moving service, intercity delivery). However, due to the old structure of the system, we only offered a generic order placing flow for all use cases. We often received user feedback about miscommunication with drivers during the delivery due to limited order information, which led to potential order cancellation.
Goals
Our goal for the project was to increase the scalability and flexibility of the order placing flow. We knew it was a long journey to modularize the entire flow for different services. Our objective was to create a foundation that embraced a rapidly evolving business and more diverse user base.
Our high-level goals were to:
- Increase service exposure
- Provide an entry point for users to enter other flows without any triggers
My role
As the sole designer in the project, I worked with a PM, a User Researcher, and a team of mobile engineers to discover design opportunities, align with stakeholders, determine the feasibility of the solution and check the UI after frontend development.
Research
To define what services to offer with a new order placing experience, our User Researcher conducted user interviews before I started working on the design. We found 2 main insights:
- While express delivery could be done by specifying the delivery time in the order, intercity delivery could only be served by specific vehicles. Based on the current structure and the mental modal of our existing users, modularizing services in distance dimensions (local and intercity) was likely the safest to start with.
- Sub-dimension services(moving service, food delivery) should be offered to both local and intercity deliveries as they share overlaps.
Existing flow
When we reviewed the home page, we found 2 main issues:
Low exposure
Due to the structure of the system, vehicles were enabled by the specific service areas. If a user wanted to place an intercity order, he needed to select a specific intercity vehicle.
Even though intercity delivery had become the focus since 2021, intercity vehicles were always deprioritised because of low usage. Also, based on data, we found that most of our users had a very consistent delivery pattern. Since the recently used vehicle type was selected by default on the home page to help reduce users’ effort when placing an order, they rarely scrolled down to browse other available vehicles. We suspected that even though this logic smoothened the order placing experience, it might also lead to low exposure to intercity delivery service.
Since first-time users needed to fill in all information on the home page, they also needed to check out the vehicles to decide the suitable one for the delivery. Even though they took more effort compared to existing users, they had a higher chance of discovering the deprioritised vehicles.
Low flexibility of the order placing flow
We had the same order placing flow on the app from the beginning of the business. To meet the user needs of different vehicles, we provided specific additional services for the vehicles to help users customise their delivery needs. When we started focusing on intercity delivery, we noticed particular user needs that additional services could not address. Users tended to have more requirements(e.g., delivery time), and drivers also wanted more details(e.g., size of the delivery items) when it came to intercity deliveries. From the product perspective, we envisioned a more flexible order placing experience, which could help us expand different services in a scalable manner. Users could also have a custom-made experience of each service.
High-level directions and deliverables
Our high-level directions were to
- Tailor-make the order placing flow for specific services, and
- Increase exposure to other services we offer
It is a long journey to modularise the entire order placing flow for different services. As a starting point, we wanted to make minimal changes to the flow to test the idea out. In phase 1, we
- Separated Local and Intercity delivery services on the home page
- Provided an entry point for users to enter the intercity flow without any triggers (e.g., selecting an intercity vehicle type)
- Only focused on the home page to make sure we could get more data and feedback before the next iteration
Constraint
There were a couple of constraints of the projects that I needed to keep in mind:
Back in 2020, we explored showing vehicle selection on the second page to filter the suitable vehicles based on the input on the first page. Unfortunately, this idea was against the company’s value proposition – “show customers our ability to deliver almost anything, large and small, through the variety of different service/vehicle types we offer.” To align with the business, we needed to make the vehicle selection always visible on the first page to let users discover it without any input.
Design Execution
Explorations
In the beginning, I explored different options to see how to increase the flexibility, scalability, and service discoverability on the home page.
I came up with 4 ideas. During discussions with PMs, we considered not only the 3 main criteria but also the corresponding tech and design development effort.
We found 2 potential ideas among all of them.
Potential idea A: Displayed services with vehicles at the bottom as an entry point
In this design, users would select the service they needed to enter the specific order placing flow. They could check out the descriptions if they were unsure which service to choose. By showing the services on the first page, users could focus on all the available options before entering the flow. We could also change the ordering based on usage and newly launched services to increase discoverability.
By showing all the available services on an individual page, we could expand the page without worrying about scalability when we introduce new services in the future.
Since we needed to keep the extensive list of vehicles on the first page on principle, vehicles remained fixed at the bottom of this page. Even when there were more services on the page, users could view all the vehicles by tapping the vehicles section at the bottom. With this approach, we could rearrange vehicle selection in the order placing flow to enhance the scalability further.
The service cards were not the only entry points to the place order flow but also the vehicles on the bottom sheet. With this design, we could collect data to see if users focused on the types of service or the variety of vehicles we offered.
Potential idea B: Added tabs on the home page
In this design, only tabs were added to the existing home page with a modified banner carousel. By using tabs, users could see the available services without going through extra steps. Since most of the orders were local delivery, the “Local” tab was the active tab by default. This design would not bring a drastic change to our main users while the discoverability of other services was improved.
Users could also view the corresponding vehicles under the tabs without entering the addresses.
Even though idea A offered high scalability than B, product managers and I both agreed that B was the direction to go.
When we were comparing the potential ideas, we focused on:
- Scalability - Among these 2 designs, idea A allowed us to rearrange the vehicle selection which offered higher flexibility to other services in the future compared to B. Yet the product team didn’t have a very clear picture of launching a new service at that moment. Scalability was not the most critical concern at the moment.
- User behavior - Idea A required all users to go through the additional page before entering the flow, while idea B did not. It was a big concern for idea A since we had more than 95% of users placing local orders most of the time. The extra tap to enter the flow would affect most of the users without adding any value to them.
- Development effort - Idea A relatively costed more tech effort compared to B. Since our product principle is to “Build fast, learn fast and create value”, idea B was a quick idea to find out if the user behavior on the home page changed and the impact on the order placing flow before the next iteration.
Tabs position
“Where should we place the tabs?”
It was pretty natural to show tabs under the top app bar. We could also provide different banner content for the related services and reduce tech effort by keeping the current banner carousel. But users might miss the tabs since they had gotten used to the idea that there were things on screens that were less relevant. They tended to look at the center of the screen and avoided the edges.
We decided to put the tabs above the address input card. The address input card was always the element users interacted with in the order placing flow. Showing the tabs nearby would be easier for users to discover them.
Switching logic
After separating services into 2 tabs, we expected some unhappy flows to occur in the order placing flow.
Auto switch from Local to Intercity
Since existing users were familiar with our current design, they might try to place an order under the wrong tab. It led to an error that blocked users from proceeding to the next step because of an incorrect vehicle type. To reduce all possible blockers that occurred by the tab, we implemented a logic to help users switch to the corresponding service automatically based on the address input.
If the user entered an address located in another city as the drop-off location under the local tab, when he returned to the home page, switching logic was triggered. We transferred address input and pick-up time to the intercity tab automatically and showed a snackbar to inform users about that.
User testing
We conducted user testing with 8 new users and 7 existing users in different markets in 10 days to ensure we were on the right path. From the testing, we wanted to know:
- To what extent did users notice the services displayed on the tabs?
- To what extent did users understand the flow of the updated design?
The Product Manager and I drafted a set of user testing questions and decided on the participant profile based on these 2 research questions, which were then reviewed by the researchers before setting up on usertesting.com. (view user testing preparation doc here)
I prepared 2 prototypes to help users experience the switching logics between local and intercity services. There were 3 tasks in total to discover learnability, task effectiveness, and task efficiency. We got a positive result in general:
- Users found that the interface is “clean” and “straightforward”
- The module picker is easily noticeable to the users
- Users found it useful to separate the service by use-cases
- Users liked the auto-switched for convenience. It helped them to understand that the module was changing
Success metrics
In this project, we mainly focused on metrics related to discoverability and impact on order placing conversion:
- Compared to the old design, how did it impact the order placing conversion?
- % of users switching to the corresponding tabs manually and relying on the switching logic
Did the design affect the completion time on the first page?
During the user testing, we found that more than half of the users liked the switching, which helped them complete the tasks. We wanted to know would users in real life also rely on the logic or switch to the right tab at the beginning. Since this switching logic only worked with these two specific services, this data would provide more insight into how we should handle other similar situations when we launch new services in the future.