Storefront Builder

Context

Yandex.Market is one of Russia’s largest e-com platforms, with over 18 million active buyers, 80,000 sellers, and more than 80 million SKUs.

At that time, only our largest enterprise clients could customize their shop pages, and those were built manually through a clunky internal CMS that no one wanted to touch.

But our research showed the demand was shifting:
1. Mid and small sized sellers were building their own brands and driving traffic to their own websites.
2. Competitors like Ozon and AliExpress had already started offering tools for SMEs to create branded storefronts.

We needed to act fast and to design a self-service solution for SMEs that was affordable, scalable, and kept sellers inside our ecosystem instead of losing them to external platforms.

Challenge

Initial metrics

Adoption — how many sellers would create and maintain active storefronts after launch, not just sign up and walk away.

Efficiency — time-to-launch and cost-per-storefront compared to the manual baseline. If this wasn't dramatically cheaper, the whole premise failed.

Engagement quality — seller retention and support escalation rate, to catch experience problems before they became platform trust problems.

GMV contribution was on the list but difficult to isolate cleanly given how storefront traffic overlaps with other acquisition channels. We tracked it directionally rather than as a primary KPI.

Research

I started with benchmarking across two tracks: competitive (Ozon, Wildberries, Tilda) and inspirational (Readymag, Framer, Shopify). I also looked at the external websites our sellers were already maintaining — the ones they’d built outside Yandex.Market — to understand what they considered a good storefront.

The pattern was consistent: hero banner, product carousels grouped by theme (discounts, bestsellers, curated collections), simple category navigation. Not surprising, but useful — it defined the non-negotiable blocks from the nice-to-haves.

Seller interviews followed, focused on one question: what job is your external website doing for you that Yandex.Market isn’t? The answers were consistent. Sellers wanted to tell a brand story, not just list products. First impressions mattered and they had no control over them.

Then I went into the internal CMS — a large, complex system — and audited what it actually supported. This turned out to be the most useful research I did. The CMS already had every component sellers cared about. I didn’t need to build new blocks from scratch. I needed to build a simpler interface on top of what already existed.

Three things came out of the research: what good looks like in modern storefront builders so we could reuse familiar patterns; which blocks to ship first; and confirmation that our existing CMS could serve as the backend, saving weeks of engineering work.

Constraint that affected design

I put together a first version of the IA — Storefront Builder as a simplified UI on top of our CMS, publishing through a microservice to the Partner app. Technically clean. Straightforward to build.

Then I got the feedback that stopped everything.

Moderation.

Any content sellers published needed review before going live — for illegal material, misleading offers, trademark violations. We had no dedicated content team. Hiring one would price the product out of the SME market we were building for. AI-based content moderation wasn't reliable enough at that point to trust unsupervised.

This wasn't a design problem. But it needed a design solution.

That's when I looked at Toloka — Yandex's own crowdsourcing platform for micro-tasks, similar to Amazon Mechanical Turk. If I could design the moderation workflow around Toloka, we'd get human-reviewed moderation at a fraction of the cost of a permanent team.

I redesigned the architecture around three components: the microservice as orchestrator, wrapping the CMS with UI components and routing moderation requests; the Storefront Builder as the simplified seller-facing editor; and Toloka handling visual content review before anything went live. I confirmed technical feasibility with the dev team, got management sign-off, and moved to the next problem.

I build the dataset to train crowdworkers

To train Toloka moderators, I built a dataset of ~200 banner examples: 100 approved, 100 rejected, covering realistic violations — misleading offers, illegal content, low-quality visuals. Approved examples came from our real B2C Figma files. The rejection cases we brainstormed as a team, which became an unexpectedly enjoyable session.

My estimate for moderation time was ~4 hours per storefront, based on comparable image-review tasks on the platform. The actual number: 10 minutes. The structured nature of the storefronts made review fast and consistent. Near-zero escalations reached support from sellers disputing moderation decisions — the error rate was low enough that it never became a tracked problem.

Zero full-time moderators hired.

Designed UI of storefront builder

The goal was a tool sellers could open and use without reading anything first. I designed a lightweight WYSIWYG editor: a control header for key actions, an interactive workspace with real-time preview. Sellers assembled pages visually; the system generated a JSON configuration behind the scenes, sent it to the CMS, and triggered a moderation task automatically.

Every interaction was validated with engineers before it became a design decision — what triggers a request, how long processing takes, what to show during loading, how to handle connection drops. These conversations shaped the UX in ways that desk research couldn't have.

I ran around a dozen usability sessions with sellers before launch. Feedback was largely positive. One consistent request: short descriptions for each content block. I added them. One seller, mid-session, asked: «Are you going to raise our fees now that it looks this good?»

That's the bar I was aiming for.

Results

15,000+ storefronts created in the first 1.5 months — roughly 19% of the active seller base at launch.

~80% of those sellers remained actively engaged with their storefront after launch, updating content or adjusting product shelves. Retention was measured broadly, but the signal was clear: sellers were coming back.

Moderation time: 10 minutes per storefront against a 4-hour estimate. Near-zero support escalations related to moderation errors.

Zero full-time content moderators hired — the Toloka model held.

What previously cost hundreds of thousands of rubles and a week of agency-style work now cost sellers nothing and took minutes. The economics of the old model made branded storefronts a luxury. This made them a default.

Peak storefront-driven GMV: 1.2M ₽ in a single day. 20,000 Shop-in-Shop DAU from seller ad traffic — validating that storefronts weren't just being built, they were being used to drive real commercial activity.

Takeaways

Next time, let the machine do the boring part. I built 200 moderation examples by hand — half approved, half rejected — brainstorming fake violations with the team like a very niche game show. It worked. It was also a terrible use of designer time. A generative model could do that in an afternoon now. I'd use it.

Design for the ecosystem on day one. Sellers were building moderated, ready-to-go banners inside the Builder. One obvious next step: push that same banner into Yandex.Direct, Search, Maps, 85M+ users. I saw it. I moved too slowly on pulling in the right teams, and the window closed. Cross-surface distribution belongs in the initial IA, not the roadmap backlog.

Templates beat blank canvas. My hunch: give sellers a pre-assembled layout instead of individual blocks, and creation time drops to two or three clicks. Adoption follows. I had the designs. The project was cut short before I could test it. I still think I was right — and the retention data would have told us within weeks.