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

Metrics

We planned to track how many sellers would onboard and retain active storefronts over time, and how that would contribute to overall GMV (Gross Merchandise Value) growth and engagement within the platform. On the operational side, we aimed to measure time-to-launch and cost-per-storefront to understand scalability and potential ROI compared to our manual CMS setup. We also included qualitative metrics: seller satisfaction and support ticket volume to capture how the new experience actually felt for users, not just how it performed.

Research

I started with a benchmarking study, looking at how other platforms approached storefront customization, from Ozon and Aliexpress to Tilda, Readymag, Framer, and our own internal CMS flows. I also reviewed personal websites of our sellers to see how they presented their products outside Yandex.Market. I noticed repeating patterns: a hero banner paired with product cards featuring infographics, and product shelves grouped by themes, like promotions, bestsellers, or curated categories.

To understand the ‘why’ behind those choices, I talked to several sellers about what jobs their websites were doing for them: how they attracted customers, what worked well on competitor platforms, and what was missing from ours.

Then I deep-dived into our internal CMS. It’s a massive system, so I audited its existing components and limitations to confirm whether we could use it as the engine for a scalable, self-service builder.

The research gave me three key insights:

1. What the standard experience looks like in modern storefront builders, both in B2C and B2B so we could reuse familiar patterns and reduce the learning curve.
2. Which content blocks sellers use most often, defining our bare minimum feature set: a large promo banner, product carousels for discounts or campaigns, a popular categories carousel, and a banner carousel linking to product collections.
3. A clear picture of our technical constraints and opportunities, confirming that our existing CMS already supported all the components sellers cared about.

This validation was crucial. It meant we didn’t need to reinvent the wheel and could build a powerful self-service tool on top of what we already had.

IA structure

I worked closely with development team and stakeholders and presented first version of IA, using our existing CMS as the backend (since it already supported all the necessary components) and publishing directly to the Partner app though Microservice or UI storefront builder. Everything was going smoothly until I got the feedback that the real bottleneck wasn’t design or tech. It was moderation.


We couldn’t afford a dedicated content team at that time, as we were aiming to build an affordable solution for our SME partners, and AI wasn’t an option yet.

So... What could I do?

IA moderation ia-moderation-updates

That’s when I came up with the idea to use Toloka (Yandex’s own micro-task crowdsourcing platform, similar to MTurk) to create a lean, human-in-the-loop moderation engine.

I designed the entire moderation architecture around few components:

• The microservice acted as the orchestrator, wrapping our CMS with UI components and managing moderation requests.
• Sellers built storefronts through a simplified UI of Storefront Builder.
• Visual content was sent to Toloka for moderation before going live.

After confirming with the dev team that the idea was technically feasible and getting the green light from management, I started preparing a training kit for moderators.

Data & training

To train Toloka moderators, I built a dataset of around 200 banner examples: 100 ‘approved’ and 100 ‘rejected’, working with the team to simulate realistic violations like illegal content or misleading offers.

At some point, I started to run out of ideas, so I pulled some ‘good’ examples from our real B2C Figma files and asked the team to help brainstorm ideas for the ‘bad’ ones. It actually turned into a fun team-building activity!

We also saw success where we didn’t expect it. 
I initially estimated that moderating each storefront would take around 4 hours (based on similar image-checking tasks), but the real results showed it took only 10 minutes on average before being released to production.

Design

I wanted the storefront builder to feel instantly familiar: something sellers could start using without training. After analyzing best practices from tools like Webflow, Shopify, and our internal CMS, I designed a lightweight WYSIWYG editor with a clear structure: a simple control header for key actions and an interactive workspace where sellers could see changes in real time.

The builder used our existing CMS blocks as the foundation so sellers could assemble pages visually while the system generated a JSON configuration behind the scenes, sending it directly to our CMS and creating a moderation task automatically.

Throughout the design process, I collaborated closely with engineers to validate every interaction: from how requests were triggered to how long processing took. This helped shape key UX decisions, like if we need show the ‘Save’ button, what to display during loading, and how to handle connection drops gracefully. I also worked with other designers to ensure visual and interaction consistency across the ecosystem, and with PMs to make sure the flow aligned with company OKRs and Yandex mission of ‘helping you solve your problems and reach your goals’.

We ran around a dozen quick usability sessions with sellers to confirm the concept. The feedback was mostly positive with the only request was to add short description for each block, which I implemented before launch. One seller even asked, ‘Are you going to raise our fees now that it looks this good?’

It was a small moment, but it captured exactly what I aimed for: a product that felt powerful, reliable, and surprisingly simple to use.

Business impact