Growth through experiments
Four features we shipped in the Perekrestok app, and one experiment we rolled back. The biggest result came from letting people add forgotten items to an order they had already placed.
Perekrestok
A large grocery chain in Russia, part of X5 Group. The app handles delivery and pickup for 5M+ people a month.
Product managers came with the hypotheses and were in charge of quarterly priorities and resources. My part was how we solved each problem, how we tested the design and when we needed to question the approach.
Adding forgotten items to an order
People cancelled orders because they had forgotten something. To add an item, they had to write to the support chat, which was slow and inconvenient.
We reused the catalog and cart. After placing an order, people could go back to the catalog, pick more products and tap “Add to order” in the cart. This made it simpler to build and kept the interface familiar.
Quick hallway tests with a prototype showed that people understood the flow. We also added onboarding on our own initiative, because most people wouldn’t expect to be able to change an order after placing it.
The screens show the first version we released, before the app’s redesign.
−15%
Cancellations in the first five minutes
−33%
Cancellations caused by forgotten items
Ready-to-eat food on the home screen
The business wanted to sell more ready-to-eat food. We tested whether showing these categories on the home screen would help people find them.
I designed this block myself. It followed the app’s principles, with the focus on food, a clear structure and calm colours. Getting a place on the first screen took more discussion than designing the block, because other teams wanted that space too.
+8%
Ready-to-eat add-to-cart, users who saw the block
Social proof where people choose a product
People weren’t sure about the quality of ready meals. We tested quality labels and purchase counts on the product page and in product lists.
We put a small block under the product name, right where people decide to buy. It had to be noticeable but not compete with the product itself.
+3–4%
Add-to-cart conversion, A/B test
+6%
Up to, for one particular label
A compact combo builder
The old combo offer was hard to use, because people had to find the products themselves. We made a builder where they could pick a set and see the deal, all in one place.
We tested a vertical list and a horizontal carousel. I liked the list more, because it was easier to compare products. The carousel kept the builder compact and the deal visible. The test showed no measurable difference, so we went with the carousel, which the product team preferred.
The builder shipped and became part of the ready-to-eat flow. I don’t have the exact results anymore, so I can’t give a number for it.
A separate scenario
The combo offer on the product page
The experiment we rolled back. We added a screen with categories between the Discounts entry and the discounted products. The idea was to help people narrow down the choice.
Conversion from the section dropped, and we rolled it back. People came to Discounts to browse what was on sale, and the extra choice got in their way.
Categories helped in the catalog, where people often knew what they were looking for. The same structure didn’t work when people just wanted to browse.
What I would change. I’d track results for longer after release and keep a log of all experiments. I’d also get involved earlier, while the hypotheses are still being discussed, so I can question an idea before the team starts building it.
Next case
Design System in code
I built components in code and set up how our team makes and reviews them.