Providing a cheaper delivery service in response to a slowdown in the global economy by 2023.

According to International Monetary Fund, global growth is forecast to slow from 6% in 2021 to 3.2% in 2022 and 2.7% in 2023. This is the weakest growth profile since 2001 except for the global financial crisis and the acute phase of the COVID-19 pandemic. Due to the expected global economic slowdown in the upcoming years, Lalamove looked for new opportunities to target price-sensitive users to grow the business.

Background

With Lalamove, users could place point-to-point orders to deliver their parcels whenever they wanted. The high flexibility of the dedicated delivery service helped obtain users, especially SMEs with unique delivery needs in different markets.

Since the economy was deteriorating, Lalamove planned to grow its business with new strategies. For 2023, one of Lalamove's main strategies was to offer a cheaper delivery service called Bundle to increase its order volume and compete with its competitors. Cannibalisation was not a concern at the moment.

What is Bundle?

• Users can place orders before the cut-off time a day before at a cheaper price.
• After the cut-off time, the operation team pools Bundle orders into big multi-stop orders and optimise the route manually. The team dispatches the multi-stop orders to drivers, so one driver can handle multiple orders at the same time in the shortest time and distance.
• All parcels will be picked up and delivered the next day.

Timeline and deliverables

To ensure the service could be released in early 2023 to address the upcoming economic challenge, we started to build an MVP at the end of 2022 Q3 and targeted to finish the development within 2022 Q4.

The whole project was separated into 2 phases on the design side:

1. Core flow to place Bundle orders
2. Post order flow for order tracking

We planned to spend 3 weeks for each phase. To ensure all the stakeholders were on the same page and to reduce the extra time for tech investigation after the design handover, there were at least 3 meetings per week for feedback and discussions.

Target users

We suspected that not all of the users need instant delivery. Based on our past research findings, some of the users preferred delivery just on time(delivery within the same day or x hours service-level agreements) but at a cheaper price. Hence, we targeted users who were both price-sensitive and non-time-sensitive.

Objectives

• We’ll offer a cheaper delivery service called Bundle to both personal and business users in 2023.
• Hong Kong was the first market we planned to roll out in the first phase. We aimed to launch a pilot test within some selected districts in Hong Kong in Q1 2023 as a start. Both quantitative and qualitative research will begin after this delivery service is released.
• To ensure the new service was under control, the service area was limited to 2 main downtown areas in Hong Kong.
• We only focused on the demand in the first phase to help users place Bundle orders on the mobile app.

Success Metrics

High-level metrics were defined before the project started.

Major metrics

1. Increase in Total TV
2. Increase in FTU who have placed orders

Secondary metrics

1. Number of Bundle orders placed
2. TV generated from Bundle orders
3. No. of Bundle users
4. Maintain normal orders TV
5. Extra fees settled by Lalamove
6. Cancellation rate of Bundle orders/
7. % of failed delivery
8. Driver supply vs demand

User research

Unfortunately, user research was not included due to the limited development time of the project. Even though user testing was not part of the design process, we planned to roll it out in Hong Kong first as a pilot test.

We will collect data and conduct user research after the service is released. In order to improve Bundle in its next phases, we sought to identify pain points in the user journey after release.

Competitor analysis

My first step was to analyze the features of my competitors to identify opportunities. To better understand what the competitors were doing in our main markets, I decided to focus on the delivery applications in South East Asia and Hong Kong.

Based on my analysis of competing products, I learned that those products offered customers flexible time windows by providing different delivery options. However, I also noticed that the amount of information required during the order-placing process was extensive. This could lead to frustration among users, and given that one of our company's main metrics was the success rate and time spent on placing orders, it was clear that we needed to strike a balance between order clarity and speed.

Design

High-level directions

• This delivery service should be discoverable and easy to access on the Home page.
• To help users decide which service to select, the product value proposition of the service and its limitations needed to be visible to ensure users had enough information to make decisions.
• Allowed users to return(/guide users back) to the original flow if Bundle was unable to fulfill the requirements, so users could still place orders on the Lalamove app to prevent potential loss from Bundle.
• Since the Bundle flow was different from the existing flow, guidance should be included to help users provide the essential information to place Bundle orders.
• Avoided unnecessary changes to limit the tech effort so that we could release on time.

Flow overview

Before checking out the flow for Bundle, let’s take a look at the existing flow.

A few highlights of the existing flow:

1. There were 2 pages in total.
2. In the whole flow, only pick-up and drop-off addresses, and vehicle selection on the Home page were mandatory. Fields on Add More Details page were either optional or prefilled once the user placed the first order.
3. To reduce offline communication between customers and drivers in the journey, we enabled customers to add delivery item details in the order placing flow. While we encouraged users to do so, this field was optional to maintain flexibility and save customers time when they were in a hurry.

Let’s look at the Bundle flow.

Several highlights of the Bundle flow:

1. There were 3 pages in total.
2. Users needed to enter pick-up and drop-off addresses, and delivery item details to place a Bundle order.
3. The pick-up time and delivery time were fixed. All Bundle orders started the next day.
4. To optimise the Bundle order handling process on the driver side, we only supported small item delivery. Customers could not select which vehicle to handle their order.

Service discovery

The business direction changed in the design process. As part of our initial plan, we wanted to introduce the service to new users and a small number of existing users to prevent cannibalization and loss of gross transaction value. During the final week of development, the company decided to "proudly" introduce the service to Hong Kong users to improve competitiveness.

Here are two versions of the solutions: the initial and final designs.

Entry point

Initial design

On the existing Home page, the pick-up time was set as Now by default. Users could tap on the “Now” button to change the pick-up time.

Based on the existing data, we notice that nearly 90% of the orders were requested to pick up immediately. We suspected that since 10% of orders were placed as scheduled orders, the pick-up time bottom sheet would be a suitable entry point to introduce the “Bundle” service without affecting most of the orders.

✨ Final design

The goal changed based on the latest business decision. To ensure our users could find the Bundle service easily, we decided to change the “Now” button to a delivery type field above the pick-up location field to make the service concept stand out on the page. We named our existing service Standard, which was set as the default option on the page.

After tapping on the delivery type field, users would see a bottom sheet with 2 options: Standard and Bundle. We added captions on each card to show the value proposition of the services. To ensure users know Bundle orders always start the day after the order is placed, we also specified the date and time windows to set user expectations.

When I first designed option cards, I tried to reuse the existing card component to keep the design consistent. During the internal alignment meeting, the Head of Product raised a concern – how might we inform users of the Bundle conditions when they select the delivery type?

Unlike Standard orders, we limited the parcel size, weight and item type for Bundle to make sure drivers could handle multiple orders during the delivery. When users placed an order, they might be flexible on pick-up time and vehicle, but parcel size and type won’t change. Even though there were entry points to redirect users in the flow, we should prevent users from spending extra time and effort to reduce the possible drop-off rate.

I iterated the design with the problem statement in mind.

• A supplementary banner was added under the Bundle card to show the package conditions
• The banner expanded automatically if the user had never placed any Bundle orders. It collapsed after the first Bundle order is placed.

By displaying critical information upfront, users were aware of it before choosing the delivery type. The user could view it on the bottom sheet whenever he chose the service.

Onboarding

Initial design

Based on our original business strategy, we decided to display a tooltip when users opened the app to encourage them to discover the service themselves.

✨ Final design

To ensure our users could discover the service as soon as possible, the Delivery type bottom sheet appears automatically once the user opened the app the first time after release. When the bottom sheet was dismissed, a tooltip appeared above the delivery type field to show users the entry point.

Through the in-your-face approach, users were educated effectively with the essential information they needed. We could possibly encourage users to place an order because of the affordable option appearing on the screen.

Package Details page

In the Standard flow, delivery item details were optional information to provide. Since the goal of the page was to collect more information about the parcel, we asked users about the type, size and weight of the items, and handling instructions. Users could also upload a photo on the page. Given that it was voluntary, we believed that it won’t affect the drop-off rate even the page was long.

When I designed the flow for Bundle, I considered turning the page into the second step, adding a “mandatory” indicator and an informative banner to limit the development effort. We could also collect precise information from users by utilizing the existing page. However, even though there is only one mandatory field to fill in, the long page might lead users to think it takes more effort than it actually is.

I came up with a problem statement to help myself iterate based on this concern.

To ensure users can place an order smoothly without hesitation due to the effort required for the flow, I decided to prioritise the item size over other information on the page. As our primary concern was the item restrictions, we reminded users again on the page of the delivery item guideline.

On this page, users were only asked about the size of the package. Since some users might not be familiar with measuring sizes without tools, I added illustrations and descriptions to help them understand the options.

In case the user wanted to deliver a larger package, we also included an entry point under the options to navigate users back to the Standard delivery flow with the prefilled route to ensure the user could still place an order on the app even if Bundle was incapable of fulfilling the order.

Add More Details page

Add notes to driver

Unlike Standard delivery, the pick-up and drop-off time windows of Bundle were fixed and long. Since it was harder for users to predict when the driver would arrive, communication was important for both users and drivers to make a successful delivery.

In order to remind users to provide delivery instructions if the sender or the recipient was not around when the driver arrived, I added a banner under the “Add notes to driver” card.

Next steps

Metrics

To better measure the design for the iterations after, I defined some metrics to help us understand the user behaviours in the flow.

Orders related

• Order type(Standard, Bundle) of the first order after the release
• % of scheduled Standard order after the release

Since Bundle’s target users were time-insensitive but price sensitive, we wanted to find out if users would switch from placing a Standard order for later to Bundle due to its lower price.

• % of orders with notes-to-driver

General

• Time taken to place a Bundle order
• Time spent on each page
• Drop-off rate of each page

Onboarding

• How long did users stay on the bottom sheet?
• What actions did users take when they saw the bottom sheet?
• Dismissed the bottom sheet
• Selected Standard
• Selected Bundle

Considering that our existing users (who had already placed orders before) were familiar with the original flow, the metrics above would be divided by new and existing users to help us better understand the behaviours of each user group specifically.

Package Details page

• Time taken to select an option
• Accuracy of the selection

Given that there was no implementation done on the driver app, it requires manual analysis by comparing user selection and photos taken by drivers during delivery.

• % of users tapping on the redirection entry point
• Event tracking after redirection

Add More Details page

• Content of “Add notes to driver”

With the banner added under the "Add notes to driver" card, we were interested in learning what additional instructions or information users provided to guide drivers.

User research

For future iterations, we will also conduct user research based on the data. These are the high-level research angles I have defined:

1. Understanding of the service

Given that there are conditions(parcel restrictions, service area etc.) for using Bundle service, we wanted to know the following:

1. How users interpret the service
2. Do users read the package guidelines when they select the delivery type?
3. Do users need any additional information when selecting the delivery type?
2. Possible pain points of Bundle delivery (Placing order, order handling)

To better improve the flow in the future, we would also like to find out the pain points users have when using the Bundle service. It helps the Design and Product team to discover opportunities in the flow as well as in offline interactions between the operations, customers and drivers.

3. Preference between Bundle and scheduled Standard orders

After Bundle was released, we suspected that some users would still place scheduled Standard orders. As Bundle is a more affordable option for non-urgent deliveries, we wondered why users choose Standard over Bundle. Is it only because of the specific delivery needs or other concerns?

4. Understanding of package dimension

Since package size is a condition affecting drivers handling the delivery, it is crucial to understand whether users are able to select the correct size of the package. If data indicates that users choose the wrong option, research should be conducted to understand:

1. Do users understand the information shown on the page?
2. What actions do users take when selecting an option?
3. What other information do users need when selecting an option?

Reflection

Accept changes based on the product direction

In March 2022, we aimed to modularise the home page to form a scalable foundation for new services in the future. It took the whole quarter for the product and the tech team to build the feature. We envisioned using tabs to show the services on the home page for scalability and sustainability.

When we started this project, the whole team went straight to the tab approach. But when I started the ideation, I realised that it was not the ideal solution based on user mental modal and error handling. When I shared different ideas to the tech team, all of the tech leads preferred using tabs to reduce the development time and complexity. When I aligned with the Product stakeholders, I shared the designs with rationales and tech concerns to help them understand the situation. Fortunately the Head of Product agreed that even though we aimed to release as soon as possible, we should not sacrifice user experience due to development time.

It was a big takeaway for me. I was not confident in convincing the team to display the service in a different way because of the structure we envisioned half a year ago. After several discussions with the Head of Product, I understood that we should do what is best for the product even though the solution is different from what we expected initially.

If I had more time

Since we only had 3 weeks to work on the design, we were not able to conduct any user research before we started. If we had more time, I would suggest involving the research team to understand our target users so we could precisely define the value proposition.