Design leadership at Dostavista and Borzo

About 95% of orders were urgent: users needed a courier to pick up the order as quickly as possible. But the form was built around manually choosing a time for each address.

For new users, the interface did not clearly answer the main question: “How quickly can you deliver? ” We advertised an urgent delivery service, but to understand how to order one, users first had to work through the complex time‑selection logic. For existing users, these were unnecessary steps: in the most common scenario, they had to set the time manually every time.

We moved this choice to the top of the form and split the flow into “As soon as possible” and “Schedule”. For urgent delivery, users no longer had to set the time manually. We also moved secondary parameters, such as weight and vehicle type, into dropdowns.

After launch, we noticed that some users still chose “Schedule” for urgent orders. Interviews showed that selecting a time manually gave them a sense of control. This led to the next idea: showing a predicted delivery time so that the simpler flow would also give users confidence.

As the product became more complex, we introduced express delivery, slower and cheaper options, and delivery by a specific time. The form now had to do more than help users place an order: it also had to introduce them to new products.

Users needed to see every available option directly in the form, understand the differences, and choose the right one without separate landing pages, pop‑ups, or explanations. There was also a risk: the more products we added, the more complex the form would become.

We redesigned the pricing selector and foregrounded the factors that mattered for the choice: speed, time, and price. We also tested the names and descriptions of the delivery options: we gave users different scenarios and checked whether they chose the product designed for each scenario.

Users clearly distinguished between the delivery options and chose those that matched their scenarios. Overall conversion to order did not decline, even though the interface offered more choices.

The final major transformation was for India, where we had many more vehicle types: mopeds, rickshaws, and several kinds of trucks, each with different delivery speeds.

The old form no longer scaled. Vehicle type and delivery speed were mixed at the same level: options such as “within 4 hours” and “by truck” could appear side by side. This worked while there were only a few options. But as we added new trucks and rickshaws, users, especially new ones, began to get lost, and adding another option could reduce conversion to the first order.

Users in India also compared prices closely. For example, delivery within 4 hours could be about 40% cheaper than urgent delivery, but the old form required users to switch between options to see the difference.

We studied local patterns and found that users in India usually thought about vehicle type first: “I need a moped” or “I need a truck”. Only then did they decide how quickly the delivery needed to arrive. We therefore restructured the hierarchy: vehicle type became the first level and delivery speed the second. At the same time, we updated the backend to calculate prices for every available option for each order. Users could now compare them without additional switching.

The new solution was intended to make additional vehicle types and delivery options more visible and easier to understand, simplifying the journey for new users and increasing activity among existing customers. After launch, we tracked conversion from the first form opening to order creation, as well as the share of alternative options across all orders.

We had a highly diverse audience, from private customers to businesses with different delivery scenarios – flowers, documents, valuable items, and bulky parcels. The product already offered features for these needs: insurance, payment on delivery, waiting at the address, document return, loading, and unloading. But in the early stages of working on the product, we did not communicate these capabilities well to users.

Phrases such as “delivery for business” were too broad. Users still needed to understand: “Is this service right for my particular business? ” At the same time, we lacked information about new customers before their first orders. We needed it to analyze different segments and prioritize them for sales. We had already collected this data through a survey during registration, but to users it felt more like an extra step serving the company’s interests.

We combined the two tasks and turned onboarding into a personalized quiz. In a few steps, users told us what and how much they delivered and immediately saw relevant service features. For documents, these included waiting and return; for bulky items, loading and unloading. The quiz gave users a quick answer to the question “Is this product right for me? ” while giving us early customer segmentation.

Although this added a step to the funnel, we hypothesized that it would not create extra friction but would instead add clarity and reveal the product’s value sooner.

In an A/B test, conversion from app installation to the first order increased by 8% compared with the previous version. Qualitative research later confirmed this: some customers recalled selecting their business type during onboarding and seeing information relevant to it. About 35% of users skipped onboarding, so we still collected some of the data later. This remained a limitation of the solution.