First_Page.png

Uklon. Delivery service experience

Real-estate Web platform (user research and feature prioritization)

 

Uklon. Delivery service experience

 
 

Overview

Uklon is a ridesharing service that has been working in 16 cities of Ukraine since 2010. Uklon has the same business model as Uber which is also their main competitor in the Ukrainian market.

At the beginning of 2020 when the country was experiencing regular restrictions due to COVID-19 and the need for a local delivery has increased, the company decided to introduce the Delivery service to send parcels up to 20 kg using their app and drivers’ base. The company’s motto of those times was “Uklon – freedom to stay at home”.

 

My Role

I was a part of a design and research team of 5 that worked on a short-term project specifically aimed to evaluate and advise on experience strategy and design solution for the new Delivery service.

As a result of cooperation, Uklon took recommendations and implemented our improvement suggestions for the Delivery to the door feature later in 2020.

 

Understanding the Problem

We started working on the project with Uklon’s stakeholders in March 2020. At the same time, their product team has already launched a MVP of the Delivery feature, and among other goals, we needed to evaluate the new feature and suggest on its improvements. We had a meeting with a Product Manager, Business Analysts Team Lead, and UX Designer from Uklon to gather stakeholders’ requirements.
Uklon already had some questions they wanted us to dive deeper:

  1. Whether users perceive Uklon as a Delivery service or taxi only.

  2. What are the possible pain points or gaps in the local delivery experiences.

  3. How ‘small business’ deliver their goods and what specific needs they might have (small bakeries etc).

 

Beginning the Process

I proposed to start the process by eating a lot of cookies and, as a result, had an overview of how the local delivery currently works both for a sender and a receiver (we were trying Kyiv city).
We send a bunch of parcels to each other using both Uklon’s MVP feature and trying out competitor services to understand how they solve the same task.

We deliver parcels using both close competitors (Bolt - Estonian mobility company that operates in Ukraine; at that time Uber did not have a delivery option in Ukraine and UberEats worked only with restaurants) and companies that have delivery as their primary option (Nova Poshta, Ukrposhta).

This experience showed us possible gaps that users might experience that we would want to focus more precisely during interviews:
Lack of tracking. All the communication between sender and receiver is happening in outer messengers (Facebook, Whatsapp etc.), such as delivery status, time of delivery, driver’s phone number, car model, plate’s number.
Delivery limitation. Only delivery to the building option, no opportunity to deliver to the apartment/office doors (can cause a problem when a person is sick, busy etc.)
Adding information about the receiver. Though in Uklon you can order a taxi for someone else by choosing person’s number directly from your phone book, in Delivery option the only way to leave any information is to write a comment for the driver.

In addition to that, we did the competitor teardowns to look into their feature depths and functionality to identify what Uklon currently lacks compared to close competitors and where Uklon has a comparative advantage and where the opportunity lies.

Competitor analysis

 

Interviewing users

After gathering our own findings and finalizing competitor teardown, we created a screener to recruit users who recently had delivery experience and mentioned Uklon in the list of companies. We also were looking for both users who receive deliveries and senders who represent ‘small business‘.

We facilitated 10 1-hour interviews and after gathering our results, we started synthesis by grouping similar items and creating categories for each of them, we also added findings from competitor teardown.

Affinity Mapping

While doing categorization, we indicated whether the user was an individual or ‘small business‘ type to see if they have different pain points.

Overall, user interviews confirmed our hypotheses and that for both individuals and businesses key needs were:

— understand when the parcel will be received
— understand where the parcel is now (both receiver and sender) (“I like using tracking option to understand what is happening to my goods and where is the courier”, “When he told me the parcel was sent, he messages me - the driver has gone, and I’m messaging after some time - where is he? what should I do?”)
provide information about the receiver (for sender)
— delivery to door option (“I want to provide good service for my clients and deliver a birthday cake with the courier to their door”)
transparent price calculation, understand what’s included in the price etc.

There were several key differences and specific pain points for local businesses:

— goods delivery to multiple addresses
— importance to choose drivers based on ratings (while regular users do not care who delivers parcels they send, for small businesses it was important to choose the driver based on the rating as the delivery was an important part of their client service)
— the ability to deliver different types of goods (large cakes, fragile objects etc)

While working with user needs, it became clear that reusing the taxi driving model as a delivery option is not optimal.

Users often indicate that they use taxi service for delivery when they need to send either something ASAP or perishable food items. Otherwise, they will use companies that have delivery as their primary service (Nova Poshta, Ukrposhta).

During our analysis, we also saw many people perceived taxi services as untrustworthy delivery service —“There is a credit of distrust, whether my parcel arrives, it's a taxi driver and his role is not in delivering parcels - somewhere on a psychological level you perceive that couriers are more responsible”.

As a Delivery option MVP was already launched as a part of Uklon’s ridesharing app, we split our suggestion into short- and long-term solutions. Short-term solutions focused on improving an existing experience, and a long-term solution proposed to have a Delivery as a separate app experience.

As a group, we prioritized needs that we revealed during our synthesis for current experience improvement based on perceived user value and moved on to create design concepts that addressed those areas for further testing.

 

Prototyping & Testing

We mapped out the current end-to-end flow focusing on improving senders’ experience within it as it was a business priority. We specifically addressed gaps that were discovered at the previous research phase: adding recipient’s information, delivery to door option, delivery to multiple addresses, choose driver based on his rating, transparent delivery services calculation.

Uklon’s Delivery service work flow

Before going into prototyping, we created several low-fi versions to work on some concept realization, including delivery to multiple addresses.

‘Delivery to the door’ iteration

Once we were aligned with the solution, we moved to the prototype phase. I was specifically working on including Recipients’ details and the Delivery to the door feature as shown below.

In the first iteration tested my solution was to add the “Delivery to door” option to the existing “Wishes” category currently used by users to write comments for the driver indicating any specific requests around the delivery such as careful driving, fragile goods, airconditioned car etc.

We did two separate rounds of testing - for the usual scenario to deliver a parcel to one address and to test multiple addresses scenario (10 people in total). Then we created a table with all the steps in our prototype indicating the rate of completion as well as insights and quotes from users.

User Testing results

After the first round of testing, however, we got feedback that users were expecting to add the Delivery to door type as a part of a flow where they added the recipient’s address information. As a result, I changed my prototype for the second round of testing and added the ‘Delivery to the door’ step to the Recipient’s main information. This approach was validated during the second testing round (you can see the second iteration in the video below).

 

Recommendations

Existing App Improvements
Based on our recommendation, Uklon has implemented the following improvements to the existing app. They put all the important data for the driver in the recipient section - both recipient’s personal details needed to contact (Name, phone number) and address delivery specifications - ‘Address delivery’ or ‘Delivery to door’ option.

Our long-term recommendations
Also, a part of our deliverables were some long-term recommendations that we based on overall testing feedback:

  • Reusing the existing ridesharing app for the delivery purposes won’t cover all needs (testing multiple addresses showed that users were worried they could easily make a mistake - “I’m worried I can send the parcel to the wrong person”).

  • The existing app allowed to choose the driver based on rating, but testing rounds showed that this information is not enough to help make a better choice compared to the usual delivery services where you can choose the courier based on feedback etc.