Six storefronts, one system

Six shops ran on shared Bitrix/Aspro infrastructure. Roof-rack sold car roof boxes and racks. Another was an official Husqvarna dealer. Others carried WORX and Greenworks tools and garden equipment. One company, one codebase, six businesses that had nothing to do with each other from a customer’s point of view.

The obvious approach is one template with a colour variable per shop. It survives about a week. These were not skins of the same store: an official dealer inherits a manufacturer’s global identity it has no right to modify, a roof-rack shop competes on whether the thing fits your car, and a tool shop competes on price and campaign. Force them into one expression and every shop is slightly wrong.

So the split had to be made deliberately, and the line I drew was between structure and expression. Shared: page types, catalogue behaviour, product-card anatomy, form patterns, checkout, content templates. Owned by each shop: palette, typography, imagery, tone, and the weight given to navigation.

The clearest proof of why that line matters is the two homepages. Roof-rack opens with a black fitment band across the full width, above everything else, because the first question a visitor has is will this fit my car. The Husqvarna site opens with a persistent category rail down the left — blowers, mowers, cultivators, riders, scarifiers — because the first question there is which machine do I need. Same infrastructure, opposite first question, opposite homepage. Neither would work on the other site.

Four years later I would call this design governance. At the time I called it deciding who gets to change what, wrote it down, and enforced it in review.

Customers arrive knowing their car, not a part number. So the roof-rack shop needed to run make → model → body type and return only what actually fits — and it had to do it inside Bitrix’s native catalog API, because there was no budget for a custom backend and no appetite for maintaining one.

That constraint decided the interaction rather than limiting it. Each step is populated from the answer before it, so an invalid combination is never offered in the first place. There is no validation message, because there is nothing to invalidate: you cannot select a model the make does not have. Prevention instead of correction is cheaper for the customer and, as it happens, much cheaper to build on a platform that was never designed for fitment logic.

On mobile it becomes progressive disclosure, one decision per screen. On desktop the three selects sit in a single band on the homepage, above the promotional slider — not in a sidebar, not one level down in a category. The most important question a visitor has should be answerable before they scroll.

Twenty-five thousand products across six shops means the homepage is a scarce resource being spent on assumptions. Yandex.Metrica and Google Analytics click and funnel data showed several modules occupying prime space that almost nobody used, while the paths that actually converted were below the fold or two clicks deep. We re-routed the traffic accordingly.

It is a small thing to describe and it was the first time I understood that taste is not a substitute for looking. I had opinions about that homepage. The heatmap did not care about them.

Earlier, as web designer, a mobile-first rebuild of the key landing and product pages moved mobile conversion up by roughly a quarter and brought bounce rate down about four points. Both measured in Metrica and GA at the time. I have flagged them as approximate above, because I cannot re-open the baseline to check.

Email, banners, homepage sliders and social ran on the same structure-versus-expression split as the storefronts. A product block in a WORX blower campaign carries the same anatomy as a catalogue card — image, full product name with the specification that matters, price, one action — so somebody arriving from an email lands somewhere that already looks familiar.

During the earlier stretch I rebuilt the email template system across five sites under a new visual direction. In retrospect that is where the Finuslugi work began: it was the first time I understood that the constraints of a medium are the design brief rather than an obstacle to it, and that an email is a system problem wearing a graphic-design costume.

Three junior designers and a rotation of external contractors briefed from concept to delivery. I set up a design review process and shared component standards, largely so the answer to “is this right?” stopped being “ask Liubov”. Two product launches and a full rebrand across six projects came out of that arrangement.

Here is what I would do differently, and it is the most useful thing this project taught me. The system lived in shared files and in my head. It was real, it was consistent, and it was undocumented — so it depended on me being available to arbitrate. That worked for four years and it is precisely the definition of a system that is not finished.

It is why the first thing I built at Finuslugi was a block library with usage rules attached, before anyone asked for one, and why that library survived two rebrands and my own absence from any given campaign. I learned that here, by being the single point of failure for a while.