White-label конструктор продукта

White-label конструктор продукта

Одна дизайн-система для всех казино-брендов
×

Interactive case map Интерактивная карта · Нажмите на карточку

B2B · WHITE-LABEL PLATFORM

Разные бренды.

Общая основа.

Как перейти от ручной сборки клиентских копий к настройке продукта на общей платформе.

Lead Product Designer / Design System Lead

Моя зона: модель кастомизации, дизайн-система и ключевые сценарии конструктора. Пользователь сценария — Setup-команда.

Бренд — конфигурация поверх общего ядра

Тема + композиция + параметры. Новые функции развиваются в платформе, а совместимость задаётся контрактом.

Читайте 01 → 02 → 05 → 09 для общей истории. Этапы 03, 04, 06–08 раскрывают основания, компромиссы и проверки.

Иллюстрация модели white-label продукта

Иллюстрации объясняют подход. Сроки, показатели и детали внедрения конфиденциальны.

B2B · WHITE-LABEL PLATFORM

Distinct brands.

One shared foundation.

Moving from manually assembled client copies to product configuration on a shared platform.

Lead Product Designer / Design System Lead

My scope: the customization model, design system and core constructor flows. The user of this scenario is the Setup team.

A brand is configuration on top of a shared core

Theme + composition + parameters. New features are developed in the platform; a contract defines compatibility.

Read 01 → 02 → 05 → 09 for the core story. Stages 03, 04 and 06–08 explain the evidence, trade-offs and checks.

Иллюстрация модели white-label продукта

Illustrations explain the approach. Timelines, metrics and implementation details are confidential.

01

Контекст

Продукт

B2B-платформа для запуска и поддержки white-label казино-брендов на общей продуктовой основе. Бренды отличаются визуально и конфигурационно, но наследуют продуктовую логику, компоненты и поведение. Основной пользователь этого сценария: - Setup-команда: ей нужно собрать страницы, настроить бренд и передать согласованную конфигурацию в запуск. - Оператор — владелец сайта.

КОЛЛАБОРАЦИЯ

Product Owner · Design · BA · FE Architecture · Development · QA

Моя зона ответственности

Discovery · product modelling · DS architecture · cross-team alignment · handoff · delivery

Моя ответственность: модель кастомизации, архитектура дизайн-системы и ключевые сценарии конструктора. С Product и Engineering — согласование границ общей платформы. С BA и QA — параметры, состояния, ограничения и критерии проверки. С другими стейкхолдерами — единые компоненты и правила адаптивной композиции.

С чего всё началось

Существовал конфигурируемый шаблон с заранее предусмотренными вариантами блоков. Он давал общую основу, но последний участок setup оставался ручным и создавал отдельные client-specific design artifacts.

config-preview · ML Constructor (концепт)

Legacy white-label setup · brand anonymised

Эта настройка была разбросана по отдельным разделам продукта и предопределённым настройкам на уровне компонентов. Масштабирование на больше клиентов требовало цельной системы для страниц, переиспользуемых виджетов, тем, отзывчивого поведения и версионируемых возможностей — а не ещё больше точечных настроек под каждого клиента.

Легаси-процесс

01

Настраиваемый шаблон

общая основа с фиксированным набором вариантов блоков

↓

02

Выбор конфигурации

клиент выбирает из заранее предусмотренных вариантов

↓

03

Ручная сборка сетапа

дизайнер собирает бренд из выбранных блоков вручную

↓

Мастер-шаблон (ок 25 файлов Figma)

Home

Lobby

Game page

Promo

VIP

Tournaments

Для каждой секции — несколько готовых вариантов блоков: Hero ×8, Menu ×4, Games ×6, Promo ×3…

↓

Клиент A

отвязанная копия · локальные правки · своя версия компонентов

Клиент B

отвязанная копия · локальные правки · своя версия компонентов

… Клиент N

отвязанная копия · локальные правки · своя версия компонентов

Следствие

Исправление в общей библиотеке не гарантирует обновления отвязанных клиентских копий: изменения приходится переносить и проверять отдельно.

BASELINE

Общая основа уже существовала. Масштабирование ломалось на ручной сборке и последующем размножении клиентских артефактов.

01

Контекст

Продукт

B2B-платформа для запуска и поддержки white-label казино-брендов на общей продуктовой основе. Бренды отличаются визуально и конфигурационно, но наследуют продуктовую логику, компоненты и поведение. Основной пользователь этого сценария: - Setup-команда: ей нужно собрать страницы, настроить бренд и передать согласованную конфигурацию в запуск. - Оператор — владелец сайта.

КОЛЛАБОРАЦИЯ

Product Owner · Design · BA · FE Architecture · Development · QA

Моя зона ответственности

Discovery · product modelling · DS architecture · cross-team alignment · handoff · delivery

Моя ответственность: модель кастомизации, архитектура дизайн-системы и ключевые сценарии конструктора. С Product и Engineering — согласование границ общей платформы. С BA и QA — параметры, состояния, ограничения и критерии проверки. С другими стейкхолдерами — единые компоненты и правила адаптивной композиции.

С чего всё началось

Существовал конфигурируемый шаблон с заранее предусмотренными вариантами блоков. Он давал общую основу, но последний участок setup оставался ручным и создавал отдельные client-specific design artifacts.

config-preview · ML Constructor (концепт)

Legacy white-label setup · brand anonymised

Но эта настройка была разбросана по отдельным разделам продукта и предопределённым настройкам на уровне компонентов. Масштабирование на больше клиентов требовало цельной системы для страниц, переиспользуемых виджетов, тем, отзывчивого поведения и версионируемых возможностей — а не ещё больше точечных настроек под каждого клиента.

Легаси-процесс

01

Настраиваемый шаблон

общая основа с фиксированным набором вариантов блоков

↓

02

Выбор конфигурации

клиент выбирает из заранее предусмотренных вариантов

↓

03

Ручная сборка сетапа

дизайнер собирает бренд из выбранных блоков вручную

↓

Мастер-шаблон (ок 25 файлов Figma)

Home

Lobby

Game page

Promo

VIP

Tournaments

Для каждой секции — несколько готовых вариантов блоков: Hero ×8, Menu ×4, Games ×6, Promo ×3…

↓

Клиент A

отвязанная копия · локальные правки · своя версия компонентов

Клиент B

отвязанная копия · локальные правки · своя версия компонентов

… Клиент N

отвязанная копия · локальные правки · своя версия компонентов

Следствие

Исправление в общей библиотеке не гарантирует обновления отвязанных клиентских копий: изменения приходится переносить и проверять отдельно.

BASELINE

Общая основа уже существовала. Масштабирование ломалось на ручной сборке и последующем размножении клиентских артефактов.

01

Контекст

Продукт

B2B-платформа для запуска и поддержки white-label казино-брендов на общей продуктовой основе. Бренды отличаются визуально и конфигурационно, но наследуют продуктовую логику, компоненты и поведение. Основной пользователь этого сценария: - Setup-команда: ей нужно собрать страницы, настроить бренд и передать согласованную конфигурацию в запуск. - Оператор — владелец сайта.

КОЛЛАБОРАЦИЯ

Product Owner · Design · BA · FE Architecture · Development · QA

Моя зона ответственности

Discovery · product modelling · DS architecture · cross-team alignment · handoff · delivery

Моя ответственность: модель кастомизации, архитектура дизайн-системы и ключевые сценарии конструктора. С Product и Engineering — согласование границ общей платформы. С BA и QA — параметры, состояния, ограничения и критерии проверки. С другими стейкхолдерами — единые компоненты и правила адаптивной композиции.

С чего всё началось

Существовал конфигурируемый шаблон с заранее предусмотренными вариантами блоков. Он давал общую основу, но последний участок setup оставался ручным и создавал отдельные client-specific design artifacts.

Image - Упрощённый концепт интерфейса ML Constructor с навигацией страниц, холстом виджетов и контекстным инспектором · mobile source restored
Image - Упрощённый концепт интерфейса ML Constructor с навигацией страниц, холстом виджетов и контекстным инспектором · mobile source restored

Legacy white-label setup · brand anonymised

Но эта настройка была разбросана по отдельным разделам продукта и предопределённым настройкам на уровне компонентов. Масштабирование на больше клиентов требовало цельной системы для страниц, переиспользуемых виджетов, тем, отзывчивого поведения и версионируемых возможностей — а не ещё больше точечных настроек под каждого клиента.

Легаси-процесс

01

Настраиваемый шаблон

общая основа с фиксированным набором вариантов блоков

↓

02

Выбор конфигурации

клиент выбирает из заранее предусмотренных вариантов

↓

03

Ручная сборка сетапа

дизайнер собирает бренд из выбранных блоков вручную

↓

Мастер-шаблон (ок 25 файлов Figma)

Home

Lobby

Game page

Promo

VIP

Tournaments

Для каждой секции — несколько готовых вариантов блоков: Hero ×8, Menu ×4, Games ×6, Promo ×3…

↓

Клиент A

отвязанная копия · локальные правки · своя версия компонентов

Клиент B

отвязанная копия · локальные правки · своя версия компонентов

… Клиент N

отвязанная копия · локальные правки · своя версия компонентов

Следствие

Исправление в общей библиотеке не гарантирует обновления отвязанных клиентских копий: изменения приходится переносить и проверять отдельно.

BASELINE

Общая основа уже существовала. Масштабирование ломалось на ручной сборке и последующем размножении клиентских артефактов.

01

Контекст

Продукт

B2B-платформа для запуска и поддержки white-label казино-брендов на общей продуктовой основе. Бренды отличаются визуально и конфигурационно, но наследуют продуктовую логику, компоненты и поведение. Основной пользователь этого сценария: - Setup-команда: ей нужно собрать страницы, настроить бренд и передать согласованную конфигурацию в запуск. - Оператор — владелец сайта.

КОЛЛАБОРАЦИЯ

Product Owner · Design · BA · FE Architecture · Development · QA

Моя зона ответственности

Discovery · product modelling · DS architecture · cross-team alignment · handoff · delivery

Моя ответственность: модель кастомизации, архитектура дизайн-системы и ключевые сценарии конструктора. С Product и Engineering — согласование границ общей платформы. С BA и QA — параметры, состояния, ограничения и критерии проверки. С другими стейкхолдерами — единые компоненты и правила адаптивной композиции.

С чего всё началось

Существовал конфигурируемый шаблон с заранее предусмотренными вариантами блоков. Он давал общую основу, но последний участок setup оставался ручным и создавал отдельные client-specific design artifacts.

Image - Упрощённый концепт интерфейса ML Constructor с навигацией страниц, холстом виджетов и контекстным инспектором · mobile source restored
Image - Упрощённый концепт интерфейса ML Constructor с навигацией страниц, холстом виджетов и контекстным инспектором · mobile source restored

Legacy white-label setup · brand anonymised

Но эта настройка была разбросана по отдельным разделам продукта и предопределённым настройкам на уровне компонентов. Масштабирование на больше клиентов требовало цельной системы для страниц, переиспользуемых виджетов, тем, отзывчивого поведения и версионируемых возможностей — а не ещё больше точечных настроек под каждого клиента.

Легаси-процесс

01

Настраиваемый шаблон

общая основа с фиксированным набором вариантов блоков

↓

02

Выбор конфигурации

клиент выбирает из заранее предусмотренных вариантов

↓

03

Ручная сборка сетапа

дизайнер собирает бренд из выбранных блоков вручную

↓

Мастер-шаблон (ок 25 файлов Figma)

Home

Lobby

Game page

Promo

VIP

Tournaments

Для каждой секции — несколько готовых вариантов блоков: Hero ×8, Menu ×4, Games ×6, Promo ×3…

↓

Клиент A

отвязанная копия · локальные правки · своя версия компонентов

Клиент B

отвязанная копия · локальные правки · своя версия компонентов

… Клиент N

отвязанная копия · локальные правки · своя версия компонентов

Следствие

Исправление в общей библиотеке не гарантирует обновления отвязанных клиентских копий: изменения приходится переносить и проверять отдельно.

BASELINE

Общая основа уже существовала. Масштабирование ломалось на ручной сборке и последующем размножении клиентских артефактов.

01

Context

Product

A B2B platform for launching and maintaining white-label casino brands on a shared product foundation. Brands differ in appearance and configuration, while inheriting the same product logic, components and behavior. Primary users of this scenario: - Setup team: assemble pages, configure the brand and hand over an agreed configuration for launch. - Operator: the website owner.

COLLABORATION

Product Owner · Design · BA · FE Architecture · Development · QA

My scope

Discovery · product modelling · DS architecture · cross-team alignment · handoff · delivery

My responsibility: the customisation model, design-system architecture and core constructor workflows. With Product and Engineering: agree the boundaries of the shared platform. With BA and QA: define parameters, states, constraints and acceptance criteria. With other stakeholders: align shared components and responsive composition rules.

Where it started

A configurable template with predefined block variants already existed. It provided a shared foundation, but the final setup stage remained manual and produced separate client-specific design artifacts.

config-preview · ML Constructor (концепт)

Legacy white-label setup · brand anonymised

Configuration was scattered across separate product sections and predefined component-level settings. Scaling to more clients required a coherent system for pages, reusable widgets, themes, responsive behavior and versioned capabilities, rather than more isolated settings for each client.

Legacy process

01

Configurable template

a shared foundation with a fixed set of block variants

↓

02

Configuration selection

the client chooses from predefined variants

↓

03

Manual setup assembly

the designer manually assembles the brand from selected blocks

↓

Master template (about 25 Figma files)

Home

Lobby

Game page

Promo

VIP

Tournaments

Each section has several ready-made block variants: Hero ×8, Menu ×4, Games ×6, Promo ×3…

↓

Client A

detached copy · local changes · its own component version

Client B

detached copy · local changes · its own component version

… Client N

detached copy · local changes · its own component version

Consequence

A shared-library fix does not guarantee that detached client copies update: changes must be transferred and checked separately.

BASELINE

A shared foundation already existed. Scaling broke down at manual assembly and the resulting proliferation of client artifacts.

01

Context

Product

A B2B platform for launching and maintaining white-label casino brands on a shared product foundation. Brands differ in appearance and configuration, while inheriting the same product logic, components and behavior. Primary users of this scenario: - Setup team: assemble pages, configure the brand and hand over an agreed configuration for launch. - Operator: the website owner.

COLLABORATION

Product Owner · Design · BA · FE Architecture · Development · QA

My scope

Discovery · product modelling · DS architecture · cross-team alignment · handoff · delivery

My responsibility: the customisation model, design-system architecture and core constructor workflows. With Product and Engineering: agree the boundaries of the shared platform. With BA and QA: define parameters, states, constraints and acceptance criteria. With other stakeholders: align shared components and responsive composition rules.

Where it started

A configurable template with predefined block variants already existed. It provided a shared foundation, but the final setup stage remained manual and produced separate client-specific design artifacts.

config-preview · ML Constructor (концепт)

Legacy white-label setup · brand anonymised

But configuration was scattered across separate product sections and predefined component-level settings. Scaling to more clients required a coherent system for pages, reusable widgets, themes, responsive behavior and versioned capabilities, rather than more isolated settings for each client.

Legacy process

01

Configurable template

a shared foundation with a fixed set of block variants

↓

02

Configuration selection

the client chooses from predefined variants

↓

03

Manual setup assembly

the designer manually assembles the brand from selected blocks

↓

Master template (about 25 Figma files)

Home

Lobby

Game page

Promo

VIP

Tournaments

Each section has several ready-made block variants: Hero ×8, Menu ×4, Games ×6, Promo ×3…

↓

Client A

detached copy · local changes · its own component version

Client B

detached copy · local changes · its own component version

… Client N

detached copy · local changes · its own component version

Consequence

A shared-library fix does not guarantee that detached client copies update: changes must be transferred and checked separately.

BASELINE

A shared foundation already existed. Scaling broke down at manual assembly and the resulting proliferation of client artifacts.

01

Context

Product

A B2B platform for launching and maintaining white-label casino brands on a shared product foundation. Brands differ in appearance and configuration, while inheriting the same product logic, components and behavior. Primary users of this scenario: - Setup team: assemble pages, configure the brand and hand over an agreed configuration for launch. - Operator: the website owner.

COLLABORATION

Product Owner · Design · BA · FE Architecture · Development · QA

My scope

Discovery · product modelling · DS architecture · cross-team alignment · handoff · delivery

My responsibility: the customisation model, design-system architecture and core constructor workflows. With Product and Engineering: agree the boundaries of the shared platform. With BA and QA: define parameters, states, constraints and acceptance criteria. With other stakeholders: align shared components and responsive composition rules.

Where it started

A configurable template with predefined block variants already existed. It provided a shared foundation, but the final setup stage remained manual and produced separate client-specific design artifacts.

Image - Упрощённый концепт интерфейса ML Constructor с навигацией страниц, холстом виджетов и контекстным инспектором · mobile source restored
Image - Упрощённый концепт интерфейса ML Constructor с навигацией страниц, холстом виджетов и контекстным инспектором · mobile source restored

Legacy white-label setup · brand anonymised

But configuration was scattered across separate product sections and predefined component-level settings. Scaling to more clients required a coherent system for pages, reusable widgets, themes, responsive behavior and versioned capabilities, rather than more isolated settings for each client.

Legacy process

01

Configurable template

a shared foundation with a fixed set of block variants

↓

02

Configuration selection

the client chooses from predefined variants

↓

03

Manual setup assembly

the designer manually assembles the brand from selected blocks

↓

Master template (about 25 Figma files)

Home

Lobby

Game page

Promo

VIP

Tournaments

Each section has several ready-made block variants: Hero ×8, Menu ×4, Games ×6, Promo ×3…

↓

Client A

detached copy · local changes · its own component version

Client B

detached copy · local changes · its own component version

… Client N

detached copy · local changes · its own component version

Consequence

A shared-library fix does not guarantee that detached client copies update: changes must be transferred and checked separately.

BASELINE

A shared foundation already existed. Scaling broke down at manual assembly and the resulting proliferation of client artifacts.

01

Context

Product

A B2B platform for launching and maintaining white-label casino brands on a shared product foundation. Brands differ in appearance and configuration, while inheriting the same product logic, components and behavior. Primary users of this scenario: - Setup team: assemble pages, configure the brand and hand over an agreed configuration for launch. - Operator: the website owner.

COLLABORATION

Product Owner · Design · BA · FE Architecture · Development · QA

My scope

Discovery · product modelling · DS architecture · cross-team alignment · handoff · delivery

My responsibility: the customisation model, design-system architecture and core constructor workflows. With Product and Engineering: agree the boundaries of the shared platform. With BA and QA: define parameters, states, constraints and acceptance criteria. With other stakeholders: align shared components and responsive composition rules.

Where it started

A configurable template with predefined block variants already existed. It provided a shared foundation, but the final setup stage remained manual and produced separate client-specific design artifacts.

Image - Упрощённый концепт интерфейса ML Constructor с навигацией страниц, холстом виджетов и контекстным инспектором · mobile source restored
Image - Упрощённый концепт интерфейса ML Constructor с навигацией страниц, холстом виджетов и контекстным инспектором · mobile source restored

Legacy white-label setup · brand anonymised

But configuration was scattered across separate product sections and predefined component-level settings. Scaling to more clients required a coherent system for pages, reusable widgets, themes, responsive behavior and versioned capabilities, rather than more isolated settings for each client.

Legacy process

01

Configurable template

a shared foundation with a fixed set of block variants

↓

02

Configuration selection

the client chooses from predefined variants

↓

03

Manual setup assembly

the designer manually assembles the brand from selected blocks

↓

Master template (about 25 Figma files)

Home

Lobby

Game page

Promo

VIP

Tournaments

Each section has several ready-made block variants: Hero ×8, Menu ×4, Games ×6, Promo ×3…

↓

Client A

detached copy · local changes · its own component version

Client B

detached copy · local changes · its own component version

… Client N

detached copy · local changes · its own component version

Consequence

A shared-library fix does not guarantee that detached client copies update: changes must be transferred and checked separately.

BASELINE

A shared foundation already existed. Scaling broke down at manual assembly and the resulting proliferation of client artifacts.

02

Проблема

Компании нужно было поддерживать много визуально разных white-label продуктов без отдельного дизайн- и code path для каждого клиента.

PRODUCT CHALLENGE

Как масштабироваться, дать брендам достаточно гибкости, сохранив юзабилити, отзывчивость и согласованность системы, не увеличивая стоимость поддержки?

Накопленная стоимость вариативности

VARIATION COST · COMPOUNDING EFFECT

01

Duplicated design

Похожие setup пересобираются вручную

02

Duplicated new function implementation

Медленное внедрение обновлений дизайн-системы; секции реализуются повторно

03

Component + Figma / code drift

Варианты и токены расходятся между продуктами

04

Manual propagation of fixes

Один fix приходится переносить N раз

05

Unclear versions

Непонятно, какой контракт использует каждый бренд

Это не только UI-kit problem.

Требовалась общая продуктовая модель, связывающая токены, переиспользуемые компоненты, композицию страниц, схемы конфигурации и версионирование в одну систему.

Примеры брендов на старом шаблоне.

HP_Desktop
HP_Desktop

Legacy white-label setup

02

Проблема

Компании нужно было поддерживать много визуально разных white-label продуктов без отдельного дизайн- и code path для каждого клиента.

PRODUCT CHALLENGE

Как масштабироваться, дать брендам достаточно гибкости, сохранив юзабилити, отзывчивость и согласованность системы, не увеличивая стоимость поддержки?

Накопленная стоимость вариативности

VARIATION COST · COMPOUNDING EFFECT

01

Duplicated design

Похожие setup пересобираются вручную

02

Duplicated new function implementation

Медленное внедрение обновлений дизайн-системы; секции реализуются повторно

03

Component + Figma / code drift

Варианты и токены расходятся между продуктами

04

Manual propagation of fixes

Один fix приходится переносить N раз

05

Unclear versions

Непонятно, какой контракт использует каждый бренд

Это не только UI-kit problem.

Требовалась общая продуктовая модель, связывающая токены, переиспользуемые компоненты, композицию страниц, схемы конфигурации и версионирование в одну систему.

Примеры брендов на старом шаблоне.

HP_Desktop
HP_Desktop

Legacy white-label setup

02

Проблема

Компании нужно было поддерживать много визуально разных white-label продуктов без отдельного дизайн- и code path для каждого клиента.

PRODUCT CHALLENGE

Как масштабироваться, дать брендам достаточно гибкости, сохранив юзабилити, отзывчивость и согласованность системы, не увеличивая стоимость поддержки?

Накопленная стоимость вариативности

VARIATION COST · COMPOUNDING EFFECT

01

Duplicated design

Похожие setup пересобираются вручную

02

Duplicated new function implementation

Медленное внедрение обновлений дизайн-системы; секции реализуются повторно

03

Component + Figma / code drift

Варианты и токены расходятся между продуктами

04

Manual propagation of fixes

Один fix приходится переносить N раз

05

Unclear versions

Непонятно, какой контракт использует каждый бренд

Это не только UI-kit problem.

Требовалась общая продуктовая модель, связывающая токены, переиспользуемые компоненты, композицию страниц, схемы конфигурации и версионирование в одну систему.

Примеры брендов на старом шаблоне.

HP_Mobile · mobile source restored
HP_Mobile · mobile source restored

Legacy white-label setup

02

Проблема

Компании нужно было поддерживать много визуально разных white-label продуктов без отдельного дизайн- и code path для каждого клиента.

PRODUCT CHALLENGE

Как масштабироваться, дать брендам достаточно гибкости, сохранив юзабилити, отзывчивость и согласованность системы, не увеличивая стоимость поддержки?

Накопленная стоимость вариативности

VARIATION COST · COMPOUNDING EFFECT

01

Duplicated design

Похожие setup пересобираются вручную

02

Duplicated new function implementation

Медленное внедрение обновлений дизайн-системы; секции реализуются повторно

03

Component + Figma / code drift

Варианты и токены расходятся между продуктами

04

Manual propagation of fixes

Один fix приходится переносить N раз

05

Unclear versions

Непонятно, какой контракт использует каждый бренд

Это не только UI-kit problem.

Требовалась общая продуктовая модель, связывающая токены, переиспользуемые компоненты, композицию страниц, схемы конфигурации и версионирование в одну систему.

Примеры брендов на старом шаблоне.

HP_Mobile · mobile source restored
HP_Mobile · mobile source restored

Legacy white-label setup

02

Problem

The company needed to maintain many visually distinct white-label products without a separate design and code path for each client.

PRODUCT CHALLENGE

How can we scale and give brands enough flexibility while preserving usability, responsiveness and system consistency without increasing maintenance costs?

The accumulating cost of variation

VARIATION COST · COMPOUNDING EFFECT

01

Duplicated design

Similar setups are rebuilt by hand

02

Duplicated new function implementation

Slow design-system updates; sections are implemented repeatedly

03

Component + Figma / code drift

Variants and tokens drift between products

04

Manual propagation of fixes

One fix must be transferred N times

05

Unclear versions

Unclear which contract each brand uses

This is more than a UI-kit problem.

We needed a shared product model connecting tokens, reusable components, page composition, configuration schemas and versioning in one system.

Examples of brands on the legacy template.

HP_Desktop
HP_Desktop

Legacy white-label setup

02

Problem

The company needed to maintain many visually distinct white-label products without a separate design and code path for each client.

PRODUCT CHALLENGE

How can we scale and give brands enough flexibility while preserving usability, responsiveness and system consistency without increasing maintenance costs?

The accumulating cost of variation

VARIATION COST · COMPOUNDING EFFECT

01

Duplicated design

Similar setups are rebuilt by hand

02

Duplicated new function implementation

Slow design-system updates; sections are implemented repeatedly

03

Component + Figma / code drift

Variants and tokens drift between products

04

Manual propagation of fixes

One fix must be transferred N times

05

Unclear versions

Unclear which contract each brand uses

This is more than a UI-kit problem.

We needed a shared product model connecting tokens, reusable components, page composition, configuration schemas and versioning in one system.

Examples of brands on the legacy template.

HP_Desktop
HP_Desktop

Legacy white-label setup

02

Problem

The company needed to maintain many visually distinct white-label products without a separate design and code path for each client.

PRODUCT CHALLENGE

How can we scale and give brands enough flexibility while preserving usability, responsiveness and system consistency without increasing maintenance costs?

The accumulating cost of variation

VARIATION COST · COMPOUNDING EFFECT

01

Duplicated design

Similar setups are rebuilt by hand

02

Duplicated new function implementation

Slow design-system updates; sections are implemented repeatedly

03

Component + Figma / code drift

Variants and tokens drift between products

04

Manual propagation of fixes

One fix must be transferred N times

05

Unclear versions

Unclear which contract each brand uses

This is more than a UI-kit problem.

We needed a shared product model connecting tokens, reusable components, page composition, configuration schemas and versioning in one system.

Examples of brands on the legacy template.

HP_Mobile · mobile source restored
HP_Mobile · mobile source restored

Legacy white-label setup

02

Problem

The company needed to maintain many visually distinct white-label products without a separate design and code path for each client.

PRODUCT CHALLENGE

How can we scale and give brands enough flexibility while preserving usability, responsiveness and system consistency without increasing maintenance costs?

The accumulating cost of variation

VARIATION COST · COMPOUNDING EFFECT

01

Duplicated design

Similar setups are rebuilt by hand

02

Duplicated new function implementation

Slow design-system updates; sections are implemented repeatedly

03

Component + Figma / code drift

Variants and tokens drift between products

04

Manual propagation of fixes

One fix must be transferred N times

05

Unclear versions

Unclear which contract each brand uses

This is more than a UI-kit problem.

We needed a shared product model connecting tokens, reusable components, page composition, configuration schemas and versioning in one system.

Examples of brands on the legacy template.

HP_Mobile · mobile source restored
HP_Mobile · mobile source restored

Legacy white-label setup

03

Исследование

Прежде чем предлагать решение, я участвовал во встречах с клиентом, чтобы понять его задачи, проблемы и ожидания от продукта. Проследил реальный процесс сетапа от начала до конца, чтобы отделить настоящие различия клиентов от случайных. Этап исследования включал:

•

разобрали запросы клиентов по повторяемости, сложности, реализуемости и влиянию на продукт (около 300 запросов на изменения за год);

•

аудит текущего шаблона: какие варианты блоков клиенты реально выбирали в прошлые годы;

•

какие дизайн- и dev-задачи повторялись между клиентами;

•

какие компоненты расходились чаще всего и почему;

•

разделили визуальные, структурные и функциональные различия;

•

сопоставили запросы с возможностями продукта и рынка;

•

провели аудит компонентов и переменных дизайн-системы;

•

собрали требования продуктовых стейкхолдеров;

•

провели UX-аудит ключевых сценариев;

•

сравнили ограничения доработки legacy и перехода к новой архитектуре.

Аудит запросов клиентов за год ≈300 запросов

Визуальные: дополнительные цветовые переменные, дополнительное оформление компонентов

≈31%

токены

Композиция: наличие и порядок секций

≈19%

композиция

Контент и варианты компонентов

≈26%

параметры

Функциональные: новые возможности

≈13%

флаги

Одноразовые запросы, не оправданные

≈11%

шум

Вывод

≈76% запросов закрываются токенами, композицией и параметрами — без нового кода. Именно это стало основанием для модели «клиент = настройки».

Цель — закрывать повторяемые запросы управляемыми настройками. Новые и нестандартные сценарии проходят отдельную оценку: их включают в общую платформу, оставляют исключением или отклоняют.

Ключевая структура

Классификация разделила настройки бренда и новые возможности продукта. Версионирование добавляет сквозное условие: конфигурация должна быть совместима с реализацией.

Четыре области настройки + контракт совместимости

VISUAL IDENTITY

Design tokens / variables

цвет · типографика · spacing · radius

COMPOSITION

Pages / sections / widget order

структурные паттерны и layout

PARAMETERS

Content / variants / behaviour

настраиваемые свойства

CAPABILITIES

Разработанные возможности / feature flags

флаг включает готовую функцию, а не создаёт её

VERSION

Version contract

совместимая версия template + schema

03

Исследование

Прежде чем предлагать решение, я участвовал во встречах с клиентом, чтобы понять его задачи, проблемы и ожидания от продукта. Проследил реальный процесс сетапа от начала до конца, чтобы отделить настоящие различия клиентов от случайных. Этап исследования включал:

•

разобрали запросы клиентов по повторяемости, сложности, реализуемости и влиянию на продукт (около 300 запросов на изменения за год);

•

аудит текущего шаблона: какие варианты блоков клиенты реально выбирали в прошлые годы;

•

какие дизайн- и dev-задачи повторялись между клиентами;

•

какие компоненты расходились чаще всего и почему;

•

разделили визуальные, структурные и функциональные различия;

•

сопоставили запросы с возможностями продукта и рынка;

•

провели аудит компонентов и переменных дизайн-системы;

•

собрали требования продуктовых стейкхолдеров;

•

провели UX-аудит ключевых сценариев;

•

сравнили ограничения доработки legacy и перехода к новой архитектуре.

Аудит запросов клиентов за год ≈300 запросов

Визуальные: дополнительные цветовые переменные, дополнительное оформление компонентов

≈31%

токены

Композиция: наличие и порядок секций

≈19%

композиция

Контент и варианты компонентов

≈26%

параметры

Функциональные: новые возможности

≈13%

флаги

Одноразовые запросы, не оправданные

≈11%

шум

Вывод

≈76% запросов закрываются токенами, композицией и параметрами — без нового кода. Именно это стало основанием для модели «клиент = настройки».

Цель — закрывать повторяемые запросы управляемыми настройками. Новые и нестандартные сценарии проходят отдельную оценку: их включают в общую платформу, оставляют исключением или отклоняют.

Ключевая структура

Классификация разделила настройки бренда и новые возможности продукта. Версионирование добавляет сквозное условие: конфигурация должна быть совместима с реализацией.

Четыре области настройки + контракт совместимости

VISUAL IDENTITY

Design tokens / variables

цвет · типографика · spacing · radius

COMPOSITION

Pages / sections / widget order

структурные паттерны и layout

PARAMETERS

Content / variants / behaviour

настраиваемые свойства

CAPABILITIES

Разработанные возможности / feature flags

флаг включает готовую функцию, а не создаёт её

VERSION

Version contract

совместимая версия template + schema

03

Исследование

Прежде чем предлагать решение, я участвовал во встречах с клиентом, чтобы понять его задачи, проблемы и ожидания от продукта. Проследил реальный процесс сетапа от начала до конца, чтобы отделить настоящие различия клиентов от случайных. Этап исследования включал:

•

разобрали запросы клиентов по повторяемости, сложности, реализуемости и влиянию на продукт (около 300 запросов на изменения за год);

•

аудит текущего шаблона: какие варианты блоков клиенты реально выбирали в прошлые годы;

•

какие дизайн- и dev-задачи повторялись между клиентами;

•

какие компоненты расходились чаще всего и почему;

•

разделили визуальные, структурные и функциональные различия;

•

сопоставили запросы с возможностями продукта и рынка;

•

провели аудит компонентов и переменных дизайн-системы;

•

собрали требования продуктовых стейкхолдеров;

•

провели UX-аудит ключевых сценариев;

•

сравнили ограничения доработки legacy и перехода к новой архитектуре.

Аудит запросов клиентов за год ≈300 запросов

Визуальные: дополнительные цветовые переменные, дополнительное оформление компонентов

31%

токены

Композиция: наличие и порядок секций

19%

композиция

Контент и варианты компонентов

26%

параметры

Функциональные: новые возможности

13%

флаги

Одноразовые запросы, не оправданные

11%

шум

Вывод

76% запросов закрываются токенами, композицией и параметрами — без нового кода. Именно это стало основанием для модели «клиент = настройки».

Цель — закрывать повторяемые запросы управляемыми настройками. Новые и нестандартные сценарии проходят отдельную оценку: их включают в общую платформу, оставляют исключением или отклоняют.

Ключевая структура

Классификация разделила настройки бренда и новые возможности продукта. Версионирование добавляет сквозное условие: конфигурация должна быть совместима с реализацией.

Четыре области настройки + контракт совместимости

VISUAL IDENTITY

Design tokens / variables

цвет · типографика · spacing · radius

COMPOSITION

Pages / sections / widget order

структурные паттерны и layout

PARAMETERS

Content / variants / behaviour

настраиваемые свойства

CAPABILITIES

Разработанные возможности / feature flags

флаг включает готовую функцию, а не создаёт её

VERSION

Version contract

совместимая версия template + schema

03

Исследование

Прежде чем предлагать решение, я участвовал во встречах с клиентом, чтобы понять его задачи, проблемы и ожидания от продукта. Проследил реальный процесс сетапа от начала до конца, чтобы отделить настоящие различия клиентов от случайных. Этап исследования включал:

•

разобрали запросы клиентов по повторяемости, сложности, реализуемости и влиянию на продукт (около 300 запросов на изменения за год);

•

аудит текущего шаблона: какие варианты блоков клиенты реально выбирали в прошлые годы;

•

какие дизайн- и dev-задачи повторялись между клиентами;

•

какие компоненты расходились чаще всего и почему;

•

разделили визуальные, структурные и функциональные различия;

•

сопоставили запросы с возможностями продукта и рынка;

•

провели аудит компонентов и переменных дизайн-системы;

•

собрали требования продуктовых стейкхолдеров;

•

провели UX-аудит ключевых сценариев;

•

сравнили ограничения доработки legacy и перехода к новой архитектуре.

Аудит запросов клиентов за год ≈300 запросов

Визуальные: дополнительные цветовые переменные, дополнительное оформление компонентов

31%

токены

Композиция: наличие и порядок секций

19%

композиция

Контент и варианты компонентов

26%

параметры

Функциональные: новые возможности

13%

флаги

Одноразовые запросы, не оправданные

11%

шум

Вывод

76% запросов закрываются токенами, композицией и параметрами — без нового кода. Именно это стало основанием для модели «клиент = настройки».

Цель — закрывать повторяемые запросы управляемыми настройками. Новые и нестандартные сценарии проходят отдельную оценку: их включают в общую платформу, оставляют исключением или отклоняют.

Ключевая структура

Классификация разделила настройки бренда и новые возможности продукта. Версионирование добавляет сквозное условие: конфигурация должна быть совместима с реализацией.

Четыре области настройки + контракт совместимости

VISUAL IDENTITY

Design tokens / variables

цвет · типографика · spacing · radius

COMPOSITION

Pages / sections / widget order

структурные паттерны и layout

PARAMETERS

Content / variants / behaviour

настраиваемые свойства

CAPABILITIES

Разработанные возможности / feature flags

флаг включает готовую функцию, а не создаёт её

VERSION

Version contract

совместимая версия template + schema

03

Research

Before proposing a solution, I joined client meetings to understand their tasks, problems and product expectations. I traced the actual setup process from start to finish to distinguish meaningful client differences from incidental ones. The research included:

•

analyzed client requests by recurrence, complexity, feasibility and product impact (about 300 change requests in a year);

•

audited the current template: which block variants clients actually chose in previous years;

•

identified design and development tasks repeated across clients;

•

identified which components drifted most often, and why;

•

separated visual, structural and functional differences;

•

compared requests with product capabilities and the market;

•

audited design-system components and variables;

•

gathered requirements from product stakeholders;

•

conducted a UX audit of key flows;

•

compared the constraints of extending legacy with moving to a new architecture.

Annual client-request audit · ≈300 requests

Visual: additional color variables and component styling

≈31%

tokens

Composition: section presence and order

≈19%

composition

Content and component variants

≈26%

parameters

Functional: new capabilities

≈13%

flags

Unjustified one-off requests

≈11%

noise

Finding

≈76% of requests are covered by tokens, composition and parameters, without new code. This became the basis for the “client = settings” model.

The goal is to address recurring requests with controlled settings. New or unusual scenarios are assessed separately: they become shared-platform capabilities, remain exceptions or are rejected.

Key structure

The classification separated brand settings from new product capabilities. Versioning adds a cross-cutting requirement: configuration must be compatible with implementation.

Four configuration areas + a compatibility contract

VISUAL IDENTITY

Design tokens / variables

color · typography · spacing · radius

COMPOSITION

Pages / sections / widget order

structural patterns and layout

PARAMETERS

Content / variants / behaviour

configurable properties

CAPABILITIES

Implemented capabilities / feature flags

a flag enables an implemented feature; it does not create one

VERSION

Version contract

compatible template + schema version

03

Research

Before proposing a solution, I joined client meetings to understand their tasks, problems and product expectations. I traced the actual setup process from start to finish to distinguish meaningful client differences from incidental ones. The research included:

•

analyzed client requests by recurrence, complexity, feasibility and product impact (about 300 change requests in a year);

•

audited the current template: which block variants clients actually chose in previous years;

•

identified design and development tasks repeated across clients;

•

identified which components drifted most often, and why;

•

separated visual, structural and functional differences;

•

compared requests with product capabilities and the market;

•

audited design-system components and variables;

•

gathered requirements from product stakeholders;

•

conducted a UX audit of key flows;

•

compared the constraints of extending legacy with moving to a new architecture.

Annual client-request audit · ≈300 requests

Visual: additional color variables and component styling

≈31%

tokens

Composition: section presence and order

≈19%

composition

Content and component variants

≈26%

parameters

Functional: new capabilities

≈13%

flags

Unjustified one-off requests

≈11%

noise

Finding

≈76% of requests are covered by tokens, composition and parameters, without new code. This became the basis for the “client = settings” model.

The goal is to address recurring requests with controlled settings. New or unusual scenarios are assessed separately: they become shared-platform capabilities, remain exceptions or are rejected.

Key structure

The classification separated brand settings from new product capabilities. Versioning adds a cross-cutting requirement: configuration must be compatible with implementation.

Four configuration areas + a compatibility contract

VISUAL IDENTITY

Design tokens / variables

color · typography · spacing · radius

COMPOSITION

Pages / sections / widget order

structural patterns and layout

PARAMETERS

Content / variants / behaviour

configurable properties

CAPABILITIES

Implemented capabilities / feature flags

a flag enables an implemented feature; it does not create one

VERSION

Version contract

compatible template + schema version

03

Research

Before proposing a solution, I joined client meetings to understand their tasks, problems and product expectations. I traced the real setup process end to end to separate genuine client differences from accidental ones. The research included:

•

analyzed client requests by recurrence, complexity, feasibility and product impact (about 300 change requests in a year);

•

audited the current template: which block variants clients actually chose in previous years;

•

identified design and development tasks repeated across clients;

•

identified which components drifted most often, and why;

•

separated visual, structural and functional differences;

•

compared requests with product capabilities and the market;

•

audited design-system components and variables;

•

gathered requirements from product stakeholders;

•

conducted a UX audit of key flows;

•

compared the constraints of extending legacy with moving to a new architecture.

Annual client-request audit · ≈300 requests

Visual: additional color variables and component styling

31%

tokens

Composition: section presence and order

19%

composition

Content and component variants

26%

parameters

Functional: new capabilities

13%

flags

Unjustified one-off requests

11%

noise

Finding

76% of requests can be addressed through tokens, composition and parameters, without new code. This informed the “client = settings” model.

The goal is to address recurring requests with controlled settings. New or unusual scenarios are assessed separately: they become shared-platform capabilities, remain exceptions or are rejected.

Key structure

The classification separated brand settings from new product capabilities. Versioning adds a cross-cutting requirement: configuration must be compatible with implementation.

Four configuration areas + a compatibility contract

VISUAL IDENTITY

Design tokens / variables

color · typography · spacing · radius

COMPOSITION

Pages / sections / widget order

structural patterns and layout

PARAMETERS

Content / variants / behaviour

configurable properties

CAPABILITIES

Implemented capabilities / feature flags

a flag enables an implemented feature; it does not create one

VERSION

Version contract

compatible template + schema version

03

Research

Before proposing a solution, I joined client meetings to understand their tasks, problems and product expectations. I traced the real setup process end to end to separate genuine client differences from accidental ones. The research included:

•

analyzed client requests by recurrence, complexity, feasibility and product impact (about 300 change requests in a year);

•

audited the current template: which block variants clients actually chose in previous years;

•

identified design and development tasks repeated across clients;

•

identified which components drifted most often, and why;

•

separated visual, structural and functional differences;

•

compared requests with product capabilities and the market;

•

audited design-system components and variables;

•

gathered requirements from product stakeholders;

•

conducted a UX audit of key flows;

•

compared the constraints of extending legacy with moving to a new architecture.

Annual client-request audit · ≈300 requests

Visual: additional color variables and component styling

31%

tokens

Composition: section presence and order

19%

composition

Content and component variants

26%

parameters

Functional: new capabilities

13%

flags

Unjustified one-off requests

11%

noise

Finding

76% of requests can be addressed through tokens, composition and parameters, without new code. This informed the “client = settings” model.

The goal is to address recurring requests with controlled settings. New or unusual scenarios are assessed separately: they become shared-platform capabilities, remain exceptions or are rejected.

Key structure

The classification separated brand settings from new product capabilities. Versioning adds a cross-cutting requirement: configuration must be compatible with implementation.

Four configuration areas + a compatibility contract

VISUAL IDENTITY

Design tokens / variables

color · typography · spacing · radius

COMPOSITION

Pages / sections / widget order

structural patterns and layout

PARAMETERS

Content / variants / behaviour

configurable properties

CAPABILITIES

Implemented capabilities / feature flags

a flag enables an implemented feature; it does not create one

VERSION

Version contract

compatible template + schema version

04

Гипотезы и Цели

Основная гипотеза:

Индивидуальные запросы клиентов и изменения, которые раньше приводили к созданию отдельных форков продукта, можно предусмотреть заранее на уровне архитектуры дизайн-системы.

Принципы проектирования:

•

Одно общее ядро — все клиенты работают на одной поддерживаемой основе вместо независимых форков.

•

Конфигурация вместо дублирования — различия бренда и layout описываются настройками, а не копированием экранов или компонентов.

•

Контролируемая гибкость — готовые варианты и ограничения снижают риск несогласованного интерфейса. Доступность и качество всё равно требуют проверки.

•

Общие улучшения — новая возможность строится один раз в общей платформе и становится доступна через параметры или feature-флаги.

•

Один язык дизайна и кода — переменные Figma, свойства компонентов, фронтенд-токены и схемы конструктора описывают одну и ту же систему.

•

Безопасная эволюция — существующие клиенты остаются стабильными, пока общая платформа продолжает улучшаться под ними.

Гипотеза: форки под клиента → общее ядро + конфигурация

Было

Клиент A

свой код + свой дизайн

Клиент B

свой код + свой дизайн

Клиент C

свой код + свой дизайн

N независимых кодовых баз. Фикс ×N. Версии расходятся, обновления DS доходят месяцами.

Стало

Общее ядро · одна поддерживаемая версия

страницы · виджеты · варианты

config-a.json

токены

config-b.json

композиция параметры ·

config-c.json

флаги · версия

Клиент = набор настроек поверх ядра. Фикс ×1 доходит до всех. Новая возможность включается флагом.

Boolean и text variables для управления вариантами

Shared · одинаково у всех

  • логика взаимодействия
  • контракты компонентов
  • адаптивное поведение
  • возможности платформы

Configurable · описывается конфигом

  • визуальные значения
  • допустимая композиция
  • контент и параметры
  • включённые возможности
  • версия шаблона и схемы

Цель

Business & product impact

Сделать улучшенную, гибкую и масштабируемую дизайн-систему вместе с Configuration and Operations Workspace, которые закрывают большинство типовых клиентских запросов без отдельной разработки.

Покрыть 90–95% типовых client requests через настройки

Ускорить сетапы и добавление платформенных фичей

Улучшить UX и ключевые casino-метрики: reg2dep, avg dep, avg bet

Единый инструмент для Setup, Live, Product и клиентов

04

Гипотезы и Цели

Основная гипотеза:

Индивидуальные запросы клиентов и изменения, которые раньше приводили к созданию отдельных форков продукта, можно предусмотреть заранее на уровне архитектуры дизайн-системы.

Принципы проектирования:

•

Одно общее ядро — все клиенты работают на одной поддерживаемой основе вместо независимых форков.

•

Конфигурация вместо дублирования — различия бренда и layout описываются настройками, а не копированием экранов или компонентов.

•

Контролируемая гибкость — готовые варианты и ограничения снижают риск несогласованного интерфейса. Доступность и качество всё равно требуют проверки.

•

Общие улучшения — новая возможность строится один раз в общей платформе и становится доступна через параметры или feature-флаги.

•

Один язык дизайна и кода — переменные Figma, свойства компонентов, фронтенд-токены и схемы конструктора описывают одну и ту же систему.

•

Безопасная эволюция — существующие клиенты остаются стабильными, пока общая платформа продолжает улучшаться под ними.

Гипотеза: форки под клиента → общее ядро + конфигурация

Было

Клиент A

свой код + свой дизайн

Клиент B

свой код + свой дизайн

Клиент C

свой код + свой дизайн

N независимых кодовых баз. Фикс ×N. Версии расходятся, обновления DS доходят месяцами.

Стало

Общее ядро · одна поддерживаемая версия

страницы · виджеты · варианты

config-a.json

токены

config-b.json

композиция параметры ·

config-c.json

флаги · версия

Клиент = набор настроек поверх ядра. Фикс ×1 доходит до всех. Новая возможность включается флагом.

Boolean и text variables для управления вариантами

Shared · одинаково у всех

  • логика взаимодействия
  • контракты компонентов
  • адаптивное поведение
  • возможности платформы

Configurable · описывается конфигом

  • визуальные значения
  • допустимая композиция
  • контент и параметры
  • включённые возможности
  • версия шаблона и схемы

Цель

Business & product impact

Сделать улучшенную, гибкую и масштабируемую дизайн-систему вместе с Configuration and Operations Workspace, которые закрывают большинство типовых клиентских запросов без отдельной разработки.

Покрыть 90–95% типовых client requests через настройки

Ускорить сетапы и добавление платформенных фичей

Улучшить UX и ключевые casino-метрики: reg2dep, avg dep, avg bet

Единый инструмент для Setup, Live, Product и клиентов

04

Гипотезы и Цели

Основная гипотеза:

Индивидуальные запросы клиентов и изменения, которые раньше приводили к созданию отдельных форков продукта, можно предусмотреть заранее на уровне архитектуры дизайн-системы.

Принципы проектирования:

•

Одно общее ядро — все клиенты работают на одной поддерживаемой основе вместо независимых форков.

•

Конфигурация вместо дублирования — различия бренда и layout описываются настройками, а не копированием экранов или компонентов.

•

Контролируемая гибкость — готовые варианты и ограничения снижают риск несогласованного интерфейса. Доступность и качество всё равно требуют проверки.

•

Общие улучшения — новая возможность строится один раз в общей платформе и становится доступна через параметры или feature-флаги.

•

Один язык дизайна и кода — переменные Figma, свойства компонентов, фронтенд-токены и схемы конструктора описывают одну и ту же систему.

•

Безопасная эволюция — существующие клиенты остаются стабильными, пока общая платформа продолжает улучшаться под ними.

Гипотеза: форки под клиента → общее ядро + конфигурация

Было

Клиент A

свой код + свой дизайн

Клиент B

свой код + свой дизайн

Клиент C

свой код + свой дизайн

N независимых кодовых баз. Фикс ×N. Версии расходятся, обновления DS доходят месяцами.

Стало

Общее ядро · одна поддерживаемая версия

страницы · виджеты · варианты

config-a.json

токены

config-b.json

композиция · параметры

config-c.json

флаги · версия

Клиент = набор настроек поверх ядра. Фикс доходит до всех. Новая возможность включается флагом.

Boolean и text variables для управления вариантами

Shared одинаково у всех

  • логика взаимодействия
  • контракты компонентов
  • адаптивное поведение
  • возможности платформы

Configurable описывается конфигом

  • визуальные значения
  • допустимая композиция
  • контент и параметры
  • включённые возможности
  • версия шаблона и схемы

Цель

Business & product impact

Сделать улучшенную, гибкую и масштабируемую дизайн-систему вместе с Configuration and Operations Workspace, которые закрывают большинство типовых клиентских запросов без отдельной разработки.

Покрыть 90–95% типовых client requests через настройки

Ускорить сетапы и добавление платформенных фичей

Улучшить UX и ключевые casino-метрики: reg2dep, avg dep, avg bet

Единый инструмент для Setup, Live, Product и клиентов

04

Гипотезы и Цели

Основная гипотеза:

Индивидуальные запросы клиентов и изменения, которые раньше приводили к созданию отдельных форков продукта, можно предусмотреть заранее на уровне архитектуры дизайн-системы.

Принципы проектирования:

•

Одно общее ядро — все клиенты работают на одной поддерживаемой основе вместо независимых форков.

•

Конфигурация вместо дублирования — различия бренда и layout описываются настройками, а не копированием экранов или компонентов.

•

Контролируемая гибкость — готовые варианты и ограничения снижают риск несогласованного интерфейса. Доступность и качество всё равно требуют проверки.

•

Общие улучшения — новая возможность строится один раз в общей платформе и становится доступна через параметры или feature-флаги.

•

Один язык дизайна и кода — переменные Figma, свойства компонентов, фронтенд-токены и схемы конструктора описывают одну и ту же систему.

•

Безопасная эволюция — существующие клиенты остаются стабильными, пока общая платформа продолжает улучшаться под ними.

Гипотеза: форки под клиента → общее ядро + конфигурация

Было

Клиент A

свой код + свой дизайн

Клиент B

свой код + свой дизайн

Клиент C

свой код + свой дизайн

N независимых кодовых баз. Фикс ×N. Версии расходятся, обновления DS доходят месяцами.

Стало

Общее ядро · одна поддерживаемая версия

страницы · виджеты · варианты

config-a.json

токены

config-b.json

композиция · параметры

config-c.json

флаги · версия

Клиент = набор настроек поверх ядра. Фикс доходит до всех. Новая возможность включается флагом.

Boolean и text variables для управления вариантами

Shared одинаково у всех

  • логика взаимодействия
  • контракты компонентов
  • адаптивное поведение
  • возможности платформы

Configurable описывается конфигом

  • визуальные значения
  • допустимая композиция
  • контент и параметры
  • включённые возможности
  • версия шаблона и схемы

Цель

Business & product impact

Сделать улучшенную, гибкую и масштабируемую дизайн-систему вместе с Configuration and Operations Workspace, которые закрывают большинство типовых клиентских запросов без отдельной разработки.

Покрыть 90–95% типовых client requests через настройки

Ускорить сетапы и добавление платформенных фичей

Улучшить UX и ключевые casino-метрики: reg2dep, avg dep, avg bet

Единый инструмент для Setup, Live, Product и клиентов

04

Hypotheses & Goals

Main hypothesis:

Client-specific requests and changes that previously created separate product forks can be anticipated in the design-system architecture.

Design principles:

•

One shared core — all clients use one maintained foundation instead of independent forks.

•

Configuration instead of duplication — brand and layout differences are defined through settings, rather than copied screens or components.

•

Controlled flexibility — predefined variants and constraints reduce the risk of an inconsistent interface. Accessibility and quality still require verification.

•

Shared improvements — each capability is built once in the shared platform and made available through parameters or feature flags.

•

One language for design and code — Figma variables, component properties, frontend tokens and constructor schemas describe the same system.

•

Safe evolution — existing clients remain stable while the shared platform continues to improve.

Hypothesis: client forks → shared core + configuration

Before

Client A

own code + own design

Client B

own code + own design

Client C

own code + own design

N independent codebases. Fix ×N. Versions drift; design-system updates take months to reach every brand.

After

Shared core · one maintained version

pages · widgets · variants

config-a.json

tokens

config-b.json

composition · parameters

config-c.json

flags · version

Client = settings on top of the core. Fix ×1 reaches everyone. A flag enables a new capability.

Boolean and text variables for controlling variants

Shared · the same for everyone

  • interaction logic
  • component contracts
  • responsive behaviour
  • platform capabilities

Configurable · defined by configuration

  • visual values
  • allowed composition
  • content and parameters
  • enabled capabilities
  • template and schema version

Goal

Business & product impact

Build an improved, flexible and scalable design system with a Configuration and Operations Workspace that addresses most typical client requests without separate development.

Cover 90–95% of typical client requests through settings

Speed up setups and the addition of platform features

Improve UX and key casino metrics: reg2dep, avg dep, avg bet

One tool for Setup, Live, Product and clients

04

Hypotheses & Goals

Main hypothesis:

Client-specific requests and changes that previously created separate product forks can be anticipated in the design-system architecture.

Design principles:

•

One shared core — all clients use one maintained foundation instead of independent forks.

•

Configuration instead of duplication — brand and layout differences are defined through settings, rather than copied screens or components.

•

Controlled flexibility — predefined variants and constraints reduce the risk of an inconsistent interface. Accessibility and quality still require verification.

•

Shared improvements — each capability is built once in the shared platform and made available through parameters or feature flags.

•

One language for design and code — Figma variables, component properties, frontend tokens and constructor schemas describe the same system.

•

Safe evolution — existing clients remain stable while the shared platform continues to improve.

Hypothesis: client forks → shared core + configuration

Before

Client A

own code + own design

Client B

own code + own design

Client C

own code + own design

N independent codebases. Fix ×N. Versions drift; design-system updates take months to reach every brand.

After

Shared core · one maintained version

pages · widgets · variants

config-a.json

tokens

config-b.json

composition · parameters

config-c.json

flags · version

Client = settings on top of the core. Fix ×1 reaches everyone. A flag enables a new capability.

Boolean and text variables for controlling variants

Shared · the same for everyone

  • interaction logic
  • component contracts
  • responsive behaviour
  • platform capabilities

Configurable · defined by configuration

  • visual values
  • allowed composition
  • content and parameters
  • enabled capabilities
  • template and schema version

Goal

Business & product impact

Build an improved, flexible and scalable design system with a Configuration and Operations Workspace that addresses most typical client requests without separate development.

Cover 90–95% of typical client requests through settings

Speed up setups and the addition of platform features

Improve UX and key casino metrics: reg2dep, avg dep, avg bet

One tool for Setup, Live, Product and clients

04

Hypotheses & Goals

Main hypothesis:

Client-specific requests and changes that previously created separate product forks can be anticipated in the design-system architecture.

Design principles:

•

One shared core — all clients use one maintained foundation instead of independent forks.

•

Configuration instead of duplication — brand and layout differences are defined through settings, rather than copied screens or components.

•

Controlled flexibility — predefined variants and constraints reduce the risk of an inconsistent interface. Accessibility and quality still require verification.

•

Shared improvements — each capability is built once in the shared platform and made available through parameters or feature flags.

•

One language for design and code — Figma variables, component properties, frontend tokens and constructor schemas describe the same system.

•

Safe evolution — existing clients remain stable while the shared platform continues to improve.

Hypothesis: client forks → shared core + configuration

Before

Client A

own code + own design

Client B

own code + own design

Client C

own code + own design

N independent codebases. Fix ×N. Versions drift; design-system updates take months to reach every brand.

After

Shared core · one maintained version

pages · widgets · variants

config-a.json

tokens

config-b.json

composition · parameters

config-c.json

flags · version

Client = settings on top of the core. A fix reaches everyone. A flag enables a new capability.

Boolean and text variables for controlling variants

Shared the same for every brand

  • interaction logic
  • component contracts
  • responsive behaviour
  • platform capabilities

Configurable defined in configuration

  • visual values
  • allowed composition
  • content and parameters
  • enabled capabilities
  • template and schema version

Goal

Business & product impact

Build an improved, flexible and scalable design system with a Configuration and Operations Workspace that addresses most typical client requests without separate development.

Cover 90–95% of typical client requests through settings

Speed up setups and the addition of platform features

Improve UX and key casino metrics: reg2dep, avg dep, avg bet

One tool for Setup, Live, Product and clients

04

Hypotheses & Goals

Main hypothesis:

Client-specific requests and changes that previously created separate product forks can be anticipated in the design-system architecture.

Design principles:

•

One shared core — all clients use one maintained foundation instead of independent forks.

•

Configuration instead of duplication — brand and layout differences are defined through settings, rather than copied screens or components.

•

Controlled flexibility — predefined variants and constraints reduce the risk of an inconsistent interface. Accessibility and quality still require verification.

•

Shared improvements — each capability is built once in the shared platform and made available through parameters or feature flags.

•

One language for design and code — Figma variables, component properties, frontend tokens and constructor schemas describe the same system.

•

Safe evolution — existing clients remain stable while the shared platform continues to improve.

Hypothesis: client forks → shared core + configuration

Before

Client A

own code + own design

Client B

own code + own design

Client C

own code + own design

N independent codebases. Fix ×N. Versions drift; design-system updates take months to reach every brand.

After

Shared core · one maintained version

pages · widgets · variants

config-a.json

tokens

config-b.json

composition · parameters

config-c.json

flags · version

Client = settings on top of the core. A fix reaches everyone. A flag enables a new capability.

Boolean and text variables for controlling variants

Shared the same for every brand

  • interaction logic
  • component contracts
  • responsive behaviour
  • platform capabilities

Configurable defined in configuration

  • visual values
  • allowed composition
  • content and parameters
  • enabled capabilities
  • template and schema version

Goal

Business & product impact

Build an improved, flexible and scalable design system with a Configuration and Operations Workspace that addresses most typical client requests without separate development.

Cover 90–95% of typical client requests through settings

Speed up setups and the addition of platform features

Improve UX and key casino metrics: reg2dep, avg dep, avg bet

One tool for Setup, Live, Product and clients

05

Решения

Почему выбрали веб-конструктор

Изначально мы рассматривали сборку клиентских проектов через связанные библиотеки и конфигурируемые файлы Figma. Подход сохранял общую компонентную основу, но усложнял настройку брендов и управление зависимостями. Поэтому выбрали направление с веб-конструктором: компоненты и виджеты остаются частью общей платформы, а различия между клиентскими сайтами описываются конфигурацией. Это упрощает сетапы и создаёт основу для централизованных обновлений без индивидуальных форков.

От настройки файлов к конфигурации продукта

Отклонено

Конфигурация бренда в Figma

Общая дизайн-система

токены, компоненты и виджеты

↓

Клиентские файлы

копии страниц и переменных бренда

↓

Настройка через JSON

variables и свойства экземпляров

Преимущества: общая компонентная основа, не требуется отдельный веб-конструктор.

Ограничения: многоуровневые зависимости между файлами; настройка бренда требует работы с внутренней структурой Figma.

Выбрано

Конфигурация бренда в веб-конструкторе

Общая дизайн-система

токены, компоненты и виджеты в коде

↓

Веб-конструктор

сборка из виджетов и настройка бренда

↓

Сайт на общей платформе

опубликованная JSON-конфигурация

Преимущества: сборка из готовых виджетов, контролируемые настройки вместо форков, одна реализация для всех клиентских сайтов.

Компромисс: нужны разработка конструктора, проверка конфигураций и управляемая доставка обновлений.

Обновления

общая библиотека → тестирование → релиз платформы → клиентские сайты с сохранением совместимых настроек. Конструктор публикует настройки, релизы платформы доставляют код.

Виджет — готовый блок из компонентов дизайн-системы с заданными вариантами, настройками и правилами размещения. Клиентская конфигурация хранит выбор этих настроек, а сайт использует общую реализацию виджета.

Рабочее пространство конструктора

Основные сценарии Setup-команды
  • Выбрать страницу и настроить готовую основу.
  • Добавить виджеты и настроить варианты в сетке.
  • Применить тему и контент бренда.
  • Проверить desktop, tablet и mobile.
  • Проверять изменения в live-превью.
  • Исправить ограничения и передать конфигурацию в публикацию.
Основные сценарии проджект-менеджера
Управлять несколькими white-label проектами и сетапами.
  • Готовить конфигурации для разных рынков, гео и лицензий.
  • Создавать варианты интерфейса для A/B-тестов.
  • Настраивать аудитории, параметры и сроки экспериментов.
  • Сравнивать результаты разных конфигураций.
  • Отслеживать продуктовые и операционные метрики.
  • Анализировать конверсию, вовлечённость и поведение пользователей.
  • Контролировать статусы тестов, проверок и запусков.
  • Выявлять проблемы и экспортировать условия тз.
  • Управлять ролями, правами доступа и историей изменений.
  • Принимать решения о масштабировании успешных вариантов.

Как решение устроено

Три слоя платформы и рабочее пространство, которое их объединяет.

Архитектура системы: пять уровней

1. Атомы и молекулы

Масштабная дизайн-система: базовые элементы, компоненты, токены и состояния.

2. Организмы и паттерны

Устойчивые интерфейсные комбинации, собранные из базовых компонентов.

↓

3. Виджеты

Функциональные модули с визуальными вариантами, настройками и сценариями размещения в сетке.

↓

4. Визуальный конфигуратор

Веб-интерфейс для гибкой сборки страниц из виджетов: сетки, композиции, параметры и варианты.

5. Операционное пространство

Рабочее пространство объединяет настройку страниц, виджетов и бренда. Управление портфелем проектов, аналитика и эксперименты — возможное развитие за пределами этого кейса.

Дизайн-система должна была работать как продуктовая инфраструктура, а не статичная библиотека компонентов:

Компонент → виджет → конструктор: одна сущность на трёх уровнях

Компонент DS

Button

variant: primary / secondary · size: s / m / l

Card

props: image (bool) · badge (bool)

Переменные

color.bg.accent · radius.md · space.16

Виджет

Hero banner

= Image + Title + Text + Button

Свойства

type: 1…8 · cta.visible · align

Связь с DS

В Figma — связанные инстансы; в продукте — проверка и релиз общей реализации

Конструктор

Сетка 12 колонок

виджет занимает N колонок × M секций

Инспектор

контент · вариант · видимость по устройствам

Экспорт

вся страница = JSON-конфигурация

{ "page": "home", "widgets": [ { "widget": "hero-banner", "type": 3, "span": [12, 2], "props": { "cta": true, "align": "left" } }, { "widget": "games-catalogue", "type": 1, "span": [8, 3] }, { "widget": "live-wins", "type": 2, "span": [4, 3] } ], "theme": "brand-a", "template": "2.4.0" }

Тот же виджет описывается в Figma (варианты и переменные), в коде (пропсы) и в конфигурации (JSON) одними и теми же именами — поэтому его можно копировать между брендами, не отрывая от системы.

Вариант компонента, доступный в Figma, соответствует реализованному варианту и явному, настраиваемому параметру в конструкторе

Пайплайн токенов — единый источник правды

Figma Variables

primitive → semantic → component; режимы = бренды

→

Tokens JSON

автоэкспорт из Figma, одно имя на всех уровнях

→

Код

CSS-переменные и тема компонентов

→

Схема конструктора

theme + параметры виджетов, валидация

→

Бренд A · B · C

конфигурация поверх ядра, без форка

Правило

Семантический токен сохраняет одну роль в Figma и коде. Значение может отличаться между брендами и темами. Ошибка — несоответствие внутри одной конфигурации, а не сам факт различия значений.

Альтернатива: настройка через библиотеки Figma

Как выглядела отклонённая модель: варианты организации библиотек в Figma — «всё в одном файле» и foundations + семантическая библиотека.

Структура дизайн-системы в Figma: foundations → визуальные значения → бренды

Foundations · один источник правды

Basic components

кнопки, поля, карточки — на семантических токенах

библиотека · публикуется в team

Section components

hero, каталог, промо, турниры — собраны из basic

библиотека · публикуется в team

Pages

home, lobby, game page — композиция секций

библиотека · публикуется в team

↓

инстансы + переменные · бренд подключает библиотеку, а не копирует её

Visual values · Бренд A

режим переменных: цвета, шрифты, радиусы, логотип

файл значений · режим переменных бренда

→

Casino #1

продукт бренда: страницы из foundations + свои значения

файл продукта · подключает foundations + значения

Visual values · Бренд B

режим переменных: цвета, шрифты, радиусы, логотип

файл значений · режим переменных бренда

→

Casino #2

продукт бренда: страницы из foundations + свои значения

файл продукта · подключает foundations + значения

Принцип

Одна библиотека — много идентичностей. Общими остаются компоненты и контракты. Тема и разрешённая композиция настраиваются для каждого бренда.

All in one file approach

All in one file

Core foundations

Color

Spacing

Typography

Layout

Semantic design tokens

Бренд A

Бренд B

Card

Dropdown

Teaser

Components

Every component is in separate file

All components in one file

Foundations + Semantic Library

Brand foundations

Color

Spacing

Typography

Layout

Brand semantic tokens

Theme 1

Theme 2

Atoms

Molecules

Organisms

File 1

File 2

Files

Альтернатива: настройка доставки фичей

копируем файл заново

компоненты и апдейты

копируем файл

Variables and styles

+ иконки и картинки

Components file

мастер-компоненты

Pages file (instances)

+ иконки и картинки

Variables and styles

подключены по ссылке

Variables and styles

+ иконки и картинки

Components file

мастер-компоненты

Pages file (instances)

+ иконки и картинки

Variables and styles

new

Variables and styles

old

стили и переменные

стили и переменные

стили и переменные

новые фичи

выгрузка JSON

замена на новый файл

Новая фича без новых стилей

Файлы шаблона

Файлы Сетапа

Новая фича + новые стили

Файлы шаблона

Файлы Сетапа

Технически схема работоспособна: мы собрали её MVP. Файлы копируются, бренд остаётся привязанным к компонентам, поэтому их можно править, а значения новых вариантов задаются булевыми свойствами. Ограничение в самой Figma: обновления не проходят автоматически через несколько уровней вложенных компонентов, и каждый апдейт приходится доставлять вручную. Архитектуру можно построить, но она сложна и держится на ручной синхронизации.

05

Решения

Почему выбрали веб-конструктор

Изначально мы рассматривали сборку клиентских проектов через связанные библиотеки и конфигурируемые файлы Figma. Подход сохранял общую компонентную основу, но усложнял настройку брендов и управление зависимостями. Поэтому выбрали направление с веб-конструктором: компоненты и виджеты остаются частью общей платформы, а различия между клиентскими сайтами описываются конфигурацией. Это упрощает сетапы и создаёт основу для централизованных обновлений без индивидуальных форков.

От настройки файлов к конфигурации продукта

Отклонено

Конфигурация бренда в Figma

Общая дизайн-система

токены, компоненты и виджеты

↓

Клиентские файлы

копии страниц и переменных бренда

↓

Настройка через JSON

variables и свойства экземпляров

Преимущества: общая компонентная основа, не требуется отдельный веб-конструктор.

Ограничения: многоуровневые зависимости между файлами; настройка бренда требует работы с внутренней структурой Figma.

Выбрано

Конфигурация бренда в веб-конструкторе

Общая дизайн-система

токены, компоненты и виджеты в коде

↓

Веб-конструктор

сборка из виджетов и настройка бренда

↓

Сайт на общей платформе

опубликованная JSON-конфигурация

Преимущества: сборка из готовых виджетов, контролируемые настройки вместо форков, одна реализация для всех клиентских сайтов.

Компромисс: нужны разработка конструктора, проверка конфигураций и управляемая доставка обновлений.

Обновления

общая библиотека → тестирование → релиз платформы → клиентские сайты с сохранением совместимых настроек. Конструктор публикует настройки, релизы платформы доставляют код.

Виджет — готовый блок из компонентов дизайн-системы с заданными вариантами, настройками и правилами размещения. Клиентская конфигурация хранит выбор этих настроек, а сайт использует общую реализацию виджета.

Рабочее пространство конструктора

Основные сценарии Setup-команды
  • Выбрать страницу и настроить готовую основу.
  • Добавить виджеты и настроить варианты в сетке.
  • Применить тему и контент бренда.
  • Проверить desktop, tablet и mobile.
  • Проверять изменения в live-превью.
  • Исправить ограничения и передать конфигурацию в публикацию.
Основные сценарии проджект-менеджера
Управлять несколькими white-label проектами и сетапами.
  • Готовить конфигурации для разных рынков, гео и лицензий.
  • Создавать варианты интерфейса для A/B-тестов.
  • Настраивать аудитории, параметры и сроки экспериментов.
  • Сравнивать результаты разных конфигураций.
  • Отслеживать продуктовые и операционные метрики.
  • Анализировать конверсию, вовлечённость и поведение пользователей.
  • Контролировать статусы тестов, проверок и запусков.
  • Выявлять проблемы и экспортировать условия тз.
  • Управлять ролями, правами доступа и историей изменений.
  • Принимать решения о масштабировании успешных вариантов.

Как решение устроено

Три слоя платформы и рабочее пространство, которое их объединяет.

Архитектура системы: пять уровней

1. Атомы и молекулы

Масштабная дизайн-система: базовые элементы, компоненты, токены и состояния.

2. Организмы и паттерны

Устойчивые интерфейсные комбинации, собранные из базовых компонентов.

↓

3. Виджеты

Функциональные модули с визуальными вариантами, настройками и сценариями размещения в сетке.

↓

4. Визуальный конфигуратор

Веб-интерфейс для гибкой сборки страниц из виджетов: сетки, композиции, параметры и варианты.

5. Операционное пространство

Рабочее пространство объединяет настройку страниц, виджетов и бренда. Управление портфелем проектов, аналитика и эксперименты — возможное развитие за пределами этого кейса.

Дизайн-система должна была работать как продуктовая инфраструктура, а не статичная библиотека компонентов:

Компонент → виджет → конструктор: одна сущность на трёх уровнях

Компонент DS

Button

variant: primary / secondary · size: s / m / l

Card

props: image (bool) · badge (bool)

Переменные

color.bg.accent · radius.md · space.16

Виджет

Hero banner

= Image + Title + Text + Button

Свойства

type: 1…8 · cta.visible · align

Связь с DS

В Figma — связанные инстансы; в продукте — проверка и релиз общей реализации

Конструктор

Сетка 12 колонок

виджет занимает N колонок × M секций

Инспектор

контент · вариант · видимость по устройствам

Экспорт

вся страница = JSON-конфигурация

{ "page": "home", "widgets": [ { "widget": "hero-banner", "type": 3, "span": [12, 2], "props": { "cta": true, "align": "left" } }, { "widget": "games-catalogue", "type": 1, "span": [8, 3] }, { "widget": "live-wins", "type": 2, "span": [4, 3] } ], "theme": "brand-a", "template": "2.4.0" }

Тот же виджет описывается в Figma (варианты и переменные), в коде (пропсы) и в конфигурации (JSON) одними и теми же именами — поэтому его можно копировать между брендами, не отрывая от системы.

Вариант компонента, доступный в Figma, соответствует реализованному варианту и явному, настраиваемому параметру в конструкторе

Пайплайн токенов — единый источник правды

Figma Variables

primitive → semantic → component; режимы = бренды

→

Tokens JSON

автоэкспорт из Figma, одно имя на всех уровнях

→

Код

CSS-переменные и тема компонентов

→

Схема конструктора

theme + параметры виджетов, валидация

→

Бренд A · B · C

конфигурация поверх ядра, без форка

Правило

Семантический токен сохраняет одну роль в Figma и коде. Значение может отличаться между брендами и темами. Ошибка — несоответствие внутри одной конфигурации, а не сам факт различия значений.

Альтернатива: настройка через библиотеки Figma

Как выглядела отклонённая модель: варианты организации библиотек в Figma — «всё в одном файле» и foundations + семантическая библиотека.

Структура дизайн-системы в Figma: foundations → визуальные значения → бренды

Foundations · один источник правды

Basic components

кнопки, поля, карточки — на семантических токенах

библиотека · публикуется в team

Section components

hero, каталог, промо, турниры — собраны из basic

библиотека · публикуется в team

Pages

home, lobby, game page — композиция секций

библиотека · публикуется в team

↓

инстансы + переменные · бренд подключает библиотеку, а не копирует её

Visual values · Бренд A

режим переменных: цвета, шрифты, радиусы, логотип

файл значений · режим переменных бренда

→

Casino #1

продукт бренда: страницы из foundations + свои значения

файл продукта · подключает foundations + значения

Visual values · Бренд B

режим переменных: цвета, шрифты, радиусы, логотип

файл значений · режим переменных бренда

→

Casino #2

продукт бренда: страницы из foundations + свои значения

файл продукта · подключает foundations + значения

Принцип

Одна библиотека — много идентичностей. Общими остаются компоненты и контракты. Тема и разрешённая композиция настраиваются для каждого бренда.

All in one file approach

All in one file

Core foundations

Color

Spacing

Typography

Layout

Semantic design tokens

Бренд A

Бренд B

Card

Dropdown

Teaser

Components

Every component is in separate file

All components in one file

Foundations + Semantic Library

Brand foundations

Color

Spacing

Typography

Layout

Brand semantic tokens

Theme 1

Theme 2

Atoms

Molecules

Organisms

File 1

File 2

Files

Альтернатива: настройка доставки фичей

копируем файл заново

компоненты и апдейты

копируем файл

Variables and styles

+ иконки и картинки

Components file

мастер-компоненты

Pages file (instances)

+ иконки и картинки

Variables and styles

подключены по ссылке

Variables and styles

+ иконки и картинки

Components file

мастер-компоненты

Pages file (instances)

+ иконки и картинки

Variables and styles

new

Variables and styles

old

стили и переменные

стили и переменные

стили и переменные

новые фичи

выгрузка JSON

замена на новый файл

Новая фича без новых стилей

Файлы шаблона

Файлы Сетапа

Новая фича + новые стили

Файлы шаблона

Файлы Сетапа

Технически схема работоспособна: мы собрали её MVP. Файлы копируются, бренд остаётся привязанным к компонентам, поэтому их можно править, а значения новых вариантов задаются булевыми свойствами. Ограничение в самой Figma: обновления не проходят автоматически через несколько уровней вложенных компонентов, и каждый апдейт приходится доставлять вручную. Архитектуру можно построить, но она сложна и держится на ручной синхронизации.

05

Решения

Почему выбрали веб-конструктор

Изначально мы рассматривали сборку клиентских проектов через связанные библиотеки и конфигурируемые файлы Figma. Подход сохранял общую компонентную основу, но усложнял настройку брендов и управление зависимостями. Поэтому выбрали направление с веб-конструктором: компоненты и виджеты остаются частью общей платформы, а различия между клиентскими сайтами описываются конфигурацией. Это упрощает сетапы и создаёт основу для централизованных обновлений без индивидуальных форков.

От настройки файлов к конфигурации продукта

Отклонено

Конфигурация бренда в Figma

Общая дизайн-система

токены, компоненты и виджеты

↓

Клиентские файлы

копии страниц и переменных бренда

↓

Настройка через JSON

variables и свойства экземпляров

Преимущества: общая компонентная основа, не требуется отдельный веб-конструктор.

Ограничения: многоуровневые зависимости между файлами; настройка бренда требует работы с внутренней структурой Figma.

Выбрано

Конфигурация бренда в веб-конструкторе

Общая дизайн-система

токены, компоненты и виджеты в коде

↓

Веб-конструктор

сборка из виджетов и настройка бренда

↓

Сайт на общей платформе

опубликованная JSON-конфигурация

Преимущества: сборка из готовых виджетов, контролируемые настройки вместо форков, одна реализация для всех клиентских сайтов.

Компромисс: нужны разработка конструктора, проверка конфигураций и управляемая доставка обновлений.

Обновления

общая библиотека → тестирование → релиз платформы → клиентские сайты с сохранением совместимых настроек. Конструктор публикует настройки, релизы платформы доставляют код.

Виджет — готовый блок из компонентов дизайн-системы с заданными вариантами, настройками и правилами размещения. Клиентская конфигурация хранит выбор этих настроек, а сайт использует общую реализацию виджета.

Рабочее пространство конструктора

Основные сценарии Setup-команды
  • Выбрать страницу и настроить готовую основу.
  • Добавить виджеты и настроить варианты в сетке.
  • Применить тему и контент бренда.
  • Проверить desktop, tablet и mobile.
  • Проверять изменения в live-превью.
  • Исправить ограничения и передать конфигурацию в публикацию.
Основные сценарии проджект-менеджера
Управлять несколькими white-label проектами и сетапами.
  • Готовить конфигурации для разных рынков, гео и лицензий.
  • Создавать варианты интерфейса для A/B-тестов.
  • Настраивать аудитории, параметры и сроки экспериментов.
  • Сравнивать результаты разных конфигураций.
  • Отслеживать продуктовые и операционные метрики.
  • Анализировать конверсию, вовлечённость и поведение пользователей.
  • Контролировать статусы тестов, проверок и запусков.
  • Выявлять проблемы и экспортировать условия тз.
  • Управлять ролями, правами доступа и историей изменений.
  • Принимать решения о масштабировании успешных вариантов.

Как решение устроено

Три слоя платформы и рабочее пространство, которое их объединяет.

Архитектура системы: пять уровней

1. Атомы и молекулы

Масштабная дизайн-система: базовые элементы, компоненты, токены и состояния.

2. Организмы и паттерны

Устойчивые интерфейсные комбинации, собранные из базовых компонентов.

↓

3. Виджеты

Функциональные модули с визуальными вариантами, настройками и сценариями размещения в сетке.

↓

4. Визуальный конфигуратор

Веб-интерфейс для гибкой сборки страниц из виджетов: сетки, композиции, параметры и варианты.

5. Операционное пространство

Рабочее пространство объединяет настройку страниц, виджетов и бренда. Управление портфелем проектов, аналитика и эксперименты — возможное развитие за пределами этого кейса.

Дизайн-система должна была работать как продуктовая инфраструктура, а не статичная библиотека компонентов:

Компонент → виджет → конструктор: одна сущность на трёх уровнях

Компонент DS

Button

variant: primary / secondary · size: s / m / l

Card

props: image (bool) · badge (bool)

Переменные

color.bg.accent · radius.md · space.16

Виджет

Hero banner

= Image + Title + Text + Button

Свойства

type: 1…8 · cta.visible · align

Связь с DS

В Figma — связанные инстансы; в продукте — проверка и релиз общей реализации

Конструктор

Сетка 12 колонок

виджет занимает N колонок × M секций

Инспектор

контент · вариант · видимость по устройствам

Экспорт

вся страница = JSON-конфигурация

{ "page": "home", "widgets": [ { "widget": "hero-banner", "type": 3, "span": [12, 2], "props": { "cta": true, "align": "left" } }, { "widget": "games-catalogue", "type": 1, "span": [8, 3] }, { "widget": "live-wins", "type": 2, "span": [4, 3] } ], "theme": "brand-a", "template": "2.4.0" }

Тот же виджет описывается в Figma (варианты и переменные), в коде (пропсы) и в конфигурации (JSON) одними и теми же именами — поэтому его можно копировать между брендами, не отрывая от системы.

Вариант компонента, доступный в Figma, соответствует реализованному варианту и явному, настраиваемому параметру в конструкторе

Пайплайн токенов — единый источник правды

Figma Variables

primitive → semantic → component; режимы = бренды

↓

Tokens JSON

автоэкспорт из Figma, одно имя на всех уровнях

↓

Код

CSS-переменные и тема компонентов

↓

Схема конструктора

theme + параметры виджетов, валидация

↓

Бренд A · B · C

конфигурация поверх ядра, без форка

Правило

Семантический токен сохраняет одну роль в Figma и коде. Значение может отличаться между брендами и темами. Ошибка — несоответствие внутри одной конфигурации, а не сам факт различия значений.

Альтернатива: настройка через библиотеки Figma

Как выглядела отклонённая модель: варианты организации библиотек в Figma — «всё в одном файле» и foundations + семантическая библиотека.

Структура дизайн-системы в Figma: foundations → визуальные значения → бренды

Foundations · один источник правды

Basic components

кнопки, поля, карточки — на семантических токенах

библиотека · публикуется в team

Section components

hero, каталог, промо, турниры — собраны из basic

библиотека · публикуется в team

Pages

home, lobby, game page — композиция секций

библиотека · публикуется в team

↓

инстансы + переменные · бренд подключает библиотеку, а не копирует её

Visual values · Бренд A

режим переменных: цвета, шрифты, радиусы, логотип

файл значений · режим переменных бренда

→

Casino #1

продукт бренда: страницы из foundations + свои значения

файл продукта · подключает foundations + значения

Visual values · Бренд B

режим переменных: цвета, шрифты, радиусы, логотип

файл значений · режим переменных бренда

→

Casino #2

продукт бренда: страницы из foundations + свои значения

файл продукта · подключает foundations + значения

Принцип

Одна библиотека — много идентичностей. Общими остаются компоненты и контракты. Тема и разрешённая композиция настраиваются для каждого бренда.

All in one file approach

All in one file

Core foundations

Color

Spacing

Typography

Layout

Semantic design tokens

Бренд A

Бренд B

Every component is in separate file

Card

Dropdown

Teaser

All components in one file

Components

Foundations + Semantic Library

File 1

Brand foundations

Color

Spacing

Typography

Layout

File 2

Brand semantic tokens

Theme 1

Theme 2

Files

Atoms

Molecules

Organisms

Альтернатива: настройка доставки фичей

Variables and styles

+ иконки и картинки

Components file

мастер-компоненты

Pages file (instances)

+ иконки и картинки

Variables and styles

подключены по ссылке

Variables and styles

+ иконки и картинки

Components file

мастер-компоненты

Pages file (instances)

+ иконки и картинки

Variables and styles

new

Variables and styles

old

стили и переменные

компоненты и апдейты

стили и переменные

копируем файл

стили и переменные

новые фичи

копируем файл заново

выгрузка JSON

замена на новый файл

Новая фича без новых стилей

Файлы шаблона

Файлы Сетапа

Новая фича + новые стили

Файлы шаблона

Файлы Сетапа

Технически схема работоспособна: мы собрали её MVP. Файлы копируются, бренд остаётся привязанным к компонентам, поэтому их можно править, а значения новых вариантов задаются булевыми свойствами. Ограничение в самой Figma: обновления не проходят автоматически через несколько уровней вложенных компонентов, и каждый апдейт приходится доставлять вручную. Архитектуру можно построить, но она сложна и держится на ручной синхронизации.

05

Решения

Почему выбрали веб-конструктор

Изначально мы рассматривали сборку клиентских проектов через связанные библиотеки и конфигурируемые файлы Figma. Подход сохранял общую компонентную основу, но усложнял настройку брендов и управление зависимостями. Поэтому выбрали направление с веб-конструктором: компоненты и виджеты остаются частью общей платформы, а различия между клиентскими сайтами описываются конфигурацией. Это упрощает сетапы и создаёт основу для централизованных обновлений без индивидуальных форков.

От настройки файлов к конфигурации продукта

Отклонено

Конфигурация бренда в Figma

Общая дизайн-система

токены, компоненты и виджеты

↓

Клиентские файлы

копии страниц и переменных бренда

↓

Настройка через JSON

variables и свойства экземпляров

Преимущества: общая компонентная основа, не требуется отдельный веб-конструктор.

Ограничения: многоуровневые зависимости между файлами; настройка бренда требует работы с внутренней структурой Figma.

Выбрано

Конфигурация бренда в веб-конструкторе

Общая дизайн-система

токены, компоненты и виджеты в коде

↓

Веб-конструктор

сборка из виджетов и настройка бренда

↓

Сайт на общей платформе

опубликованная JSON-конфигурация

Преимущества: сборка из готовых виджетов, контролируемые настройки вместо форков, одна реализация для всех клиентских сайтов.

Компромисс: нужны разработка конструктора, проверка конфигураций и управляемая доставка обновлений.

Обновления

общая библиотека → тестирование → релиз платформы → клиентские сайты с сохранением совместимых настроек. Конструктор публикует настройки, релизы платформы доставляют код.

Виджет — готовый блок из компонентов дизайн-системы с заданными вариантами, настройками и правилами размещения. Клиентская конфигурация хранит выбор этих настроек, а сайт использует общую реализацию виджета.

Рабочее пространство конструктора

Основные сценарии Setup-команды
  • Выбрать страницу и настроить готовую основу.
  • Добавить виджеты и настроить варианты в сетке.
  • Применить тему и контент бренда.
  • Проверить desktop, tablet и mobile.
  • Проверять изменения в live-превью.
  • Исправить ограничения и передать конфигурацию в публикацию.
Основные сценарии проджект-менеджера
Управлять несколькими white-label проектами и сетапами.
  • Готовить конфигурации для разных рынков, гео и лицензий.
  • Создавать варианты интерфейса для A/B-тестов.
  • Настраивать аудитории, параметры и сроки экспериментов.
  • Сравнивать результаты разных конфигураций.
  • Отслеживать продуктовые и операционные метрики.
  • Анализировать конверсию, вовлечённость и поведение пользователей.
  • Контролировать статусы тестов, проверок и запусков.
  • Выявлять проблемы и экспортировать условия тз.
  • Управлять ролями, правами доступа и историей изменений.
  • Принимать решения о масштабировании успешных вариантов.

Как решение устроено

Три слоя платформы и рабочее пространство, которое их объединяет.

Архитектура системы: пять уровней

1. Атомы и молекулы

Масштабная дизайн-система: базовые элементы, компоненты, токены и состояния.

2. Организмы и паттерны

Устойчивые интерфейсные комбинации, собранные из базовых компонентов.

↓

3. Виджеты

Функциональные модули с визуальными вариантами, настройками и сценариями размещения в сетке.

↓

4. Визуальный конфигуратор

Веб-интерфейс для гибкой сборки страниц из виджетов: сетки, композиции, параметры и варианты.

5. Операционное пространство

Рабочее пространство объединяет настройку страниц, виджетов и бренда. Управление портфелем проектов, аналитика и эксперименты — возможное развитие за пределами этого кейса.

Дизайн-система должна была работать как продуктовая инфраструктура, а не статичная библиотека компонентов:

Компонент → виджет → конструктор: одна сущность на трёх уровнях

Компонент DS

Button

variant: primary / secondary · size: s / m / l

Card

props: image (bool) · badge (bool)

Переменные

color.bg.accent · radius.md · space.16

Виджет

Hero banner

= Image + Title + Text + Button

Свойства

type: 1…8 · cta.visible · align

Связь с DS

В Figma — связанные инстансы; в продукте — проверка и релиз общей реализации

Конструктор

Сетка 12 колонок

виджет занимает N колонок × M секций

Инспектор

контент · вариант · видимость по устройствам

Экспорт

вся страница = JSON-конфигурация

{ "page": "home", "widgets": [ { "widget": "hero-banner", "type": 3, "span": [12, 2], "props": { "cta": true, "align": "left" } }, { "widget": "games-catalogue", "type": 1, "span": [8, 3] }, { "widget": "live-wins", "type": 2, "span": [4, 3] } ], "theme": "brand-a", "template": "2.4.0" }

Тот же виджет описывается в Figma (варианты и переменные), в коде (пропсы) и в конфигурации (JSON) одними и теми же именами — поэтому его можно копировать между брендами, не отрывая от системы.

Вариант компонента, доступный в Figma, соответствует реализованному варианту и явному, настраиваемому параметру в конструкторе

Пайплайн токенов — единый источник правды

Figma Variables

primitive → semantic → component; режимы = бренды

↓

Tokens JSON

автоэкспорт из Figma, одно имя на всех уровнях

↓

Код

CSS-переменные и тема компонентов

↓

Схема конструктора

theme + параметры виджетов, валидация

↓

Бренд A · B · C

конфигурация поверх ядра, без форка

Правило

Семантический токен сохраняет одну роль в Figma и коде. Значение может отличаться между брендами и темами. Ошибка — несоответствие внутри одной конфигурации, а не сам факт различия значений.

Альтернатива: настройка через библиотеки Figma

Как выглядела отклонённая модель: варианты организации библиотек в Figma — «всё в одном файле» и foundations + семантическая библиотека.

Структура дизайн-системы в Figma: foundations → визуальные значения → бренды

Foundations · один источник правды

Basic components

кнопки, поля, карточки — на семантических токенах

библиотека · публикуется в team

Section components

hero, каталог, промо, турниры — собраны из basic

библиотека · публикуется в team

Pages

home, lobby, game page — композиция секций

библиотека · публикуется в team

↓

инстансы + переменные · бренд подключает библиотеку, а не копирует её

Visual values · Бренд A

режим переменных: цвета, шрифты, радиусы, логотип

файл значений · режим переменных бренда

→

Casino #1

продукт бренда: страницы из foundations + свои значения

файл продукта · подключает foundations + значения

Visual values · Бренд B

режим переменных: цвета, шрифты, радиусы, логотип

файл значений · режим переменных бренда

→

Casino #2

продукт бренда: страницы из foundations + свои значения

файл продукта · подключает foundations + значения

Принцип

Одна библиотека — много идентичностей. Общими остаются компоненты и контракты. Тема и разрешённая композиция настраиваются для каждого бренда.

All in one file approach

All in one file

Core foundations

Color

Spacing

Typography

Layout

Semantic design tokens

Бренд A

Бренд B

Every component is in separate file

Card

Dropdown

Teaser

All components in one file

Components

Foundations + Semantic Library

File 1

Brand foundations

Color

Spacing

Typography

Layout

File 2

Brand semantic tokens

Theme 1

Theme 2

Files

Atoms

Molecules

Organisms

Альтернатива: настройка доставки фичей

Variables and styles

+ иконки и картинки

Components file

мастер-компоненты

Pages file (instances)

+ иконки и картинки

Variables and styles

подключены по ссылке

Variables and styles

+ иконки и картинки

Components file

мастер-компоненты

Pages file (instances)

+ иконки и картинки

Variables and styles

new

Variables and styles

old

стили и переменные

компоненты и апдейты

стили и переменные

копируем файл

стили и переменные

новые фичи

копируем файл заново

выгрузка JSON

замена на новый файл

Новая фича без новых стилей

Файлы шаблона

Файлы Сетапа

Новая фича + новые стили

Файлы шаблона

Файлы Сетапа

Технически схема работоспособна: мы собрали её MVP. Файлы копируются, бренд остаётся привязанным к компонентам, поэтому их можно править, а значения новых вариантов задаются булевыми свойствами. Ограничение в самой Figma: обновления не проходят автоматически через несколько уровней вложенных компонентов, и каждый апдейт приходится доставлять вручную. Архитектуру можно построить, но она сложна и держится на ручной синхронизации.

05

Decisions

Why we chose a web constructor

We initially considered assembling client projects through linked libraries and configurable Figma files. This preserved a shared component foundation, but made brand configuration and dependency management more complex. We chose a web constructor: components and widgets remain part of the shared platform, while configuration describes differences between client websites. This simplifies setup and provides a foundation for centralized updates without individual forks.

From configuring files to configuring a product

Rejected

Brand configuration in Figma

Shared design system

tokens, components and widgets

↓

Client files

copies of pages and brand variables

↓

Configuration through JSON

variables and instance properties

Benefits: a shared component foundation, with no separate web constructor required.

Limitations: multilevel dependencies between files; brand configuration requires working with Figma’s internal structure.

Chosen

Brand configuration in the web constructor

Shared design system

tokens, components and widgets in code

↓

Web constructor

widget-based assembly and brand configuration

↓

Website on the shared platform

published JSON configuration

Benefits: assembly from ready-made widgets, controlled settings instead of forks, and one implementation for all client sites.

Trade-off: requires constructor development, configuration validation and controlled delivery of updates.

Updates

shared library → testing → platform release → client websites with compatible settings preserved. The constructor publishes settings; platform releases deliver code.

A widget is a ready-made block of design-system components with defined variants, settings and placement rules. The client configuration stores those choices, while the website uses the shared widget implementation.

Constructor workspace

Core setup-team workflows
  • Select a page and configure a ready-made foundation.
  • Add widgets and configure variants in the grid.
  • Apply the brand theme and content.
  • Check desktop, tablet and mobile.
  • Review changes in the live preview.
  • Resolve constraint violations and submit the configuration for publishing.
Core project-manager workflows
Manage multiple white-label projects and setups.
  • Prepare configurations for different markets, regions and licences.
  • Create interface variants for A/B tests.
  • Set experiment audiences, parameters and schedules.
  • Compare results across configurations.
  • Monitor product and operational metrics.
  • Analyse conversion, engagement and user behaviour.
  • Track the status of tests, reviews and launches.
  • Identify issues and export requirements.
  • Manage roles, permissions and change history.
  • Decide which successful variants to scale.

How the solution works

Three platform layers and the workspace that connects them.

System architecture: five levels

1. Atoms and molecules

A large design system: foundations, components, tokens and states.

2. Organisms and patterns

Stable interface patterns assembled from foundational components.

↓

3. Widgets

Functional modules with visual variants, settings and grid-placement scenarios.

↓

4. Visual configurator

A web interface for composing pages from widgets: grids, composition, parameters and variants.

5. Operations workspace

The workspace combines page, widget and brand configuration. Portfolio management, analytics and experiments are potential developments beyond this case.

The design system needed to work as product infrastructure, rather than a static component library:

Component → widget → constructor: one entity at three levels

DS component

Button

variant: primary / secondary · size: s / m / l

Card

props: image (bool) · badge (bool)

Variables

color.bg.accent · radius.md · space.16

Widget

Hero banner

= Image + Title + Text + Button

Properties

type: 1…8 · cta.visible · align

Connection to the DS

Linked instances in Figma; a reviewed, released shared implementation in the product

Constructor

12-column grid

widget spans N columns × M sections

Inspector

content · variant · device visibility

Export

whole page = JSON configuration

{ "page": "home", "widgets": [ { "widget": "hero-banner", "type": 3, "span": [12, 2], "props": { "cta": true, "align": "left" } }, { "widget": "games-catalogue", "type": 1, "span": [8, 3] }, { "widget": "live-wins", "type": 2, "span": [4, 3] } ], "theme": "brand-a", "template": "2.4.0" }

The same widget uses the same names in Figma (variants and variables), code (props) and configuration (JSON), so it can move between brands while staying connected to the system.

A component variant available in Figma maps to an implemented variant and an explicit, configurable constructor parameter

Token pipeline — one source of truth

Figma Variables

primitive → semantic → component; modes = brands

→

Tokens JSON

automatic Figma export, one name at every level

→

Code

CSS variables and component theme

→

Constructor schema

theme + widget parameters, validation

→

Brand A · B · C

configuration on top of the core, without a fork

Rule

A semantic token keeps the same role in Figma and code. Values may differ across brands and themes. A mismatch within one configuration is an error; differing values alone are not.

Alternative: configuration through Figma libraries

The rejected model: Figma library structures — all in one file, or foundations + a semantic library.

Design-system structure in Figma: foundations → visual values → brands

Foundations · one source of truth

Basic components

buttons, fields, cards — built on semantic tokens

library · published to the team

Section components

hero, catalogue, promotions, tournaments — built from basic components

library · published to the team

Pages

home, lobby, game page — section compositions

library · published to the team

↓

instances + variables · the brand connects to the library instead of copying it

Visual values · Brand A

variable mode: colors, fonts, radii, logo

values file · brand variable mode

→

Casino #1

brand product: foundation pages + its own values

product file · connects foundations + values

Visual values · Brand B

variable mode: colors, fonts, radii, logo

values file · brand variable mode

→

Casino #2

brand product: foundation pages + its own values

product file · connects foundations + values

Principle

One library, many identities. Components and contracts stay shared. The theme and permitted composition are configured for each brand.

All in one file approach

All in one file

Core foundations

Color

Spacing

Typography

Layout

Semantic design tokens

Brand A

Brand B

Card

Dropdown

Teaser

Components

Every component is in separate file

All components in one file

Foundations + Semantic Library

Brand foundations

Color

Spacing

Typography

Layout

Brand semantic tokens

Theme 1

Theme 2

Atoms

Molecules

Organisms

File 1

File 2

Files

Alternative: configuring feature delivery

copy the file again

components and updates

copy the file

Variables and styles

+ icons and images

Components file

master components

Pages file (instances)

+ icons and images

Variables and styles

linked by reference

Variables and styles

+ icons and images

Components file

master components

Pages file (instances)

+ icons and images

Variables and styles

new

Variables and styles

old

styles and variables

styles and variables

styles and variables

new features

JSON export

replaced by new file

New feature without new styles

Template files

Setup files

New feature + new styles

Template files

Setup files

Technically the scheme works: we built an MVP of it. Files are copied while the brand stays bound to the components, so they remain editable, and new variant values are set through boolean properties. The limit is Figma itself: updates do not propagate automatically through several levels of nested components, so every update has to be carried across by hand. The architecture can be built, but it is complex and rests on manual synchronisation.

05

Decisions

Why we chose a web constructor

We initially considered assembling client projects through linked libraries and configurable Figma files. This preserved a shared component foundation, but made brand configuration and dependency management more complex. We chose a web constructor: components and widgets remain part of the shared platform, while configuration describes differences between client websites. This simplifies setup and provides a foundation for centralized updates without individual forks.

From configuring files to configuring a product

Rejected

Brand configuration in Figma

Shared design system

tokens, components and widgets

↓

Client files

copies of pages and brand variables

↓

Configuration through JSON

variables and instance properties

Benefits: a shared component foundation, with no separate web constructor required.

Limitations: multilevel dependencies between files; brand configuration requires working with Figma’s internal structure.

Chosen

Brand configuration in the web constructor

Shared design system

tokens, components and widgets in code

↓

Web constructor

widget-based assembly and brand configuration

↓

Website on the shared platform

published JSON configuration

Benefits: assembly from ready-made widgets, controlled settings instead of forks, and one implementation for all client sites.

Trade-off: requires constructor development, configuration validation and controlled delivery of updates.

Updates

shared library → testing → platform release → client websites with compatible settings preserved. The constructor publishes settings; platform releases deliver code.

A widget is a ready-made block of design-system components with defined variants, settings and placement rules. The client configuration stores those choices, while the website uses the shared widget implementation.

Constructor workspace

Core setup-team workflows
  • Select a page and configure a ready-made foundation.
  • Add widgets and configure variants in the grid.
  • Apply the brand theme and content.
  • Check desktop, tablet and mobile.
  • Review changes in the live preview.
  • Resolve constraint violations and submit the configuration for publishing.
Core project-manager workflows
Manage multiple white-label projects and setups.
  • Prepare configurations for different markets, regions and licences.
  • Create interface variants for A/B tests.
  • Set experiment audiences, parameters and schedules.
  • Compare results across configurations.
  • Monitor product and operational metrics.
  • Analyse conversion, engagement and user behaviour.
  • Track the status of tests, reviews and launches.
  • Identify issues and export requirements.
  • Manage roles, permissions and change history.
  • Decide which successful variants to scale.

How the solution works

Three platform layers and the workspace that connects them.

System architecture: five levels

1. Atoms and molecules

A large design system: foundations, components, tokens and states.

2. Organisms and patterns

Stable interface patterns assembled from foundational components.

↓

3. Widgets

Functional modules with visual variants, settings and grid-placement scenarios.

↓

4. Visual configurator

A web interface for composing pages from widgets: grids, composition, parameters and variants.

5. Operations workspace

The workspace combines page, widget and brand configuration. Portfolio management, analytics and experiments are potential developments beyond this case.

The design system needed to work as product infrastructure, rather than a static component library:

Component → widget → constructor: one entity at three levels

DS component

Button

variant: primary / secondary · size: s / m / l

Card

props: image (bool) · badge (bool)

Variables

color.bg.accent · radius.md · space.16

Widget

Hero banner

= Image + Title + Text + Button

Properties

type: 1…8 · cta.visible · align

Connection to the DS

Linked instances in Figma; a reviewed, released shared implementation in the product

Constructor

12-column grid

widget spans N columns × M sections

Inspector

content · variant · device visibility

Export

whole page = JSON configuration

{ "page": "home", "widgets": [ { "widget": "hero-banner", "type": 3, "span": [12, 2], "props": { "cta": true, "align": "left" } }, { "widget": "games-catalogue", "type": 1, "span": [8, 3] }, { "widget": "live-wins", "type": 2, "span": [4, 3] } ], "theme": "brand-a", "template": "2.4.0" }

The same widget uses the same names in Figma (variants and variables), code (props) and configuration (JSON), so it can move between brands while staying connected to the system.

A component variant available in Figma maps to an implemented variant and an explicit, configurable constructor parameter

Token pipeline — one source of truth

Figma Variables

primitive → semantic → component; modes = brands

→

Tokens JSON

automatic Figma export, one name at every level

→

Code

CSS variables and component theme

→

Constructor schema

theme + widget parameters, validation

→

Brand A · B · C

configuration on top of the core, without a fork

Rule

A semantic token keeps the same role in Figma and code. Values may differ across brands and themes. A mismatch within one configuration is an error; differing values alone are not.

Alternative: configuration through Figma libraries

The rejected model: Figma library structures — all in one file, or foundations + a semantic library.

Design-system structure in Figma: foundations → visual values → brands

Foundations · one source of truth

Basic components

buttons, fields, cards — built on semantic tokens

library · published to the team

Section components

hero, catalogue, promotions, tournaments — built from basic components

library · published to the team

Pages

home, lobby, game page — section compositions

library · published to the team

↓

instances + variables · the brand connects to the library instead of copying it

Visual values · Brand A

variable mode: colors, fonts, radii, logo

values file · brand variable mode

→

Casino #1

brand product: foundation pages + its own values

product file · connects foundations + values

Visual values · Brand B

variable mode: colors, fonts, radii, logo

values file · brand variable mode

→

Casino #2

brand product: foundation pages + its own values

product file · connects foundations + values

Principle

One library, many identities. Components and contracts stay shared. The theme and permitted composition are configured for each brand.

All in one file approach

All in one file

Core foundations

Color

Spacing

Typography

Layout

Semantic design tokens

Brand A

Brand B

Card

Dropdown

Teaser

Components

Every component is in separate file

All components in one file

Foundations + Semantic Library

Brand foundations

Color

Spacing

Typography

Layout

Brand semantic tokens

Theme 1

Theme 2

Atoms

Molecules

Organisms

File 1

File 2

Files

Alternative: configuring feature delivery

copy the file again

components and updates

copy the file

Variables and styles

+ icons and images

Components file

master components

Pages file (instances)

+ icons and images

Variables and styles

linked by reference

Variables and styles

+ icons and images

Components file

master components

Pages file (instances)

+ icons and images

Variables and styles

new

Variables and styles

old

styles and variables

styles and variables

styles and variables

new features

JSON export

replaced by new file

New feature without new styles

Template files

Setup files

New feature + new styles

Template files

Setup files

Technically the scheme works: we built an MVP of it. Files are copied while the brand stays bound to the components, so they remain editable, and new variant values are set through boolean properties. The limit is Figma itself: updates do not propagate automatically through several levels of nested components, so every update has to be carried across by hand. The architecture can be built, but it is complex and rests on manual synchronisation.

05

Decisions

Why we chose a web constructor

We initially considered assembling client projects through linked libraries and configurable Figma files. This preserved a shared component foundation, but made brand configuration and dependency management more complex. We chose a web constructor: components and widgets remain part of the shared platform, while configuration describes differences between client websites. This simplifies setup and provides a foundation for centralized updates without individual forks.

From configuring files to configuring a product

Rejected

Brand configuration in Figma

Shared design system

tokens, components and widgets

↓

Client files

copies of pages and brand variables

↓

Configuration through JSON

variables and instance properties

Benefits: a shared component foundation, with no separate web constructor required.

Limitations: multilevel dependencies between files; brand configuration requires working with Figma’s internal structure.

Chosen

Brand configuration in the web constructor

Shared design system

tokens, components and widgets in code

↓

Web constructor

widget-based assembly and brand configuration

↓

Website on the shared platform

published JSON configuration

Benefits: assembly from ready-made widgets, controlled settings instead of forks, and one implementation for all client sites.

Trade-off: requires constructor development, configuration validation and controlled delivery of updates.

Updates

shared library → testing → platform release → client websites with compatible settings preserved. The constructor publishes settings; platform releases deliver code.

A widget is a ready-made block of design-system components with defined variants, settings and placement rules. The client configuration stores those choices, while the website uses the shared widget implementation.

Constructor workspace

Core setup-team workflows
  • Select a page and configure a ready-made foundation.
  • Add widgets and configure variants in the grid.
  • Apply the brand theme and content.
  • Check desktop, tablet and mobile.
  • Review changes in the live preview.
  • Resolve constraint violations and submit the configuration for publishing.
Core project-manager workflows
Manage multiple white-label projects and setups.
  • Prepare configurations for different markets, regions and licences.
  • Create interface variants for A/B tests.
  • Set experiment audiences, parameters and schedules.
  • Compare results across configurations.
  • Monitor product and operational metrics.
  • Analyse conversion, engagement and user behaviour.
  • Track the status of tests, reviews and launches.
  • Identify issues and export requirements.
  • Manage roles, permissions and change history.
  • Decide which successful variants to scale.

How the solution works

Three platform layers and the workspace that connects them.

System architecture: five levels

1. Atoms and molecules

A large design system: foundations, components, tokens and states.

2. Organisms and patterns

Stable interface patterns assembled from foundational components.

↓

3. Widgets

Functional modules with visual variants, settings and grid-placement scenarios.

↓

4. Visual configurator

A web interface for composing pages from widgets: grids, composition, parameters and variants.

5. Operations workspace

The workspace combines page, widget and brand configuration. Portfolio management, analytics and experiments are potential developments beyond this case.

The design system needed to work as product infrastructure, rather than a static component library:

Component → widget → constructor: one entity at three levels

DS component

Button

variant: primary / secondary · size: s / m / l

Card

props: image (bool) · badge (bool)

Variables

color.bg.accent · radius.md · space.16

Widget

Hero banner

= Image + Title + Text + Button

Properties

type: 1…8 · cta.visible · align

Connection to the DS

Linked instances in Figma; a reviewed, released shared implementation in the product

Constructor

12-column grid

widget spans N columns × M sections

Inspector

content · variant · device visibility

Export

whole page = JSON configuration

{ "page": "home", "widgets": [ { "widget": "hero-banner", "type": 3, "span": [12, 2], "props": { "cta": true, "align": "left" } }, { "widget": "games-catalogue", "type": 1, "span": [8, 3] }, { "widget": "live-wins", "type": 2, "span": [4, 3] } ], "theme": "brand-a", "template": "2.4.0" }

The same widget uses the same names in Figma (variants and variables), code (props) and configuration (JSON), so it can move between brands while staying connected to the system.

A component variant available in Figma maps to an implemented variant and an explicit, configurable constructor parameter

Token pipeline — one source of truth

Figma Variables

primitive → semantic → component; modes = brands

↓

Tokens JSON

automatic Figma export, one name at every level

↓

Code

CSS variables and component theme

↓

Constructor schema

theme + widget parameters, validation

↓

Brand A · B · C

configuration on top of the core, without a fork

Rule

A semantic token keeps the same role in Figma and code. Values may differ across brands and themes. A mismatch within one configuration is an error; differing values alone are not.

Alternative: configuration through Figma libraries

The rejected model: Figma library structures — all in one file, or foundations + a semantic library.

Design-system structure in Figma: foundations → visual values → brands

Foundations · one source of truth

Basic components

buttons, fields, cards — built on semantic tokens

library · published to the team

Section components

hero, catalogue, promotions, tournaments — built from basic components

library · published to the team

Pages

home, lobby, game page — section compositions

library · published to the team

↓

instances + variables · the brand connects to the library instead of copying it

Visual values · Brand A

variable mode: colors, fonts, radii, logo

values file · brand variable mode

→

Casino #1

brand product: foundation pages + its own values

product file · connects foundations + values

Visual values · Brand B

variable mode: colors, fonts, radii, logo

values file · brand variable mode

→

Casino #2

brand product: foundation pages + its own values

product file · connects foundations + values

Principle

One library, many identities. Components and contracts stay shared. The theme and permitted composition are configured for each brand.

All in one file approach

All in one file

Core foundations

Color

Spacing

Typography

Layout

Semantic design tokens

Brand A

Brand B

Every component is in separate file

Card

Dropdown

Teaser

All components in one file

Components

Foundations + Semantic Library

File 1

Brand foundations

Color

Spacing

Typography

Layout

File 2

Brand semantic tokens

Theme 1

Theme 2

Files

Atoms

Molecules

Organisms

Alternative: configuring feature delivery

Variables and styles

+ icons and images

Components file

master components

Pages file (instances)

+ icons and images

Variables and styles

linked by reference

Variables and styles

+ icons and images

Components file

master components

Pages file (instances)

+ icons and images

Variables and styles

new

Variables and styles

old

styles and variables

components and updates

styles and variables

copy the file

styles and variables

new features

copy the file again

JSON export

replaced by new file

New feature without new styles

Template files

Setup files

New feature + new styles

Template files

Setup files

Technically the scheme works: we built an MVP of it. Files are copied while the brand stays bound to the components, so they remain editable, and new variant values are set through boolean properties. The limit is Figma itself: updates do not propagate automatically through several levels of nested components, so every update has to be carried across by hand. The architecture can be built, but it is complex and rests on manual synchronisation.

05

Decisions

Why we chose a web constructor

We initially considered assembling client projects through linked libraries and configurable Figma files. This preserved a shared component foundation, but made brand configuration and dependency management more complex. We chose a web constructor: components and widgets remain part of the shared platform, while configuration describes differences between client websites. This simplifies setup and provides a foundation for centralized updates without individual forks.

From configuring files to configuring a product

Rejected

Brand configuration in Figma

Shared design system

tokens, components and widgets

↓

Client files

copies of pages and brand variables

↓

Configuration through JSON

variables and instance properties

Benefits: a shared component foundation, with no separate web constructor required.

Limitations: multilevel dependencies between files; brand configuration requires working with Figma’s internal structure.

Chosen

Brand configuration in the web constructor

Shared design system

tokens, components and widgets in code

↓

Web constructor

widget-based assembly and brand configuration

↓

Website on the shared platform

published JSON configuration

Benefits: assembly from ready-made widgets, controlled settings instead of forks, and one implementation for all client sites.

Trade-off: requires constructor development, configuration validation and controlled delivery of updates.

Updates

shared library → testing → platform release → client websites with compatible settings preserved. The constructor publishes settings; platform releases deliver code.

A widget is a ready-made block of design-system components with defined variants, settings and placement rules. The client configuration stores those choices, while the website uses the shared widget implementation.

Constructor workspace

Core setup-team workflows
  • Select a page and configure a ready-made foundation.
  • Add widgets and configure variants in the grid.
  • Apply the brand theme and content.
  • Check desktop, tablet and mobile.
  • Review changes in the live preview.
  • Resolve constraint violations and submit the configuration for publishing.
Core project-manager workflows
Manage multiple white-label projects and setups.
  • Prepare configurations for different markets, regions and licences.
  • Create interface variants for A/B tests.
  • Set experiment audiences, parameters and schedules.
  • Compare results across configurations.
  • Monitor product and operational metrics.
  • Analyse conversion, engagement and user behaviour.
  • Track the status of tests, reviews and launches.
  • Identify issues and export requirements.
  • Manage roles, permissions and change history.
  • Decide which successful variants to scale.

How the solution works

Three platform layers and the workspace that connects them.

System architecture: five levels

1. Atoms and molecules

A large design system: foundations, components, tokens and states.

2. Organisms and patterns

Stable interface patterns assembled from foundational components.

↓

3. Widgets

Functional modules with visual variants, settings and grid-placement scenarios.

↓

4. Visual configurator

A web interface for composing pages from widgets: grids, composition, parameters and variants.

5. Operations workspace

The workspace combines page, widget and brand configuration. Portfolio management, analytics and experiments are potential developments beyond this case.

The design system needed to work as product infrastructure, rather than a static component library:

Component → widget → constructor: one entity at three levels

DS component

Button

variant: primary / secondary · size: s / m / l

Card

props: image (bool) · badge (bool)

Variables

color.bg.accent · radius.md · space.16

Widget

Hero banner

= Image + Title + Text + Button

Properties

type: 1…8 · cta.visible · align

Connection to the DS

Linked instances in Figma; a reviewed, released shared implementation in the product

Constructor

12-column grid

widget spans N columns × M sections

Inspector

content · variant · device visibility

Export

whole page = JSON configuration

{ "page": "home", "widgets": [ { "widget": "hero-banner", "type": 3, "span": [12, 2], "props": { "cta": true, "align": "left" } }, { "widget": "games-catalogue", "type": 1, "span": [8, 3] }, { "widget": "live-wins", "type": 2, "span": [4, 3] } ], "theme": "brand-a", "template": "2.4.0" }

The same widget uses the same names in Figma (variants and variables), code (props) and configuration (JSON), so it can move between brands while staying connected to the system.

A component variant available in Figma maps to an implemented variant and an explicit, configurable constructor parameter

Token pipeline — one source of truth

Figma Variables

primitive → semantic → component; modes = brands

↓

Tokens JSON

automatic Figma export, one name at every level

↓

Code

CSS variables and component theme

↓

Constructor schema

theme + widget parameters, validation

↓

Brand A · B · C

configuration on top of the core, without a fork

Rule

A semantic token keeps the same role in Figma and code. Values may differ across brands and themes. A mismatch within one configuration is an error; differing values alone are not.

Alternative: configuration through Figma libraries

The rejected model: Figma library structures — all in one file, or foundations + a semantic library.

Design-system structure in Figma: foundations → visual values → brands

Foundations · one source of truth

Basic components

buttons, fields, cards — built on semantic tokens

library · published to the team

Section components

hero, catalogue, promotions, tournaments — built from basic components

library · published to the team

Pages

home, lobby, game page — section compositions

library · published to the team

↓

instances + variables · the brand connects to the library instead of copying it

Visual values · Brand A

variable mode: colors, fonts, radii, logo

values file · brand variable mode

→

Casino #1

brand product: foundation pages + its own values

product file · connects foundations + values

Visual values · Brand B

variable mode: colors, fonts, radii, logo

values file · brand variable mode

→

Casino #2

brand product: foundation pages + its own values

product file · connects foundations + values

Principle

One library, many identities. Components and contracts stay shared. The theme and permitted composition are configured for each brand.

All in one file approach

All in one file

Core foundations

Color

Spacing

Typography

Layout

Semantic design tokens

Brand A

Brand B

Every component is in separate file

Card

Dropdown

Teaser

All components in one file

Components

Foundations + Semantic Library

File 1

Brand foundations

Color

Spacing

Typography

Layout

File 2

Brand semantic tokens

Theme 1

Theme 2

Files

Atoms

Molecules

Organisms

Alternative: configuring feature delivery

Variables and styles

+ icons and images

Components file

master components

Pages file (instances)

+ icons and images

Variables and styles

linked by reference

Variables and styles

+ icons and images

Components file

master components

Pages file (instances)

+ icons and images

Variables and styles

new

Variables and styles

old

styles and variables

components and updates

styles and variables

copy the file

styles and variables

new features

copy the file again

JSON export

replaced by new file

New feature without new styles

Template files

Setup files

New feature + new styles

Template files

Setup files

Technically the scheme works: we built an MVP of it. Files are copied while the brand stays bound to the components, so they remain editable, and new variant values are set through boolean properties. The limit is Figma itself: updates do not propagate automatically through several levels of nested components, so every update has to be carried across by hand. The architecture can be built, but it is complex and rests on manual synchronisation.

06

Компромиссы

Как мы принимали системные решения

•

Quick mode vs. Expert mode — Quick mode: выбор из готовых вариантов и пресетов с низким риском. Expert mode: более глубокая настройка страницы — положение, размеры и варианты виджетов по правилам сетки. Уровень компонентов остаётся за дизайнерами: новые фичи появляются в общем ядре, а не в конструкторе. Оставили оба режима.

•

Контролируемая гибкость vs. свобода оператора — операторы не могут сломать доступность, отзывчивость или согласованность системы, даже если конкретный запрос клиента предпочёл бы обратное.

•

Скорость с AI vs. целостность системы — AI изучали для аудита переменных, автоматизации сборки новой дизайн-системы и сверки структуры Figma с реализацией. Любое реальное изменение дизайн-системы всё равно требует ручного подтверждения владельца — никогда не мёржится автоматически.

•

Необязательные минорные апдейты vs. единые версии — минорные обновления аддитивны и опциональны, поэтому существующих клиентов никогда не заставляют меняться. Цена: разные клиенты в любой момент времени могут быть на разных минорных версиях.

Как работает сетка виджетов

Страница — это сетка из колонок. Виджеты сгруппированы по блокам. Виджет занимает N колонок × M рядов и объявляет свой span для каждого брейкпоинта. В подписях «span N×M» N — колонки, M — ряды; Type — вариант виджета. Порядок виджетов общий, меняется только раскладка и, при необходимости, вариант виджета.

DESKTOP · 12 КОЛОНОК

Hero banner

span 12×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 4×3 · list

Player 01

Player 02

Player 03

Promo 01

span 6×2

Welcome offer

Promo 02

span 6×2

Weekly rewards

Footer · span 12×1

12 колонок: hero на всю ширину; каталог 8 + live wins 4; промо 6 + 6; footer на всю ширину.

TABLET · 8 КОЛОНОК

Hero banner

span 8×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 8×1 · compact

Win 01

Win 02

Win 03

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 8×1

8 колонок: каталог на всю ширину, под ним компактная полоса live wins, промо 4 + 4.

MOBILE · 4 КОЛОНКИ

Hero banner

span 4×2 · Type 1 · carousel 1/3

Banner 01

● ○ ○

Games catalogue

span 4×3 · Type 1

01

02

03

04

05

06

Live wins

span 4×1 · compact

Player 01 · win 120

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 4×1

4 колонки: всё на всю ширину — игры по 2 в ряд, live wins компактно, промо друг под другом.

Правила сетки

Span объявляет виджет

Каждый тип виджета задаёт минимальный и максимальный span по колонкам и рядам. Оператор выбирает в этих пределах.

Перенос вместо ломки

Если в ряду не хватает колонок, виджет уходит на следующий ряд. Наложений не бывает по построению.

Порядок общий для всех устройств

Меняется раскладка и вариант, но не последовательность блоков — контент читается одинаково.

Вариант зависит от брейкпоинта

Hero Type 3 на десктопе становится Type 1 на мобиле; переключение описано в контракте виджета, а не руками.

Ограничения защищают систему

Нельзя поставить виджет уже минимального span или вне разрешённых зон страницы — конструктор просто не даст.

Фрагмент конфигурации страницы

{ "page": "home", "grid": { "desktop": 12, "tablet": 8, "mobile": 4 }, "widgets": [ { "widget": "hero-banner", "span": { "desktop": [12, 2], "tablet": [8, 2], "mobile": [4, 2] }, "variant": { "desktop": "type-3", "mobile": "type-1" } }, { "widget": "games-catalogue", "span": { "desktop": [8, 3], "tablet": [8, 3], "mobile": [4, 3] } }, { "widget": "live-wins", "span": { "desktop": [4, 3], "tablet": [8, 1], "mobile": [4, 1] }, "variant": { "tablet": "compact", "mobile": "compact" } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "footer", "span": { "desktop": [12, 1], "tablet": [8, 1], "mobile": [4, 1] } } ] }

Тот же JSON, который публикует конструктор и читает frontend: сетка и span по брейкпоинтам — часть контракта виджета.

Концепт сетки: как виджеты занимают секции страницы и как выглядит мобильное превью. Реальный интерфейс конструктора — под NDA.

06

Компромиссы

Как мы принимали системные решения

•

Quick mode vs. Expert mode — Quick mode: выбор из готовых вариантов и пресетов с низким риском. Expert mode: более глубокая настройка страницы — положение, размеры и варианты виджетов по правилам сетки. Уровень компонентов остаётся за дизайнерами: новые фичи появляются в общем ядре, а не в конструкторе. Оставили оба режима.

•

Контролируемая гибкость vs. свобода оператора — операторы не могут сломать доступность, отзывчивость или согласованность системы, даже если конкретный запрос клиента предпочёл бы обратное.

•

Скорость с AI vs. целостность системы — AI изучали для аудита переменных, автоматизации сборки новой дизайн-системы и сверки структуры Figma с реализацией. Любое реальное изменение дизайн-системы всё равно требует ручного подтверждения владельца — никогда не мёржится автоматически.

•

Необязательные минорные апдейты vs. единые версии — минорные обновления аддитивны и опциональны, поэтому существующих клиентов никогда не заставляют меняться. Цена: разные клиенты в любой момент времени могут быть на разных минорных версиях.

Как работает сетка виджетов

Страница — это сетка из колонок. Виджеты сгруппированы по блокам. Виджет занимает N колонок × M рядов и объявляет свой span для каждого брейкпоинта. В подписях «span N×M» N — колонки, M — ряды; Type — вариант виджета. Порядок виджетов общий, меняется только раскладка и, при необходимости, вариант виджета.

DESKTOP · 12 КОЛОНОК

Hero banner

span 12×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 4×3 · list

Player 01

Player 02

Player 03

Promo 01

span 6×2

Welcome offer

Promo 02

span 6×2

Weekly rewards

Footer · span 12×1

12 колонок: hero на всю ширину; каталог 8 + live wins 4; промо 6 + 6; footer на всю ширину.

TABLET · 8 КОЛОНОК

Hero banner

span 8×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 8×1 · compact

Win 01

Win 02

Win 03

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 8×1

8 колонок: каталог на всю ширину, под ним компактная полоса live wins, промо 4 + 4.

MOBILE · 4 КОЛОНКИ

Hero banner

span 4×2 · Type 1 · carousel 1/3

Banner 01

● ○ ○

Games catalogue

span 4×3 · Type 1

01

02

03

04

05

06

Live wins

span 4×1 · compact

Player 01 · win 120

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 4×1

4 колонки: всё на всю ширину — игры по 2 в ряд, live wins компактно, промо друг под другом.

Правила сетки

Span объявляет виджет

Каждый тип виджета задаёт минимальный и максимальный span по колонкам и рядам. Оператор выбирает в этих пределах.

Перенос вместо ломки

Если в ряду не хватает колонок, виджет уходит на следующий ряд. Наложений не бывает по построению.

Порядок общий для всех устройств

Меняется раскладка и вариант, но не последовательность блоков — контент читается одинаково.

Вариант зависит от брейкпоинта

Hero Type 3 на десктопе становится Type 1 на мобиле; переключение описано в контракте виджета, а не руками.

Ограничения защищают систему

Нельзя поставить виджет уже минимального span или вне разрешённых зон страницы — конструктор просто не даст.

Фрагмент конфигурации страницы

{ "page": "home", "grid": { "desktop": 12, "tablet": 8, "mobile": 4 }, "widgets": [ { "widget": "hero-banner", "span": { "desktop": [12, 2], "tablet": [8, 2], "mobile": [4, 2] }, "variant": { "desktop": "type-3", "mobile": "type-1" } }, { "widget": "games-catalogue", "span": { "desktop": [8, 3], "tablet": [8, 3], "mobile": [4, 3] } }, { "widget": "live-wins", "span": { "desktop": [4, 3], "tablet": [8, 1], "mobile": [4, 1] }, "variant": { "tablet": "compact", "mobile": "compact" } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "footer", "span": { "desktop": [12, 1], "tablet": [8, 1], "mobile": [4, 1] } } ] }

Тот же JSON, который публикует конструктор и читает frontend: сетка и span по брейкпоинтам — часть контракта виджета.

Концепт сетки: как виджеты занимают секции страницы и как выглядит мобильное превью. Реальный интерфейс конструктора — под NDA.

06

Компромиссы

Как мы принимали системные решения

•

Quick mode vs. Expert mode — Quick mode: выбор из готовых вариантов и пресетов с низким риском. Expert mode: более глубокая настройка страницы — положение, размеры и варианты виджетов по правилам сетки. Уровень компонентов остаётся за дизайнерами: новые фичи появляются в общем ядре, а не в конструкторе. Оставили оба режима.

•

Контролируемая гибкость vs. свобода оператора — операторы не могут сломать доступность, отзывчивость или согласованность системы, даже если конкретный запрос клиента предпочёл бы обратное.

•

Скорость с AI vs. целостность системы — AI изучали для аудита переменных, автоматизации сборки новой дизайн-системы и сверки структуры Figma с реализацией. Любое реальное изменение дизайн-системы всё равно требует ручного подтверждения владельца — никогда не мёржится автоматически.

•

Необязательные минорные апдейты vs. единые версии — минорные обновления аддитивны и опциональны, поэтому существующих клиентов никогда не заставляют меняться. Цена: разные клиенты в любой момент времени могут быть на разных минорных версиях.

Как работает сетка виджетов

Страница — это сетка из колонок. Виджеты сгруппированы по блокам. Виджет занимает N колонок × M рядов и объявляет свой span для каждого брейкпоинта. В подписях «span N×M» N — колонки, M — ряды; Type — вариант виджета. Порядок виджетов общий, меняется только раскладка и, при необходимости, вариант виджета.

DESKTOP · 12 КОЛОНОК

Hero banner

span 12×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 4×3 · list

Player 01

Player 02

Player 03

Promo 01

span 6×2

Welcome offer

Promo 02

span 6×2

Weekly rewards

Footer · span 12×1

12 колонок: hero на всю ширину; каталог 8 + live wins 4; промо 6 + 6; footer на всю ширину.

TABLET · 8 КОЛОНОК

Hero banner

span 8×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 8×1 · compact

Win 01

Win 02

Win 03

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 8×1

8 колонок: каталог на всю ширину, под ним компактная полоса live wins, промо 4 + 4.

MOBILE · 4 КОЛОНКИ

Hero banner

span 4×2 · Type 1 · carousel 1/3

Banner 01

● ○ ○

Games catalogue

span 4×3 · Type 1

01

02

03

04

05

06

Live wins

span 4×1 · compact

Player 01 · win 120

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 4×1

4 колонки: всё на всю ширину — игры по 2 в ряд, live wins компактно, промо друг под другом.

Правила сетки

Span объявляет виджет

Каждый тип виджета задаёт минимальный и максимальный span по колонкам и рядам. Оператор выбирает в этих пределах.

Перенос вместо ломки

Если в ряду не хватает колонок, виджет уходит на следующий ряд. Наложений не бывает по построению.

Порядок общий для всех устройств

Меняется раскладка и вариант, но не последовательность блоков — контент читается одинаково.

Вариант зависит от брейкпоинта

Hero Type 3 на десктопе становится Type 1 на мобиле; переключение описано в контракте виджета, а не руками.

Ограничения защищают систему

Нельзя поставить виджет уже минимального span или вне разрешённых зон страницы — конструктор просто не даст.

Фрагмент конфигурации страницы

{ "page": "home", "grid": { "desktop": 12, "tablet": 8, "mobile": 4 }, "widgets": [ { "widget": "hero-banner", "span": { "desktop": [12, 2], "tablet": [8, 2], "mobile": [4, 2] }, "variant": { "desktop": "type-3", "mobile": "type-1" } }, { "widget": "games-catalogue", "span": { "desktop": [8, 3], "tablet": [8, 3], "mobile": [4, 3] } }, { "widget": "live-wins", "span": { "desktop": [4, 3], "tablet": [8, 1], "mobile": [4, 1] }, "variant": { "tablet": "compact", "mobile": "compact" } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "footer", "span": { "desktop": [12, 1], "tablet": [8, 1], "mobile": [4, 1] } } ] }

Тот же JSON, который публикует конструктор и читает frontend: сетка и span по брейкпоинтам — часть контракта виджета.

Концепт сетки: как виджеты занимают секции страницы и как выглядит мобильное превью. Реальный интерфейс конструктора — под NDA.

06

Компромиссы

Как мы принимали системные решения

•

Quick mode vs. Expert mode — Quick mode: выбор из готовых вариантов и пресетов с низким риском. Expert mode: более глубокая настройка страницы — положение, размеры и варианты виджетов по правилам сетки. Уровень компонентов остаётся за дизайнерами: новые фичи появляются в общем ядре, а не в конструкторе. Оставили оба режима.

•

Контролируемая гибкость vs. свобода оператора — операторы не могут сломать доступность, отзывчивость или согласованность системы, даже если конкретный запрос клиента предпочёл бы обратное.

•

Скорость с AI vs. целостность системы — AI изучали для аудита переменных, автоматизации сборки новой дизайн-системы и сверки структуры Figma с реализацией. Любое реальное изменение дизайн-системы всё равно требует ручного подтверждения владельца — никогда не мёржится автоматически.

•

Необязательные минорные апдейты vs. единые версии — минорные обновления аддитивны и опциональны, поэтому существующих клиентов никогда не заставляют меняться. Цена: разные клиенты в любой момент времени могут быть на разных минорных версиях.

Как работает сетка виджетов

Страница — это сетка из колонок. Виджеты сгруппированы по блокам. Виджет занимает N колонок × M рядов и объявляет свой span для каждого брейкпоинта. В подписях «span N×M» N — колонки, M — ряды; Type — вариант виджета. Порядок виджетов общий, меняется только раскладка и, при необходимости, вариант виджета.

DESKTOP · 12 КОЛОНОК

Hero banner

span 12×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 4×3 · list

Player 01

Player 02

Player 03

Promo 01

span 6×2

Welcome offer

Promo 02

span 6×2

Weekly rewards

Footer · span 12×1

12 колонок: hero на всю ширину; каталог 8 + live wins 4; промо 6 + 6; footer на всю ширину.

TABLET · 8 КОЛОНОК

Hero banner

span 8×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 8×1 · compact

Win 01

Win 02

Win 03

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 8×1

8 колонок: каталог на всю ширину, под ним компактная полоса live wins, промо 4 + 4.

MOBILE · 4 КОЛОНКИ

Hero banner

span 4×2 · Type 1 · carousel 1/3

Banner 01

● ○ ○

Games catalogue

span 4×3 · Type 1

01

02

03

04

05

06

Live wins

span 4×1 · compact

Player 01 · win 120

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 4×1

4 колонки: всё на всю ширину — игры по 2 в ряд, live wins компактно, промо друг под другом.

Правила сетки

Span объявляет виджет

Каждый тип виджета задаёт минимальный и максимальный span по колонкам и рядам. Оператор выбирает в этих пределах.

Перенос вместо ломки

Если в ряду не хватает колонок, виджет уходит на следующий ряд. Наложений не бывает по построению.

Порядок общий для всех устройств

Меняется раскладка и вариант, но не последовательность блоков — контент читается одинаково.

Вариант зависит от брейкпоинта

Hero Type 3 на десктопе становится Type 1 на мобиле; переключение описано в контракте виджета, а не руками.

Ограничения защищают систему

Нельзя поставить виджет уже минимального span или вне разрешённых зон страницы — конструктор просто не даст.

Фрагмент конфигурации страницы

{ "page": "home", "grid": { "desktop": 12, "tablet": 8, "mobile": 4 }, "widgets": [ { "widget": "hero-banner", "span": { "desktop": [12, 2], "tablet": [8, 2], "mobile": [4, 2] }, "variant": { "desktop": "type-3", "mobile": "type-1" } }, { "widget": "games-catalogue", "span": { "desktop": [8, 3], "tablet": [8, 3], "mobile": [4, 3] } }, { "widget": "live-wins", "span": { "desktop": [4, 3], "tablet": [8, 1], "mobile": [4, 1] }, "variant": { "tablet": "compact", "mobile": "compact" } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "footer", "span": { "desktop": [12, 1], "tablet": [8, 1], "mobile": [4, 1] } } ] }

Тот же JSON, который публикует конструктор и читает frontend: сетка и span по брейкпоинтам — часть контракта виджета.

Концепт сетки: как виджеты занимают секции страницы и как выглядит мобильное превью. Реальный интерфейс конструктора — под NDA.

06

Trade-offs

How we made system-level decisions

•

Quick mode vs. Expert mode — Quick mode: a low-risk choice from ready-made options and presets. Expert mode: deeper page configuration — widget placement, sizes and variants within the grid rules. The component level stays with the designers: new features arrive in the shared core, not in the constructor. We kept both modes.

•

Controlled flexibility vs. operator freedom — operators cannot override the system’s accessibility, responsiveness or consistency constraints, even when a particular client request calls for it.

•

AI speed vs. system integrity — we explored AI for variable audits, automating the new design-system assembly and comparing the Figma structure with implementation. Every actual design-system change still requires the owner’s manual approval; it is never merged automatically.

•

Optional minor updates vs. consistent versions — minor updates are additive and optional, so existing clients are never forced to change. The trade-off: clients may be on different minor versions at any given time.

How the widget grid works

A page is a column grid, with widgets grouped into blocks. Each widget spans N columns × M rows and declares its span at every breakpoint. In the labels, span N×M means N columns by M rows; Type is the widget variant. Widget order stays the same; only the layout and, when needed, the widget variant change.

DESKTOP · 12 COLUMNS

Hero banner

span 12×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 4×3 · list

Player 01

Player 02

Player 03

Promo 01

span 6×2

Welcome offer

Promo 02

span 6×2

Weekly rewards

Footer · span 12×1

12 columns: full-width hero; catalogue 8 + live wins 4; promos 6 + 6; full-width footer.

TABLET · 8 COLUMNS

Hero banner

span 8×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 8×1 · compact

Win 01

Win 02

Win 03

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 8×1

8 columns: full-width catalogue, a compact live-wins strip below it, promos 4 + 4.

MOBILE · 4 COLUMNS

Hero banner

span 4×2 · Type 1 · carousel 1/3

Banner 01

● ○ ○

Games catalogue

span 4×3 · Type 1

01

02

03

04

05

06

Live wins

span 4×1 · compact

Player 01 · win 120

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 4×1

4 columns: everything full width — two games per row, compact live wins, stacked promos.

Grid rules

The widget declares its span

Each widget type defines its minimum and maximum column and row spans. The operator chooses within these limits.

Wrap instead of breaking

If there are not enough columns in a row, the widget moves to the next row. The layout prevents overlap by design.

One order across all devices

The layout and variant change, but block order stays the same, preserving the reading sequence.

Variants follow the breakpoint

Hero Type 3 on desktop becomes Type 1 on mobile. The switch is defined in the widget contract, not configured manually.

Constraints protect the system

The constructor prevents placing a widget below its minimum span or outside the allowed page zones.

Page configuration excerpt

{ "page": "home", "grid": { "desktop": 12, "tablet": 8, "mobile": 4 }, "widgets": [ { "widget": "hero-banner", "span": { "desktop": [12, 2], "tablet": [8, 2], "mobile": [4, 2] }, "variant": { "desktop": "type-3", "mobile": "type-1" } }, { "widget": "games-catalogue", "span": { "desktop": [8, 3], "tablet": [8, 3], "mobile": [4, 3] } }, { "widget": "live-wins", "span": { "desktop": [4, 3], "tablet": [8, 1], "mobile": [4, 1] }, "variant": { "tablet": "compact", "mobile": "compact" } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "footer", "span": { "desktop": [12, 1], "tablet": [8, 1], "mobile": [4, 1] } } ] }

The same JSON is published by the constructor and read by the frontend. The grid and breakpoint spans are part of the widget contract.

Grid concept: widget placement within page sections and the mobile preview. The actual constructor interface is under NDA.

06

Trade-offs

How we made system-level decisions

•

Quick mode vs. Expert mode — Quick mode: a low-risk choice from ready-made options and presets. Expert mode: deeper page configuration — widget placement, sizes and variants within the grid rules. The component level stays with the designers: new features arrive in the shared core, not in the constructor. We kept both modes.

•

Controlled flexibility vs. operator freedom — operators cannot override the system’s accessibility, responsiveness or consistency constraints, even when a particular client request calls for it.

•

AI speed vs. system integrity — we explored AI for variable audits, automating the new design-system assembly and comparing the Figma structure with implementation. Every actual design-system change still requires the owner’s manual approval; it is never merged automatically.

•

Optional minor updates vs. consistent versions — minor updates are additive and optional, so existing clients are never forced to change. The trade-off: clients may be on different minor versions at any given time.

How the widget grid works

A page is a column grid, with widgets grouped into blocks. Each widget spans N columns × M rows and declares its span at every breakpoint. In the labels, span N×M means N columns by M rows; Type is the widget variant. Widget order stays the same; only the layout and, when needed, the widget variant change.

DESKTOP · 12 COLUMNS

Hero banner

span 12×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 4×3 · list

Player 01

Player 02

Player 03

Promo 01

span 6×2

Welcome offer

Promo 02

span 6×2

Weekly rewards

Footer · span 12×1

12 columns: full-width hero; catalogue 8 + live wins 4; promos 6 + 6; full-width footer.

TABLET · 8 COLUMNS

Hero banner

span 8×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 8×1 · compact

Win 01

Win 02

Win 03

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 8×1

8 columns: full-width catalogue, a compact live-wins strip below it, promos 4 + 4.

MOBILE · 4 COLUMNS

Hero banner

span 4×2 · Type 1 · carousel 1/3

Banner 01

● ○ ○

Games catalogue

span 4×3 · Type 1

01

02

03

04

05

06

Live wins

span 4×1 · compact

Player 01 · win 120

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 4×1

4 columns: everything full width — two games per row, compact live wins, stacked promos.

Grid rules

The widget declares its span

Each widget type defines its minimum and maximum column and row spans. The operator chooses within these limits.

Wrap instead of breaking

If there are not enough columns in a row, the widget moves to the next row. The layout prevents overlap by design.

One order across all devices

The layout and variant change, but block order stays the same, preserving the reading sequence.

Variants follow the breakpoint

Hero Type 3 on desktop becomes Type 1 on mobile. The switch is defined in the widget contract, not configured manually.

Constraints protect the system

The constructor prevents placing a widget below its minimum span or outside the allowed page zones.

Page configuration excerpt

{ "page": "home", "grid": { "desktop": 12, "tablet": 8, "mobile": 4 }, "widgets": [ { "widget": "hero-banner", "span": { "desktop": [12, 2], "tablet": [8, 2], "mobile": [4, 2] }, "variant": { "desktop": "type-3", "mobile": "type-1" } }, { "widget": "games-catalogue", "span": { "desktop": [8, 3], "tablet": [8, 3], "mobile": [4, 3] } }, { "widget": "live-wins", "span": { "desktop": [4, 3], "tablet": [8, 1], "mobile": [4, 1] }, "variant": { "tablet": "compact", "mobile": "compact" } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "footer", "span": { "desktop": [12, 1], "tablet": [8, 1], "mobile": [4, 1] } } ] }

The same JSON is published by the constructor and read by the frontend. The grid and breakpoint spans are part of the widget contract.

Grid concept: widget placement within page sections and the mobile preview. The actual constructor interface is under NDA.

06

Trade-offs

How we made system-level decisions

•

Quick mode vs. Expert mode — Quick mode: a low-risk choice from ready-made options and presets. Expert mode: deeper page configuration — widget placement, sizes and variants within the grid rules. The component level stays with the designers: new features arrive in the shared core, not in the constructor. We kept both modes.

•

Controlled flexibility vs. operator freedom — operators cannot override the system’s accessibility, responsiveness or consistency constraints, even when a particular client request calls for it.

•

AI speed vs. system integrity — we explored AI for variable audits, automating the new design-system assembly and comparing the Figma structure with implementation. Every actual design-system change still requires the owner’s manual approval; it is never merged automatically.

•

Optional minor updates vs. consistent versions — minor updates are additive and optional, so existing clients are never forced to change. The trade-off: clients may be on different minor versions at any given time.

How the widget grid works

A page is a column grid, with widgets grouped into blocks. Each widget spans N columns × M rows and declares its span at every breakpoint. In the labels, span N×M means N columns by M rows; Type is the widget variant. Widget order stays the same; only the layout and, when needed, the widget variant change.

DESKTOP · 12 COLUMNS

Hero banner

span 12×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 4×3 · list

Player 01

Player 02

Player 03

Promo 01

span 6×2

Welcome offer

Promo 02

span 6×2

Weekly rewards

Footer · span 12×1

12 columns: full-width hero; catalogue 8 + live wins 4; promos 6 + 6; full-width footer.

TABLET · 8 COLUMNS

Hero banner

span 8×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 8×1 · compact

Win 01

Win 02

Win 03

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 8×1

8 columns: full-width catalogue, a compact live-wins strip below it, promos 4 + 4.

MOBILE · 4 COLUMNS

Hero banner

span 4×2 · Type 1 · carousel 1/3

Banner 01

● ○ ○

Games catalogue

span 4×3 · Type 1

01

02

03

04

05

06

Live wins

span 4×1 · compact

Player 01 · win 120

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 4×1

4 columns: everything full width — two games per row, compact live wins, stacked promos.

Grid rules

The widget declares its span

Each widget type defines its minimum and maximum column and row spans. The operator chooses within these limits.

Wrap instead of breaking

If there are not enough columns in a row, the widget moves to the next row. The layout prevents overlap by design.

One order across all devices

The layout and variant change, but block order stays the same, preserving the reading sequence.

Variants follow the breakpoint

Hero Type 3 on desktop becomes Type 1 on mobile. The switch is defined in the widget contract, not configured manually.

Constraints protect the system

The constructor prevents placing a widget below its minimum span or outside the allowed page zones.

Page configuration excerpt

{ "page": "home", "grid": { "desktop": 12, "tablet": 8, "mobile": 4 }, "widgets": [ { "widget": "hero-banner", "span": { "desktop": [12, 2], "tablet": [8, 2], "mobile": [4, 2] }, "variant": { "desktop": "type-3", "mobile": "type-1" } }, { "widget": "games-catalogue", "span": { "desktop": [8, 3], "tablet": [8, 3], "mobile": [4, 3] } }, { "widget": "live-wins", "span": { "desktop": [4, 3], "tablet": [8, 1], "mobile": [4, 1] }, "variant": { "tablet": "compact", "mobile": "compact" } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "footer", "span": { "desktop": [12, 1], "tablet": [8, 1], "mobile": [4, 1] } } ] }

The same JSON is published by the constructor and read by the frontend. The grid and breakpoint spans are part of the widget contract.

Grid concept: widget placement within page sections and the mobile preview. The actual constructor interface is under NDA.

06

Trade-offs

How we made system-level decisions

•

Quick mode vs. Expert mode — Quick mode: a low-risk choice from ready-made options and presets. Expert mode: deeper page configuration — widget placement, sizes and variants within the grid rules. The component level stays with the designers: new features arrive in the shared core, not in the constructor. We kept both modes.

•

Controlled flexibility vs. operator freedom — operators cannot override the system’s accessibility, responsiveness or consistency constraints, even when a particular client request calls for it.

•

AI speed vs. system integrity — we explored AI for variable audits, automating the new design-system assembly and comparing the Figma structure with implementation. Every actual design-system change still requires the owner’s manual approval; it is never merged automatically.

•

Optional minor updates vs. consistent versions — minor updates are additive and optional, so existing clients are never forced to change. The trade-off: clients may be on different minor versions at any given time.

How the widget grid works

A page is a column grid, with widgets grouped into blocks. Each widget spans N columns × M rows and declares its span at every breakpoint. In the labels, span N×M means N columns by M rows; Type is the widget variant. Widget order stays the same; only the layout and, when needed, the widget variant change.

DESKTOP · 12 COLUMNS

Hero banner

span 12×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 4×3 · list

Player 01

Player 02

Player 03

Promo 01

span 6×2

Welcome offer

Promo 02

span 6×2

Weekly rewards

Footer · span 12×1

12 columns: full-width hero; catalogue 8 + live wins 4; promos 6 + 6; full-width footer.

TABLET · 8 COLUMNS

Hero banner

span 8×2 · Type 3 · 3 banners

Banner 01

Banner 02

Banner 03

Games catalogue

span 8×2 · Type 1

01

02

03

04

05

06

07

08

Live wins

span 8×1 · compact

Win 01

Win 02

Win 03

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 8×1

8 columns: full-width catalogue, a compact live-wins strip below it, promos 4 + 4.

MOBILE · 4 COLUMNS

Hero banner

span 4×2 · Type 1 · carousel 1/3

Banner 01

● ○ ○

Games catalogue

span 4×3 · Type 1

01

02

03

04

05

06

Live wins

span 4×1 · compact

Player 01 · win 120

Promo 01

span 4×2

Welcome offer

Promo 02

span 4×2

Weekly rewards

Footer · span 4×1

4 columns: everything full width — two games per row, compact live wins, stacked promos.

Grid rules

The widget declares its span

Each widget type defines its minimum and maximum column and row spans. The operator chooses within these limits.

Wrap instead of breaking

If there are not enough columns in a row, the widget moves to the next row. The layout prevents overlap by design.

One order across all devices

The layout and variant change, but block order stays the same, preserving the reading sequence.

Variants follow the breakpoint

Hero Type 3 on desktop becomes Type 1 on mobile. The switch is defined in the widget contract, not configured manually.

Constraints protect the system

The constructor prevents placing a widget below its minimum span or outside the allowed page zones.

Page configuration excerpt

{ "page": "home", "grid": { "desktop": 12, "tablet": 8, "mobile": 4 }, "widgets": [ { "widget": "hero-banner", "span": { "desktop": [12, 2], "tablet": [8, 2], "mobile": [4, 2] }, "variant": { "desktop": "type-3", "mobile": "type-1" } }, { "widget": "games-catalogue", "span": { "desktop": [8, 3], "tablet": [8, 3], "mobile": [4, 3] } }, { "widget": "live-wins", "span": { "desktop": [4, 3], "tablet": [8, 1], "mobile": [4, 1] }, "variant": { "tablet": "compact", "mobile": "compact" } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "promo-cards", "span": { "desktop": [6, 2], "tablet": [4, 2], "mobile": [4, 2] } }, { "widget": "footer", "span": { "desktop": [12, 1], "tablet": [8, 1], "mobile": [4, 1] } } ] }

The same JSON is published by the constructor and read by the frontend. The grid and breakpoint spans are part of the widget contract.

Grid concept: widget placement within page sections and the mobile preview. The actual constructor interface is under NDA.

07

Валидация

Роли и контрольные точки

В кейсе показана проверка качества системы: контрактов, параметров и соответствия реализации. Она дополняет, но не заменяет проверку удобства конструктора с его пользователями.

1

Бизнес-аналитика документирует параметры, правила и краевые случаи до начала разработки.

2

Владелец дизайн-системы валидирует контракт компонента — ручной gate, а не авто-мёрдж.

3

QA проверяет результат и по спецификации, и по исходнику в Figma.

4

Совместимость проверяется для изменений контракта. Несовместимое изменение требует миграции или новой major-версии; само по себе оно не означает ошибку версионирования.

Что стоит проверить с Setup-командой Сценарий: собрать страницу нового бренда, изменить тему, проверить мобильный вид и исправить ошибку настройки. Наблюдать: завершение задачи, время до первого корректного превью, ошибки и обращения за помощью. Сравнить Quick и Expert при одинаковой задаче и сопоставимом опыте участников. Это план проверки удобства, а не опубликованный результат исследования.

Constructor — improved (1440×900)

Пример настройки конструктора

Hero banner

Type 3

⋯

Params

Semantic

Rules

Devices

Variant

8 types

1

2

3

4

5

6

7

8

Content

Title

JOIN NOW AND GET

Offer

100% up to 300 EUR + 180 FS

CTA button

Join now

Layout

Span

12 cols × 2 rows

▾

Align

Left

▾

Mobile

Stack · 1 col

▾

Visibility

✓ Desktop

✓ Tablet

✓ Mobile

Semantic tokens

2 overrides

color.bg.hero

override

#06266F

color.accent

#FF5A1F

radius.card

16 px

type.h1

override

Inter Bold 40

Overrides live in this brand's config only. The shared template and other brands stay untouched.

Template & rules

Template version

2.4.0 · compatible

Next minor

2.5.0 · optional

Lock accessibility rules

Reset to template

Apply

07

Валидация

Роли и контрольные точки

В кейсе показана проверка качества системы: контрактов, параметров и соответствия реализации. Она дополняет, но не заменяет проверку удобства конструктора с его пользователями.

1

Бизнес-аналитика документирует параметры, правила и краевые случаи до начала разработки.

2

Владелец дизайн-системы валидирует контракт компонента — ручной gate, а не авто-мёрдж.

3

QA проверяет результат и по спецификации, и по исходнику в Figma.

4

Совместимость проверяется для изменений контракта. Несовместимое изменение требует миграции или новой major-версии; само по себе оно не означает ошибку версионирования.

Что стоит проверить с Setup-командой Сценарий: собрать страницу нового бренда, изменить тему, проверить мобильный вид и исправить ошибку настройки. Наблюдать: завершение задачи, время до первого корректного превью, ошибки и обращения за помощью. Сравнить Quick и Expert при одинаковой задаче и сопоставимом опыте участников. Это план проверки удобства, а не опубликованный результат исследования.

Constructor — improved (1440×900)

Пример настройки конструктора

Hero banner

Type 3

⋯

Params

Semantic

Rules

Devices

Variant

8 types

1

2

3

4

5

6

7

8

Content

Title

JOIN NOW AND GET

Offer

100% up to 300 EUR + 180 FS

CTA button

Join now

Layout

Span

12 cols × 2 rows

▾

Align

Left

▾

Mobile

Stack · 1 col

▾

Visibility

✓ Desktop

✓ Tablet

✓ Mobile

Semantic tokens

2 overrides

color.bg.hero

override

#06266F

color.accent

#FF5A1F

radius.card

16 px

type.h1

override

Inter Bold 40

Overrides live in this brand's config only. The shared template and other brands stay untouched.

Template & rules

Template version

2.4.0 · compatible

Next minor

2.5.0 · optional

Lock accessibility rules

Reset to template

Apply

07

Валидация

Роли и контрольные точки

В кейсе показана проверка качества системы: контрактов, параметров и соответствия реализации. Она дополняет, но не заменяет проверку удобства конструктора с его пользователями.

1

Бизнес-аналитика документирует параметры, правила и краевые случаи до начала разработки.

2

Владелец дизайн-системы валидирует контракт компонента — ручной gate, а не авто-мёрдж.

3

QA проверяет результат и по спецификации, и по исходнику в Figma.

4

Совместимость проверяется для изменений контракта. Несовместимое изменение требует миграции или новой major-версии; само по себе оно не означает ошибку версионирования.

Что стоит проверить с Setup-командой Сценарий: собрать страницу нового бренда, изменить тему, проверить мобильный вид и исправить ошибку настройки. Наблюдать: завершение задачи, время до первого корректного превью, ошибки и обращения за помощью. Сравнить Quick и Expert при одинаковой задаче и сопоставимом опыте участников. Это план проверки удобства, а не опубликованный результат исследования.

Constructor — improved (1440×900)

Пример настройки конструктора

Hero banner

Type 3

⋯

Params

Semantic

Rules

Devices

Variant

8 types

1

2

3

4

5

6

7

8

Content

Title

JOIN NOW AND GET

Offer

100% up to 300 EUR + 180 FS

CTA button

Join now

Layout

Span

12 cols × 2 rows

▾

Align

Left

▾

Mobile

Stack · 1 col

▾

Visibility

✓ Desktop

✓ Tablet

✓ Mobile

Semantic tokens

2 overrides

color.bg.hero

override

#06266F

color.accent

#FF5A1F

radius.card

16 px

type.h1

override

Inter Bold 40

Overrides live in this brand's config only. The shared template and other brands stay untouched.

Template & rules

Template version

2.4.0 · compatible

Next minor

2.5.0 · optional

Lock accessibility rules

Reset to template

Apply

07

Валидация

Роли и контрольные точки

В кейсе показана проверка качества системы: контрактов, параметров и соответствия реализации. Она дополняет, но не заменяет проверку удобства конструктора с его пользователями.

1

Бизнес-аналитика документирует параметры, правила и краевые случаи до начала разработки.

2

Владелец дизайн-системы валидирует контракт компонента — ручной gate, а не авто-мёрдж.

3

QA проверяет результат и по спецификации, и по исходнику в Figma.

4

Совместимость проверяется для изменений контракта. Несовместимое изменение требует миграции или новой major-версии; само по себе оно не означает ошибку версионирования.

Что стоит проверить с Setup-командой Сценарий: собрать страницу нового бренда, изменить тему, проверить мобильный вид и исправить ошибку настройки. Наблюдать: завершение задачи, время до первого корректного превью, ошибки и обращения за помощью. Сравнить Quick и Expert при одинаковой задаче и сопоставимом опыте участников. Это план проверки удобства, а не опубликованный результат исследования.

Constructor — improved (1440×900)

Пример настройки конструктора

Hero banner

Type 3

⋯

Params

Semantic

Rules

Devices

Variant

8 types

1

2

3

4

5

6

7

8

Content

Title

JOIN NOW AND GET

Offer

100% up to 300 EUR + 180 FS

CTA button

Join now

Layout

Span

12 cols × 2 rows

▾

Align

Left

▾

Mobile

Stack · 1 col

▾

Visibility

✓ Desktop

✓ Tablet

✓ Mobile

Semantic tokens

2 overrides

color.bg.hero

override

#06266F

color.accent

#FF5A1F

radius.card

16 px

type.h1

override

Inter Bold 40

Overrides live in this brand's config only. The shared template and other brands stay untouched.

Template & rules

Template version

2.4.0 · compatible

Next minor

2.5.0 · optional

Lock accessibility rules

Reset to template

Apply

07

Validation

Roles and checkpoints

This case shows system-quality checks: contracts, parameters and implementation fidelity. They complement usability testing with the constructor’s users; they do not replace it.

1

Business analysis documents parameters, rules and edge cases before development starts.

2

Design-system owner validates the component contract: a manual approval, never an automatic merge.

3

QA checks the result against both the specification and the Figma source.

4

Compatibility is checked when contracts change. A breaking change requires a migration or a new major version; it does not, by itself, mean that versioning has failed.

What to test with the setup team Scenario: build a new brand page, change its theme, check the mobile view and resolve a configuration error. Observe task completion, time to the first valid preview, errors and requests for help. Compare Quick and Expert using the same task and participants with comparable experience. This is a usability-test plan, not a published research result.

Constructor — improved (1440×900)

Constructor configuration example

Hero banner

Type 3

⋯

Params

Semantic

Rules

Devices

Variant

8 types

1

2

3

4

5

6

7

8

Content

Title

JOIN NOW AND GET

Offer

100% up to 300 EUR + 180 FS

CTA button

Join now

Layout

Span

12 cols × 2 rows

▾

Align

Left

▾

Mobile

Stack · 1 col

▾

Visibility

✓ Desktop

✓ Tablet

✓ Mobile

Semantic tokens

2 overrides

color.bg.hero

override

#06266F

color.accent

#FF5A1F

radius.card

16 px

type.h1

override

Inter Bold 40

Overrides live in this brand's config only. The shared template and other brands stay untouched.

Template & rules

Template version

2.4.0 · compatible

Next minor

2.5.0 · optional

Lock accessibility rules

Reset to template

Apply

07

Validation

Roles and checkpoints

This case shows system-quality checks: contracts, parameters and implementation fidelity. They complement usability testing with the constructor’s users; they do not replace it.

1

Business analysis documents parameters, rules and edge cases before development starts.

2

Design-system owner validates the component contract: a manual approval, never an automatic merge.

3

QA checks the result against both the specification and the Figma source.

4

Compatibility is checked when contracts change. A breaking change requires a migration or a new major version; it does not, by itself, mean that versioning has failed.

What to test with the setup team Scenario: build a new brand page, change its theme, check the mobile view and resolve a configuration error. Observe task completion, time to the first valid preview, errors and requests for help. Compare Quick and Expert using the same task and participants with comparable experience. This is a usability-test plan, not a published research result.

Constructor — improved (1440×900)

Constructor configuration example

Hero banner

Type 3

⋯

Params

Semantic

Rules

Devices

Variant

8 types

1

2

3

4

5

6

7

8

Content

Title

JOIN NOW AND GET

Offer

100% up to 300 EUR + 180 FS

CTA button

Join now

Layout

Span

12 cols × 2 rows

▾

Align

Left

▾

Mobile

Stack · 1 col

▾

Visibility

✓ Desktop

✓ Tablet

✓ Mobile

Semantic tokens

2 overrides

color.bg.hero

override

#06266F

color.accent

#FF5A1F

radius.card

16 px

type.h1

override

Inter Bold 40

Overrides live in this brand's config only. The shared template and other brands stay untouched.

Template & rules

Template version

2.4.0 · compatible

Next minor

2.5.0 · optional

Lock accessibility rules

Reset to template

Apply

07

Validation

Roles and checkpoints

This case shows system-quality checks: contracts, parameters and implementation fidelity. They complement usability testing with the constructor’s users; they do not replace it.

1

Business analysis documents parameters, rules and edge cases before development starts.

2

Design-system owner validates the component contract: a manual approval, never an automatic merge.

3

QA checks the result against both the specification and the Figma source.

4

Compatibility is checked when contracts change. A breaking change requires a migration or a new major version; it does not, by itself, mean that versioning has failed.

What to test with the setup team Scenario: build a new brand page, change its theme, check the mobile view and resolve a configuration error. Observe task completion, time to the first valid preview, errors and requests for help. Compare Quick and Expert using the same task and participants with comparable experience. This is a usability-test plan, not a published research result.

Constructor — improved (1440×900)

Constructor configuration example

Hero banner

Type 3

⋯

Params

Semantic

Rules

Devices

Variant

8 types

1

2

3

4

5

6

7

8

Content

Title

JOIN NOW AND GET

Offer

100% up to 300 EUR + 180 FS

CTA button

Join now

Layout

Span

12 cols × 2 rows

▾

Align

Left

▾

Mobile

Stack · 1 col

▾

Visibility

✓ Desktop

✓ Tablet

✓ Mobile

Semantic tokens

2 overrides

color.bg.hero

override

#06266F

color.accent

#FF5A1F

radius.card

16 px

type.h1

override

Inter Bold 40

Overrides live in this brand's config only. The shared template and other brands stay untouched.

Template & rules

Template version

2.4.0 · compatible

Next minor

2.5.0 · optional

Lock accessibility rules

Reset to template

Apply

07

Validation

Roles and checkpoints

This case shows system-quality checks: contracts, parameters and implementation fidelity. They complement usability testing with the constructor’s users; they do not replace it.

1

Business analysis documents parameters, rules and edge cases before development starts.

2

Design-system owner validates the component contract: a manual approval, never an automatic merge.

3

QA checks the result against both the specification and the Figma source.

4

Compatibility is checked when contracts change. A breaking change requires a migration or a new major version; it does not, by itself, mean that versioning has failed.

What to test with the setup team Scenario: build a new brand page, change its theme, check the mobile view and resolve a configuration error. Observe task completion, time to the first valid preview, errors and requests for help. Compare Quick and Expert using the same task and participants with comparable experience. This is a usability-test plan, not a published research result.

Constructor — improved (1440×900)

Constructor configuration example

Hero banner

Type 3

⋯

Params

Semantic

Rules

Devices

Variant

8 types

1

2

3

4

5

6

7

8

Content

Title

JOIN NOW AND GET

Offer

100% up to 300 EUR + 180 FS

CTA button

Join now

Layout

Span

12 cols × 2 rows

▾

Align

Left

▾

Mobile

Stack · 1 col

▾

Visibility

✓ Desktop

✓ Tablet

✓ Mobile

Semantic tokens

2 overrides

color.bg.hero

override

#06266F

color.accent

#FF5A1F

radius.card

16 px

type.h1

override

Inter Bold 40

Overrides live in this brand's config only. The shared template and other brands stay untouched.

Template & rules

Template version

2.4.0 · compatible

Next minor

2.5.0 · optional

Lock accessibility rules

Reset to template

Apply

08

Доставка

10-шаговый workflow

Как только возможность рамировали как общую, а не под конкретного клиента, она проходила один повторяемый путь:

1

Клиент или стейкхолдер формулирует потребность.

2

Product Owner решает, должна ли она стать общей возможностью.

3

Продуктовый дизайн определяет опыт, состояния и поведение компонента.

4

Владелец дизайн-системы валидирует контракт компонента.

5

Бизнес-аналитика документирует параметры, правила и краевые случаи.

6

FE-архитектура определяет технический интерфейс.

7

Разработка реализует компонент и схему конфигурации.

8

QA проверяет результат по спецификации и Figma.

9

Новый виджет становится доступен в конструкторе.

10

Нужные клиенты включают его конфигом или feature-флагом — без редеплоя и без сборки под клиента.

Безопасная поставка между версиями

Patch

совместимые фиксы — клиент ничего не делает

Minor

аддитивная возможность — опционально, без влияния на остальных

Major

изменение контракта — нужен путь миграции

Общая платформа и конфигурация бренда

Figma

проектирование системы

Токены + UI-компоненты

реализация в коде

Библиотека виджетов

варианты, настройки, правила размещения

Релиз платформы

тесты → версия → сайты

Веб-конструктор

сборка страниц и настройка бренда

Frontend сайта

показывает опубликованный результат

Тема бренда

цвета, типографика, ресурсы

Конфигурация сайта · JSON

страницы, виджеты, варианты

токены

компоненты

регистрация виджетов

тесты

публикация настроек

оформление

сайт читает конфиг

патч / минор без пересборки

одна реализация

Общая платформа — разрабатывается один раз

Слой бренда — только настройки

08

Доставка

10-шаговый workflow

Как только возможность рамировали как общую, а не под конкретного клиента, она проходила один повторяемый путь:

1

Клиент или стейкхолдер формулирует потребность.

2

Product Owner решает, должна ли она стать общей возможностью.

3

Продуктовый дизайн определяет опыт, состояния и поведение компонента.

4

Владелец дизайн-системы валидирует контракт компонента.

5

Бизнес-аналитика документирует параметры, правила и краевые случаи.

6

FE-архитектура определяет технический интерфейс.

7

Разработка реализует компонент и схему конфигурации.

8

QA проверяет результат по спецификации и Figma.

9

Новый виджет становится доступен в конструкторе.

10

Нужные клиенты включают его конфигом или feature-флагом — без редеплоя и без сборки под клиента.

Безопасная поставка между версиями

Patch

совместимые фиксы — клиент ничего не делает

Minor

аддитивная возможность — опционально, без влияния на остальных

Major

изменение контракта — нужен путь миграции

Общая платформа и конфигурация бренда

Figma

проектирование системы

Токены + UI-компоненты

реализация в коде

Библиотека виджетов

варианты, настройки, правила размещения

Релиз платформы

тесты → версия → сайты

Веб-конструктор

сборка страниц и настройка бренда

Frontend сайта

показывает опубликованный результат

Тема бренда

цвета, типографика, ресурсы

Конфигурация сайта · JSON

страницы, виджеты, варианты

токены

компоненты

регистрация виджетов

тесты

публикация настроек

оформление

сайт читает конфиг

патч / минор без пересборки

одна реализация

Общая платформа — разрабатывается один раз

Слой бренда — только настройки

08

Доставка

10-шаговый workflow

Как только возможность рамировали как общую, а не под конкретного клиента, она проходила один повторяемый путь:

1

Клиент или стейкхолдер формулирует потребность.

2

Product Owner решает, должна ли она стать общей возможностью.

3

Продуктовый дизайн определяет опыт, состояния и поведение компонента.

4

Владелец дизайн-системы валидирует контракт компонента.

5

Бизнес-аналитика документирует параметры, правила и краевые случаи.

6

FE-архитектура определяет технический интерфейс.

7

Разработка реализует компонент и схему конфигурации.

8

QA проверяет результат по спецификации и Figma.

9

Новый виджет становится доступен в конструкторе.

10

Нужные клиенты включают его конфигом или feature-флагом — без редеплоя и без сборки под клиента.

Безопасная поставка между версиями

Patch

совместимые фиксы — клиент ничего не делает

Minor

аддитивная возможность — опционально, без влияния на остальных

Major

изменение контракта — нужен путь миграции

Общая платформа и конфигурация бренда

Figma

Проектирование системы и описание токенов.

токены и контракты

Общая платформа

Разрабатывается один раз

Токены + UI-компоненты

Реализация в коде

компоненты

Библиотека виджетов

Варианты, настройки и правила размещения

Веб-конструктор

Регистрация виджетов → сборка страниц и настройка бренда

Релиз платформы

Тесты → версия → общая реализация для сайтов

Из веб-конструктора ↓ публикация настроек

Слой бренда — настройки

Тема бренда

Цвета, типографика и ресурсы

Конфигурация сайта · JSON

Страницы, виджеты и выбранные варианты

сайт читает конфигурацию

Frontend сайта

Опубликованный результат: тема + конфигурация + общая реализация

Релиз платформы → Frontend: обновление общей реализации. Публикация настроек → JSON: изменение конфигурации бренда.

08

Доставка

10-шаговый workflow

Как только возможность рамировали как общую, а не под конкретного клиента, она проходила один повторяемый путь:

1

Клиент или стейкхолдер формулирует потребность.

2

Product Owner решает, должна ли она стать общей возможностью.

3

Продуктовый дизайн определяет опыт, состояния и поведение компонента.

4

Владелец дизайн-системы валидирует контракт компонента.

5

Бизнес-аналитика документирует параметры, правила и краевые случаи.

6

FE-архитектура определяет технический интерфейс.

7

Разработка реализует компонент и схему конфигурации.

8

QA проверяет результат по спецификации и Figma.

9

Новый виджет становится доступен в конструкторе.

10

Нужные клиенты включают его конфигом или feature-флагом — без редеплоя и без сборки под клиента.

Безопасная поставка между версиями

Patch

совместимые фиксы — клиент ничего не делает

Minor

аддитивная возможность — опционально, без влияния на остальных

Major

изменение контракта — нужен путь миграции

Общая платформа и конфигурация бренда

Figma

Проектирование системы и описание токенов.

токены и контракты

Общая платформа

Разрабатывается один раз

Токены + UI-компоненты

Реализация в коде

компоненты

Библиотека виджетов

Варианты, настройки и правила размещения

Веб-конструктор

Регистрация виджетов → сборка страниц и настройка бренда

Релиз платформы

Тесты → версия → общая реализация для сайтов

Из веб-конструктора ↓ публикация настроек

Слой бренда — настройки

Тема бренда

Цвета, типографика и ресурсы

Конфигурация сайта · JSON

Страницы, виджеты и выбранные варианты

сайт читает конфигурацию

Frontend сайта

Опубликованный результат: тема + конфигурация + общая реализация

Релиз платформы → Frontend: обновление общей реализации. Публикация настроек → JSON: изменение конфигурации бренда.

08

Delivery

10-step workflow

Once a capability was framed as shared rather than client-specific, it followed one repeatable path:

1

Client or stakeholder expresses a need.

2

Product Owner decides whether it should become a shared capability.

3

Product design defines the component experience, states and behaviour.

4

Design-system owner validates the component contract.

5

Business analysis documents parameters, rules and edge cases.

6

FE architecture defines the technical interface.

7

Development implements the component and configuration schema.

8

QA checks the result against the specification and Figma.

9

The new widget becomes available in the constructor.

10

Relevant clients enable it through configuration or a feature flag — without a redeployment or a client-specific build.

Safe delivery across versions

Patch

compatible fixes; no client action needed

Minor

an additive capability; optional, with no impact on other clients

Major

a contract change; a migration path is required

Shared platform and brand configuration

Figma

system design

Tokens + UI components

in code

Widget library

variants, settings, placement rules

Platform release

tests → version → sites

Web constructor

page building and brand setup

Site frontend

shows the published result

Brand theme

colours, typography, assets

Site configuration · JSON

pages, widgets, variants

tokens

components

widget registration

tests

publish settings

appearance

site reads config

patch / minor without a rebuild

shared code

Shared platform — built once

Brand layer — settings only

08

Delivery

10-step workflow

Once a capability was framed as shared rather than client-specific, it followed one repeatable path:

1

Client or stakeholder expresses a need.

2

Product Owner decides whether it should become a shared capability.

3

Product design defines the component experience, states and behaviour.

4

Design-system owner validates the component contract.

5

Business analysis documents parameters, rules and edge cases.

6

FE architecture defines the technical interface.

7

Development implements the component and configuration schema.

8

QA checks the result against the specification and Figma.

9

The new widget becomes available in the constructor.

10

Relevant clients enable it through configuration or a feature flag — without a redeployment or a client-specific build.

Safe delivery across versions

Patch

compatible fixes; no client action needed

Minor

an additive capability; optional, with no impact on other clients

Major

a contract change; a migration path is required

Shared platform and brand configuration

Figma

system design

Tokens + UI components

in code

Widget library

variants, settings, placement rules

Platform release

tests → version → sites

Web constructor

page building and brand setup

Site frontend

shows the published result

Brand theme

colours, typography, assets

Site configuration · JSON

pages, widgets, variants

tokens

components

widget registration

tests

publish settings

appearance

site reads config

patch / minor without a rebuild

shared code

Shared platform — built once

Brand layer — settings only

08

Delivery

10-step workflow

Once a capability was framed as shared rather than client-specific, it followed one repeatable path:

1

Client or stakeholder expresses a need.

2

Product Owner decides whether it should become a shared capability.

3

Product design defines the component experience, states and behaviour.

4

Design-system owner validates the component contract.

5

Business analysis documents parameters, rules and edge cases.

6

FE architecture defines the technical interface.

7

Development implements the component and configuration schema.

8

QA checks the result against the specification and Figma.

9

The new widget becomes available in the constructor.

10

Relevant clients enable it through configuration or a feature flag — without a redeployment or a client-specific build.

Safe delivery across versions

Patch

compatible fixes; no client action needed

Minor

an additive capability; optional, with no impact on other clients

Major

a contract change; a migration path is required

Shared platform and brand configuration

Figma

System design and token definitions.

tokens and contracts

Shared platform

Built once

Tokens + UI components

Code implementation

components

Widget library

Variants, settings and placement rules

Web constructor

Register widgets → build pages and configure the brand

Platform release

Tests → version → shared site implementation

From the web constructor ↓ publish settings

Brand layer — settings

Brand theme

Colours, typography and assets

Site configuration · JSON

Pages, widgets and selected variants

the site reads configuration

Site frontend

Published result: theme + configuration + shared implementation

Platform release → Frontend: update the shared implementation. Publish settings → JSON: change the brand configuration.

08

Delivery

10-step workflow

Once a capability was framed as shared rather than client-specific, it followed one repeatable path:

1

Client or stakeholder expresses a need.

2

Product Owner decides whether it should become a shared capability.

3

Product design defines the component experience, states and behaviour.

4

Design-system owner validates the component contract.

5

Business analysis documents parameters, rules and edge cases.

6

FE architecture defines the technical interface.

7

Development implements the component and configuration schema.

8

QA checks the result against the specification and Figma.

9

The new widget becomes available in the constructor.

10

Relevant clients enable it through configuration or a feature flag — without a redeployment or a client-specific build.

Safe delivery across versions

Patch

compatible fixes; no client action needed

Minor

an additive capability; optional, with no impact on other clients

Major

a contract change; a migration path is required

Shared platform and brand configuration

Figma

System design and token definitions.

tokens and contracts

Shared platform

Built once

Tokens + UI components

Code implementation

components

Widget library

Variants, settings and placement rules

Web constructor

Register widgets → build pages and configure the brand

Platform release

Tests → version → shared site implementation

From the web constructor ↓ publish settings

Brand layer — settings

Brand theme

Colours, typography and assets

Site configuration · JSON

Pages, widgets and selected variants

the site reads configuration

Site frontend

Published result: theme + configuration + shared implementation

Platform release → Frontend: update the shared implementation. Publish settings → JSON: change the brand configuration.

09

Результат

Продуктовый результат

•

единая модель страниц, виджетов, тем и адаптивного поведения для всех клиентов;

•

чёткое разделение структуры продукта и выражения бренда;

•

путь от изолированных запросов клиентов к переиспользуемым возможностям платформы;

•

версионируемая модель для развития общего продукта без поломок.

Дизайн-результат

•

архитектура тем на токенах;

•

переиспользуемая модель виджетов вместо штучных компонентов под клиента;

•

общий для всех брендов workflow адаптивной композиции;

•

прогрессивные уровни управления (Quick / Expert) под разный опыт пользователя;

•

более чёткая, прослеживаемая связь между Figma, конфигурацией и реализацией.

Ожидаемый бизнес-эффект · без публичных показателей

•

более быстрый запуск нового white-label бренда;

•

меньше дизайн- и инженерных затрат на клиента;

•

более широкое переиспользование фиксов и новых фич по всему портфелю;

•

более стабильное качество между брендами;

•

меньше накопленного дизайн- и технического долга со временем.

Как оценивать решение

Сроки, масштаб внедрения и внутренние показатели конфиденциальны. Ниже — критерии оценки решения; они не представлены как достигнутые результаты.

01 Скорость сетапа

Время от согласованной задачи до конфигурации, прошедшей проверку.

Сравнивать задачи одинакового объёма и отдельно учитывать ожидание согласований.

02 Повторная работа

Ручные копии, локальные исключения и переносы исправлений.

Считать отдельно настройки бренда и изменения общего кода.

04 Качество результата

Ошибки конфигурации и UI-регрессии после изменения.

Сокращение времени полезно только при сохранении качества.

06 Самостоятельность команды

Завершение задачи без помощи и обращения к документации.

Оценивать отдельно новичков и опытных пользователей.

Рефлексия

Сложность редко была в конкретном экране — в основном в том, какие различия клиентов заслуживали стать постоянными системными понятиями, а какие были шумом, который вообще не стоило кастомизировать. Это разделение и есть настоящая дизайн-работа за интерфейсом конструктора. Второй урок — про роль дизайнера в такой системе: большую часть решений я принимал не в макетах, а на стыке с FE-архитектурой и бизнес-анализом — в терминах контрактов, схем и версий. Умение говорить на этом языке оказалось важнее, чем ещё один экран. Главный вывод: повторяемые различия стоит превращать в понятные настройки, а не в новые копии продукта. Но границы конфигурации так же важны, как её гибкость. Для дизайнера это означает связать действия Setup-команды с ограничениями системы: что можно изменить, что затронет другие экраны и как проверить результат до публикации.

Что дальше

Следующий инструмент — управление запуском white-label брендов. Сотруднику нужно видеть, готов ли бренд к запуску, какие настройки уже применены, где проблема и кто должен её исправить. В зоне: список проектов и сравнение по метрикам (рынок, версия, ответственный, готовность), статусы «в работе / на проверке / заблокировано / запущено», конфликты настроек, история изменений и права доступа. Это уже тема отдельного кейса.

09

Результат

Продуктовый результат

•

единая модель страниц, виджетов, тем и адаптивного поведения для всех клиентов;

•

чёткое разделение структуры продукта и выражения бренда;

•

путь от изолированных запросов клиентов к переиспользуемым возможностям платформы;

•

версионируемая модель для развития общего продукта без поломок.

Дизайн-результат

•

архитектура тем на токенах;

•

переиспользуемая модель виджетов вместо штучных компонентов под клиента;

•

общий для всех брендов workflow адаптивной композиции;

•

прогрессивные уровни управления (Quick / Expert) под разный опыт пользователя;

•

более чёткая, прослеживаемая связь между Figma, конфигурацией и реализацией.

Ожидаемый бизнес-эффект · без публичных показателей

•

более быстрый запуск нового white-label бренда;

•

меньше дизайн- и инженерных затрат на клиента;

•

более широкое переиспользование фиксов и новых фич по всему портфелю;

•

более стабильное качество между брендами;

•

меньше накопленного дизайн- и технического долга со временем.

Как оценивать решение

Сроки, масштаб внедрения и внутренние показатели конфиденциальны. Ниже — критерии оценки решения; они не представлены как достигнутые результаты.

01 Скорость сетапа

Время от согласованной задачи до конфигурации, прошедшей проверку.

Сравнивать задачи одинакового объёма и отдельно учитывать ожидание согласований.

02 Повторная работа

Ручные копии, локальные исключения и переносы исправлений.

Считать отдельно настройки бренда и изменения общего кода.

04 Качество результата

Ошибки конфигурации и UI-регрессии после изменения.

Сокращение времени полезно только при сохранении качества.

06 Самостоятельность команды

Завершение задачи без помощи и обращения к документации.

Оценивать отдельно новичков и опытных пользователей.

Рефлексия

Сложность редко была в конкретном экране — в основном в том, какие различия клиентов заслуживали стать постоянными системными понятиями, а какие были шумом, который вообще не стоило кастомизировать. Это разделение и есть настоящая дизайн-работа за интерфейсом конструктора. Второй урок — про роль дизайнера в такой системе: большую часть решений я принимал не в макетах, а на стыке с FE-архитектурой и бизнес-анализом — в терминах контрактов, схем и версий. Умение говорить на этом языке оказалось важнее, чем ещё один экран. Главный вывод: повторяемые различия стоит превращать в понятные настройки, а не в новые копии продукта. Но границы конфигурации так же важны, как её гибкость. Для дизайнера это означает связать действия Setup-команды с ограничениями системы: что можно изменить, что затронет другие экраны и как проверить результат до публикации.

Что дальше

Следующий инструмент — управление запуском white-label брендов. Сотруднику нужно видеть, готов ли бренд к запуску, какие настройки уже применены, где проблема и кто должен её исправить. В зоне: список проектов и сравнение по метрикам (рынок, версия, ответственный, готовность), статусы «в работе / на проверке / заблокировано / запущено», конфликты настроек, история изменений и права доступа. Это уже тема отдельного кейса.

09

Результат

Продуктовый результат

•

единая модель страниц, виджетов, тем и адаптивного поведения для всех клиентов;

•

чёткое разделение структуры продукта и выражения бренда;

•

путь от изолированных запросов клиентов к переиспользуемым возможностям платформы;

•

версионируемая модель для развития общего продукта без поломок.

Дизайн-результат

•

архитектура тем на токенах;

•

переиспользуемая модель виджетов вместо штучных компонентов под клиента;

•

общий для всех брендов workflow адаптивной композиции;

•

прогрессивные уровни управления (Quick / Expert) под разный опыт пользователя;

•

более чёткая, прослеживаемая связь между Figma, конфигурацией и реализацией.

Ожидаемый бизнес-эффект · без публичных показателей

•

более быстрый запуск нового white-label бренда;

•

меньше дизайн- и инженерных затрат на клиента;

•

более широкое переиспользование фиксов и новых фич по всему портфелю;

•

более стабильное качество между брендами;

•

меньше накопленного дизайн- и технического долга со временем.

Как оценивать решение

Сроки, масштаб внедрения и внутренние показатели конфиденциальны. Ниже — критерии оценки решения; они не представлены как достигнутые результаты.

01 Скорость сетапа

Время от согласованной задачи до конфигурации, прошедшей проверку.

Сравнивать задачи одинакового объёма и отдельно учитывать ожидание согласований.

02 Повторная работа

Ручные копии, локальные исключения и переносы исправлений.

Считать отдельно настройки бренда и изменения общего кода.

04 Качество результата

Ошибки конфигурации и UI-регрессии после изменения.

Сокращение времени полезно только при сохранении качества.

06 Самостоятельность команды

Завершение задачи без помощи и обращения к документации.

Оценивать отдельно новичков и опытных пользователей.

Рефлексия

Сложность редко была в конкретном экране — в основном в том, какие различия клиентов заслуживали стать постоянными системными понятиями, а какие были шумом, который вообще не стоило кастомизировать. Это разделение и есть настоящая дизайн-работа за интерфейсом конструктора. Второй урок — про роль дизайнера в такой системе: большую часть решений я принимал не в макетах, а на стыке с FE-архитектурой и бизнес-анализом — в терминах контрактов, схем и версий. Умение говорить на этом языке оказалось важнее, чем ещё один экран. Главный вывод: повторяемые различия стоит превращать в понятные настройки, а не в новые копии продукта. Но границы конфигурации так же важны, как её гибкость. Для дизайнера это означает связать действия Setup-команды с ограничениями системы: что можно изменить, что затронет другие экраны и как проверить результат до публикации.

Что дальше

Следующий инструмент — управление запуском white-label брендов. Сотруднику нужно видеть, готов ли бренд к запуску, какие настройки уже применены, где проблема и кто должен её исправить. В зоне: список проектов и сравнение по метрикам (рынок, версия, ответственный, готовность), статусы «в работе / на проверке / заблокировано / запущено», конфликты настроек, история изменений и права доступа. Это уже тема отдельного кейса.

09

Результат

Продуктовый результат

•

единая модель страниц, виджетов, тем и адаптивного поведения для всех клиентов;

•

чёткое разделение структуры продукта и выражения бренда;

•

путь от изолированных запросов клиентов к переиспользуемым возможностям платформы;

•

версионируемая модель для развития общего продукта без поломок.

Дизайн-результат

•

архитектура тем на токенах;

•

переиспользуемая модель виджетов вместо штучных компонентов под клиента;

•

общий для всех брендов workflow адаптивной композиции;

•

прогрессивные уровни управления (Quick / Expert) под разный опыт пользователя;

•

более чёткая, прослеживаемая связь между Figma, конфигурацией и реализацией.

Ожидаемый бизнес-эффект · без публичных показателей

•

более быстрый запуск нового white-label бренда;

•

меньше дизайн- и инженерных затрат на клиента;

•

более широкое переиспользование фиксов и новых фич по всему портфелю;

•

более стабильное качество между брендами;

•

меньше накопленного дизайн- и технического долга со временем.

Как оценивать решение

Сроки, масштаб внедрения и внутренние показатели конфиденциальны. Ниже — критерии оценки решения; они не представлены как достигнутые результаты.

01 Скорость сетапа

Время от согласованной задачи до конфигурации, прошедшей проверку.

Сравнивать задачи одинакового объёма и отдельно учитывать ожидание согласований.

02 Повторная работа

Ручные копии, локальные исключения и переносы исправлений.

Считать отдельно настройки бренда и изменения общего кода.

04 Качество результата

Ошибки конфигурации и UI-регрессии после изменения.

Сокращение времени полезно только при сохранении качества.

06 Самостоятельность команды

Завершение задачи без помощи и обращения к документации.

Оценивать отдельно новичков и опытных пользователей.

Рефлексия

Сложность редко была в конкретном экране — в основном в том, какие различия клиентов заслуживали стать постоянными системными понятиями, а какие были шумом, который вообще не стоило кастомизировать. Это разделение и есть настоящая дизайн-работа за интерфейсом конструктора. Второй урок — про роль дизайнера в такой системе: большую часть решений я принимал не в макетах, а на стыке с FE-архитектурой и бизнес-анализом — в терминах контрактов, схем и версий. Умение говорить на этом языке оказалось важнее, чем ещё один экран. Главный вывод: повторяемые различия стоит превращать в понятные настройки, а не в новые копии продукта. Но границы конфигурации так же важны, как её гибкость. Для дизайнера это означает связать действия Setup-команды с ограничениями системы: что можно изменить, что затронет другие экраны и как проверить результат до публикации.

Что дальше

Следующий инструмент — управление запуском white-label брендов. Сотруднику нужно видеть, готов ли бренд к запуску, какие настройки уже применены, где проблема и кто должен её исправить. В зоне: список проектов и сравнение по метрикам (рынок, версия, ответственный, готовность), статусы «в работе / на проверке / заблокировано / запущено», конфликты настроек, история изменений и права доступа. Это уже тема отдельного кейса.

09

Result

Product outcome

•

a unified model for pages, widgets, themes and responsive behaviour across clients;

•

a clear separation between product structure and brand expression;

•

a path from isolated client requests to reusable platform capabilities;

•

a versioned model for evolving the shared product safely.

Design outcome

•

token-based theme architecture;

•

a reusable widget model instead of bespoke components for each client;

•

a shared responsive-composition workflow across brands;

•

progressive controls (Quick / Expert) for different levels of user experience;

•

a clearer, traceable link between Figma, configuration and implementation.

Expected business impact · no public metrics

•

faster launches for new white-label brands;

•

less design and engineering effort per client;

•

wider reuse of fixes and new features across the portfolio;

•

more consistent quality across brands;

•

less accumulated design and technical debt over time.

How to evaluate the solution

Timelines, rollout scope and internal metrics are confidential. The criteria below describe how to evaluate the solution; they are not presented as achieved results.

01 Setup speed

Time from an agreed task to a validated configuration.

Compare tasks of equal scope and track approval waiting time separately.

02 Repeated work

Manual copies, local exceptions and propagated fixes.

Count brand configuration separately from shared-code changes.

04 Output quality

Configuration errors and UI regressions after a change.

Time savings only matter if quality is maintained.

06 Team autonomy

Task completion without help or consulting documentation.

Evaluate new and experienced users separately.

Reflection

The difficulty was rarely in an individual screen. It lay in deciding which client differences deserved to become lasting system concepts and which were noise that should never become customisation options. Making that distinction is the design work behind the constructor’s interface. The second lesson concerns the designer’s role: I made most decisions at the intersection of FE architecture and business analysis, in terms of contracts, schemas and versions. Speaking that language proved more valuable than producing another screen. The main takeaway: turn recurring differences into understandable settings rather than new product copies. Configuration boundaries matter as much as flexibility. For a designer, that means connecting the setup team’s actions to system constraints: what can change, what affects other screens and how to check the result before publishing.

What’s next

The next tool is white-label brand launch management. Team members need to see whether a brand is ready to launch, which settings are applied, where a problem is and who should resolve it. The scope includes a project list and comparisons by market, version, owner and readiness; statuses such as in progress, in review, blocked and launched; configuration conflicts, change history and permissions. That is a separate case study.

09

Result

Product outcome

•

a unified model for pages, widgets, themes and responsive behaviour across clients;

•

a clear separation between product structure and brand expression;

•

a path from isolated client requests to reusable platform capabilities;

•

a versioned model for evolving the shared product safely.

Design outcome

•

token-based theme architecture;

•

a reusable widget model instead of bespoke components for each client;

•

a shared responsive-composition workflow across brands;

•

progressive controls (Quick / Expert) for different levels of user experience;

•

a clearer, traceable link between Figma, configuration and implementation.

Expected business impact · no public metrics

•

faster launches for new white-label brands;

•

less design and engineering effort per client;

•

wider reuse of fixes and new features across the portfolio;

•

more consistent quality across brands;

•

less accumulated design and technical debt over time.

How to evaluate the solution

Timelines, rollout scope and internal metrics are confidential. The criteria below describe how to evaluate the solution; they are not presented as achieved results.

01 Setup speed

Time from an agreed task to a validated configuration.

Compare tasks of equal scope and track approval waiting time separately.

02 Repeated work

Manual copies, local exceptions and propagated fixes.

Count brand configuration separately from shared-code changes.

04 Output quality

Configuration errors and UI regressions after a change.

Time savings only matter if quality is maintained.

06 Team autonomy

Task completion without help or consulting documentation.

Evaluate new and experienced users separately.

Reflection

The difficulty was rarely in an individual screen. It lay in deciding which client differences deserved to become lasting system concepts and which were noise that should never become customisation options. Making that distinction is the design work behind the constructor’s interface. The second lesson concerns the designer’s role: I made most decisions at the intersection of FE architecture and business analysis, in terms of contracts, schemas and versions. Speaking that language proved more valuable than producing another screen. The main takeaway: turn recurring differences into understandable settings rather than new product copies. Configuration boundaries matter as much as flexibility. For a designer, that means connecting the setup team’s actions to system constraints: what can change, what affects other screens and how to check the result before publishing.

What’s next

The next tool is white-label brand launch management. Team members need to see whether a brand is ready to launch, which settings are applied, where a problem is and who should resolve it. The scope includes a project list and comparisons by market, version, owner and readiness; statuses such as in progress, in review, blocked and launched; configuration conflicts, change history and permissions. That is a separate case study.

09

Result

Product outcome

•

a unified model for pages, widgets, themes and responsive behaviour across clients;

•

a clear separation between product structure and brand expression;

•

a path from isolated client requests to reusable platform capabilities;

•

a versioned model for evolving the shared product safely.

Design outcome

•

token-based theme architecture;

•

a reusable widget model instead of bespoke components for each client;

•

a shared responsive-composition workflow across brands;

•

progressive controls (Quick / Expert) for different levels of user experience;

•

a clearer, traceable link between Figma, configuration and implementation.

Expected business impact · no public metrics

•

faster launches for new white-label brands;

•

less design and engineering effort per client;

•

wider reuse of fixes and new features across the portfolio;

•

more consistent quality across brands;

•

less accumulated design and technical debt over time.

How to evaluate the solution

Timelines, rollout scope and internal metrics are confidential. The criteria below describe how to evaluate the solution; they are not presented as achieved results.

01 Setup speed

Time from an agreed task to a validated configuration.

Compare tasks of equal scope and track approval waiting time separately.

02 Repeated work

Manual copies, local exceptions and propagated fixes.

Count brand configuration separately from shared-code changes.

04 Output quality

Configuration errors and UI regressions after a change.

Time savings only matter if quality is maintained.

06 Team autonomy

Task completion without help or consulting documentation.

Evaluate new and experienced users separately.

Reflection

The difficulty was rarely in an individual screen. It lay in deciding which client differences deserved to become lasting system concepts and which were noise that should never become customisation options. Making that distinction is the design work behind the constructor’s interface. The second lesson concerns the designer’s role: I made most decisions at the intersection of FE architecture and business analysis, in terms of contracts, schemas and versions. Speaking that language proved more valuable than producing another screen. The main takeaway: turn recurring differences into understandable settings rather than new product copies. Configuration boundaries matter as much as flexibility. For a designer, that means connecting the setup team’s actions to system constraints: what can change, what affects other screens and how to check the result before publishing.

What’s next

The next tool is white-label brand launch management. Team members need to see whether a brand is ready to launch, which settings are applied, where a problem is and who should resolve it. The scope includes a project list and comparisons by market, version, owner and readiness; statuses such as in progress, in review, blocked and launched; configuration conflicts, change history and permissions. That is a separate case study.

09

Result

Product outcome

•

a unified model for pages, widgets, themes and responsive behaviour across clients;

•

a clear separation between product structure and brand expression;

•

a path from isolated client requests to reusable platform capabilities;

•

a versioned model for evolving the shared product safely.

Design outcome

•

token-based theme architecture;

•

a reusable widget model instead of bespoke components for each client;

•

a shared responsive-composition workflow across brands;

•

progressive controls (Quick / Expert) for different levels of user experience;

•

a clearer, traceable link between Figma, configuration and implementation.

Expected business impact · no public metrics

•

faster launches for new white-label brands;

•

less design and engineering effort per client;

•

wider reuse of fixes and new features across the portfolio;

•

more consistent quality across brands;

•

less accumulated design and technical debt over time.

How to evaluate the solution

Timelines, rollout scope and internal metrics are confidential. The criteria below describe how to evaluate the solution; they are not presented as achieved results.

01 Setup speed

Time from an agreed task to a validated configuration.

Compare tasks of equal scope and track approval waiting time separately.

02 Repeated work

Manual copies, local exceptions and propagated fixes.

Count brand configuration separately from shared-code changes.

04 Output quality

Configuration errors and UI regressions after a change.

Time savings only matter if quality is maintained.

06 Team autonomy

Task completion without help or consulting documentation.

Evaluate new and experienced users separately.

Reflection

The difficulty was rarely in an individual screen. It lay in deciding which client differences deserved to become lasting system concepts and which were noise that should never become customisation options. Making that distinction is the design work behind the constructor’s interface. The second lesson concerns the designer’s role: I made most decisions at the intersection of FE architecture and business analysis, in terms of contracts, schemas and versions. Speaking that language proved more valuable than producing another screen. The main takeaway: turn recurring differences into understandable settings rather than new product copies. Configuration boundaries matter as much as flexibility. For a designer, that means connecting the setup team’s actions to system constraints: what can change, what affects other screens and how to check the result before publishing.

What’s next

The next tool is white-label brand launch management. Team members need to see whether a brand is ready to launch, which settings are applied, where a problem is and who should resolve it. The scope includes a project list and comparisons by market, version, owner and readiness; statuses such as in progress, in review, blocked and launched; configuration conflicts, change history and permissions. That is a separate case study.