Case stages
Select a stage to see details.
Product: a B2B white-label platform used to launch and manage multiple casino brands ("clients") from one shared foundation.
Each client needs its own visual identity and configuration — but the underlying product logic is largely the same. That gap between "must look different" and "should work the same way underneath" is the whole design problem this case is about.
Collaboration: Product Owners, Product Designers, Business Analysts, Front-end Architects, Developers and QA — organized as specialized roles with explicit handoffs rather than one generalist team.
My scope: discovery, product modelling, design-system architecture, responsive page composition, theme configuration, component contracts, and the design-to-development workflow connecting all of it.
A configurator already existed. Teams could customize individual parts of a casino product — navigation, hero banners, catalogues, VIP sections, tournaments, promotions — and preview the result before launch.
But that configuration was scattered across separate product sections and predefined, component-level settings. Scaling this to more clients needed a coherent system across pages, reusable widgets, themes, responsive behavior and versioned capabilities — not more of the same per-client tuning.
Продукт: B2B white-label платформа для запуска и управления несколькими казино-брендами («клиентами») на одной общей основе.
Каждому клиенту нужна своя визуальная идентичность и конфигурация — но продуктовая логика при этом во многом одинакова. Разрыв между «должно выглядеть по-разному» и «должно работать одинаково внутри» — и есть вся дизайн-задача этого кейса.
Коллаборация: Product Owner'ы, продуктовые дизайнеры, бизнес-аналитики, FE-архитекторы, разработчики и QA — как отдельные роли с явной передачей задач, а не одна универсальная команда.
Моя зона ответственности: discovery, продуктовое моделирование, архитектура дизайн-системы, адаптивная композиция страниц, настройка тем, контракты компонентов и весь workflow между дизайном и разработкой.
Конфигуратор уже существовал. Команды могли настраивать отдельные части казино-продукта — навигацию, hero-баннеры, каталоги, VIP-разделы, турниры, промо — и смотреть предпросмотр перед запуском.
Но эта настройка была разбросана по отдельным разделам продукта и предопределённым настройкам на уровне компонентов. Масштабирование на больше клиентов требовало цельной системы для страниц, переиспользуемых виджетов, тем, отзывчивого поведения и версионируемых возможностей — а не ещё больше точечных настроек под каждого клиента.
The company needed to support many visually distinct white-label products without maintaining a separate design and code path for every client.
The previous operating model created recurring, compounding issues:
The system could scale the number of clients. It was scaling the cost of maintaining them just as fast.
How might we give operators enough flexibility to create visually distinct products while preserving usability, responsiveness and system consistency?
Not only a UI-kit problem — it needed a shared product model connecting design tokens, reusable components, page composition, configuration schemas and versioning, treated as one system.
Компании нужно было поддерживать много визуально разных white-label продуктов без отдельного дизайн- и код-пути для каждого клиента.
Прежняя операционная модель создавала повторяющиеся, накапливающиеся проблемы:
Система могла масштабировать количество клиентов. Но она так же быстро масштабировала стоимость их поддержки.
Как дать операторам достаточно гибкости для визуально разных продуктов, сохранив юзабилити, отзывчивость и согласованность системы?
Это была не только задача UI-кита — требовалась общая продуктовая модель, связывающая токены, переиспользуемые компоненты, композицию страниц, схемы конфигурации и версионирование в одну систему.
Before proposing a direction, we traced the actual setup process end to end to separate genuine client differences from accidental ones. We reviewed:
Most client differences turned out to be expressible through five reusable layers rather than bespoke code:
A client is settings, not a separate codebase.
Прежде чем предлагать направление, мы проследили реальный процесс настройки от начала до конца, чтобы отделить настоящие различия клиентов от случайных. Мы изучили:
Большинство различий между клиентами можно было выразить через пять переиспользуемых слоёв, а не через отдельный код:
Клиент — это настройки, а не отдельная кодовая база.
The core hypothesis: if brand differences can be fully described through the five layers above, a shared template can replace per-client forks without losing the flexibility operators actually need. Broken into testable product principles:
Each of these was a bet to validate against real usage, not an assumption treated as settled on day one.
Основная гипотеза: если различия брендов можно полностью описать через пять слоёв выше, общий шаблон может заменить форки под каждого клиента без потери нужной операторам гибкости. Разложена на проверяемые принципы:
Каждый из этих пунктов был гипотезой, которую нужно было проверить на реальном использовании, а не допущением, принятым как данность с первого дня.
We shaped the system as four connected layers rather than one big configurator:
Keep the per-client fork model. Fast to start — but this was the status quo already producing N codebases and repeated manual fixes. It was the problem, not a solution.
Extend component-level settings only, without touching composition or tokens. Lower engineering lift, but couldn't address structural/visual divergence between brands.
Full configuration model across five layers — the only option addressing visual identity, page structure and safe upgrades together, instead of solving one and leaving the rest as future debt.
ML Constructor combined four areas: product navigation, a widget library, a responsive canvas, and a contextual inspector for parameters and design-system settings. Operators could create pages, add widgets, arrange them on a grid, configure content/variants/behavior, switch breakpoints, manage brand schemes, preview components live, and import/export configuration.
The design system needed to function as product infrastructure, not a static component library:
A component variant available in Figma corresponds to an implemented variant and an explicit, configurable parameter in the builder — not three separate, drifting sources of truth.
Систему выстроили как четыре связанных слоя, а не один большой конфигуратор:
Оставить модель форков под каждого клиента. Быстрый старт — но это и был status quo, уже дававший N кодовых баз и повторные ручные фиксы. Это была причина проблемы, а не решение.
Расширить только настройки на уровне компонентов, не трогая композицию и токены. Меньше инженерных усилий, но не решает структурное/визуальное расхождение между брендами.
Полная модель конфигурации из пяти слоёв — единственный вариант, решающий визуальную идентичность, структуру страниц и безопасные апдейты одновременно, а не по отдельности.
ML Constructor объединял четыре зоны: навигацию по продукту, библиотеку виджетов, отзывчивый canvas и контекстный инспектор параметров и настроек дизайн-системы. Операторы могли создавать страницы, добавлять виджеты, расставлять их по сетке, настраивать контент/варианты/поведение, переключать брейкпоинты, управлять брендовыми схемами, видеть live-превью компонентов и импортировать/экспортировать конфигурацию.
Дизайн-система должна была работать как продуктовая инфраструктура, а не статичная библиотека компонентов:
Вариант компонента, доступный в Figma, соответствует реализованному варианту и явному, настраиваемому параметру в конструкторе — а не трём отдельным, расходящимся источникам правды.
Validation here worked at the level of the system and its contracts, not (yet) as formal end-user usability testing with operators.
Валидация здесь работала на уровне системы и её контрактов, а не (пока) как формальное юзабилити-тестирование с операторами.
Once a capability was framed as shared rather than client-specific, it moved through one repeatable path:
Как только возможность рамировали как общую, а не под конкретного клиента, она проходила один повторяемый путь:
The hard part was rarely a single screen — it was deciding which client differences deserved to become permanent system concepts versus which were noise that should never have been custom-built. That separation is the real design work behind the builder UI.
Сложность была редко в конкретном экране — в основном в том, какие различия клиентов заслуживали стать постоянными системными понятиями, а какие были шумом, который вообще не стоило кастомизировать. Это разделение и есть настоящая дизайн-работа за интерфейсом конструктора.