Admin Panel Unification · Apteka.ru
The company's first internal product, grown to 9 sections and 40+ modules without a design system. I Led the unification: audited every pattern, introduced the design system, and rebuilt the product the team uses every day.
Scope
Design system initiator, architect & owner / Interface audit, pattern unification, quality control / Junior designer management
Client
Apteka.ru
Duration
Ongoing
2025
Context
The admin panel was the company's first internal product, built at a time when there was no design system, no established patterns, and no single owner responsible for the overall experience. Over the years it grew to 9 sections and 40+ modules, each added as the business needed it. Some features were shipped without designer involvement; others were built by different people at different moments with no shared reference point. The result was a product that had grown organically, not by design, but by accumulation. Every section followed its own logic. Basic visual principles (hierarchy, proximity, consistent use of colour) were applied unevenly at best. The product worked, but it was increasingly difficult to use and even more difficult to extend without making things worse.
There was a second, structural layer to the problem. Internal tools at Apteka.ru don't exist in isolation, features migrate between products. A module built for the admin panel might later be moved into the advertiser dashboard or the supplier portal. In practice, every such migration meant not just adapting the layout but manually replacing components with their counterparts from a completely different UI kit. The visual similarity between products was deceptive; under the hood, nothing was shared. Each move was slow, expensive, and prone to introducing new inconsistencies.
Building the design system
The migration problem was one of the core reasons I initiated the design system in the first place. The approach was to prove the concept before pitching it. The advertiser dashboard, a product being built from scratch at the time, became the pilot: I designed every atom and molecule to be universal from the start, with theming handled entirely through colour tokens so the same components could serve different products by simply switching a colour scheme. Then ran a second pilot on the staff mobile app admin panel and it was successful.
With two live examples in hand, I presented to the engineering lead and the team: here is the problem, here is what already exists, here is the rollout plan. They approved it. From there we built the full component library with frontend review at every step, established a contribution process for adding new components, launched an internal site where the whole company could access guidelines and interact with components directly, and tracked rollout progress with a component coverage map across all products.
The system covered 6 internal products over 6 months, running in parallel with regular product work rather than as a dedicated initiative. The clearest demonstration of what it made possible came when we needed to replace the authentication module across all products simultaneously: it took copy-paste and a mode switch. Zero per-product rework.
Once the system was in place, the admin panel became the natural next candidate: the oldest, most tangled product in the ecosystem, and the one with the most to gain from being brought into a shared visual language.
The work
We started with the highest-visibility surfaces, section landing pages, dashboards, data tables, where design system components could be applied immediately and the results would be visible to the whole team straight away. Getting these right quickly created a clear before/after and built confidence in the approach.
From there, we ran a systematic audit of the interior pages: form builders, entity creation flows, moderation interfaces, filter-heavy views. Everything was screenshotted and categorised, mapping every variant of every pattern that had quietly diverged over years. From that foundation, we designed unified patterns for each interaction category, tested them against the most structurally different examples we could find, presented to the team, validated through corridor tests, and refined. Then worked section by section through the full product, rebuilding each page with design system components. In practice, the detailed work surfaced things the model patterns hadn't anticipated, one example: we realised during implementation that the delete action worked better placed in the settings panel rather than inside the entity body. Small, but the kind of decision that only becomes visible at real scale.
The result
The product went from a self-built sprawl of one-off solutions to a coherent, maintainable system. New features can be designed and built against an established visual language rather than invented from scratch each time. Migrations between products, the problem that started all of this, now take a fraction of the time they used to. There are no headline metrics to point to here, but the qualitative shift was significant and visible to everyone who worked in the product every day.