Overview
SOFTSWISS provides a platform for multiple casino brands and operators. The Setup design team adapts and launches client products on top of that shared foundation — its own discipline, distinct from the platform's core product design (see the companion case, Master Layout).
SOFTSWISS предоставляет платформу для нескольких казино-брендов и операторов. Setup-команда дизайнеров адаптирует и запускает клиентские продукты поверх этой общей основы — отдельная дисциплина, отличная от продуктового дизайна самой платформы (см. смежный кейс Master Layout).
Starting Point
- processes were fragmented — each designer approached setup work their own way;
- no unified standards for quality, review or handoff;
- responsibility was unevenly distributed across the team;
- output quality depended heavily on which specific designer ran a project;
- scaling to more clients and more designers was getting harder, not easier;
- a large share of the work was manual and repetitive;
- the connection between design decisions and front-end implementation was looser than it should have been.
- процессы были разрозненными — каждый дизайнер подходил к setup-работе по-своему;
- не было единых стандартов качества, review или handoff;
- ответственность была распределена неравномерно;
- качество результата сильно зависело от того, какой конкретно дизайнер вёл проект;
- масштабирование на больше клиентов и дизайнеров становилось сложнее, а не проще;
- значительная часть работы была ручной и повторяющейся;
- связь между дизайн-решениями и реализацией во frontend была слабее, чем нужно.
Leadership Challenge
As a lead, the problem wasn't any single project — it was building the conditions for the team to reliably deliver good work at a growing scale:
- build and grow the team itself;
- raise and stabilize the quality of setup projects;
- speed up delivery without sacrificing consistency;
- establish shared processes the whole team could rely on;
- introduce a design system that could scale across brands;
- strengthen collaboration with Product and Front-end;
- bring AI tools into the workflow without letting quality slip.
Как для лида, проблема была не в конкретном проекте — а в том, чтобы создать условия, при которых команда могла бы надёжно поставлять хорошую работу при растущем масштабе:
- собрать и развить саму команду;
- поднять и стабилизировать качество setup-проектов;
- ускорить delivery, не жертвуя согласованностью;
- выстроить общие процессы, на которые могла бы опираться вся команда;
- внедрить дизайн-систему, масштабируемую на разные бренды;
- укрепить взаимодействие с Product и Frontend;
- внедрить AI-инструменты, не потеряв в качестве.
Building the Team
Growing a design function is people work first, process work second. This meant taking part in hiring, shaping how the team was structured, and building an environment where designers could develop past their starting level:
- participated in hiring as the team grew;
- defined role structure and ownership — who owns what, and why;
- built a structured onboarding path for new designers, independent of informal mentorship;
- supported the growth of middle and senior designers specifically, not just the team as a whole;
- ran regular 1:1s, PDPs and check-ins — feedback as a habit, not an event;
- worked deliberately on a trusting, creative environment where designers could raise problems early.
Рост дизайн-функции — это в первую очередь работа с людьми, и только потом — с процессом. Это означало участие в найме, формирование структуры команды и создание среды, в которой дизайнеры могли расти выше стартового уровня:
- участвовал в найме по мере роста команды;
- определял структуру ролей и ответственность — кто за что отвечает и почему;
- выстроил структурированный onboarding для новых дизайнеров, не зависящий от неформального наставничества;
- отдельно поддерживал рост middle- и senior-дизайнеров, а не только команды в целом;
- проводил регулярные 1:1, PDP и check-in'ы — фидбек как привычка, а не разовое событие;
- сознательно работал над доверительной творческой средой, где проблемы можно поднимать рано.
Establishing Design Operations
The processes below turned "how a good designer already does this" into something the whole team could rely on, not just tribal knowledge:
- Design review at a consistent point in every project, not improvised per designer;
- a defined setup workflow from brief to release;
- a consistent front-end handoff process instead of an ad-hoc one each time;
- clearer task distribution across the team;
- living documentation and templates, kept current rather than written once and abandoned;
- regular meetings and retrospectives that fed lessons back into the process itself;
- lightweight risk and dependency management for anything non-standard.
Процессы ниже превратили «то, как это уже делает хороший дизайнер» в то, на что могла опереться вся команда, а не только неформальное знание:
- Design review в одной и той же точке каждого проекта, а не по желанию каждого дизайнера;
- определённый setup workflow от брифа до релиза;
- последовательный frontend handoff вместо разового процесса каждый раз;
- более ясное распределение задач по команде;
- живая документация и шаблоны, которые поддерживались в актуальном состоянии, а не писались один раз и забывались;
- регулярные встречи и ретроспективы, возвращавшие уроки обратно в процесс;
- лёгкое управление рисками и зависимостями для всего нестандартного.
Scalable Design System
The Setup team's delivery work depended directly on the platform's design system — the shared components, tokens and customization levels developed as part of Master Layout (the companion case) needed to hold up under everyday setup production, not just in principle:
- a white-label architecture supporting many brands from one system;
- components built to be configured, not forked;
- design tokens and variables as the shared contract between Figma and production;
- layered customization — quick, low-risk changes versus deeper, expert-level control;
- reusable patterns instead of one-off screens per client;
- a traceable link between a Figma component and what actually ships;
- support for multiple brands and markets from the same underlying system.
Delivery-работа Setup-команды напрямую зависела от дизайн-системы платформы — общие компоненты, токены и уровни кастомизации, разработанные в рамках Master Layout (смежный кейс), должны были выдерживать повседневное setup-производство, а не только работать в теории:
- white-label архитектура, поддерживающая много брендов на одной системе;
- компоненты, созданные для конфигурации, а не форка;
- дизайн-токены и переменные как общий контракт между Figma и продакшном;
- слоистая кастомизация — быстрые, малорискованные изменения против более глубокого, экспертного контроля;
- переиспользуемые паттерны вместо разовых экранов под каждого клиента;
- прослеживаемая связь между компонентом в Figma и тем, что реально в продакшне;
- поддержка нескольких брендов и рынков на одной и той же системе.
AI-Assisted Workflows
AI was introduced as a change to the production process, not as a list of tools bolted onto the old one:
- Claude, Cursor, Figma MCP — for prototyping and connecting structured requirements to working front-end;
- ChatGPT / Codex — explored for scripting and repetitive production tasks;
- AI image generation — trialled for casino promotional graphics;
- landing-page automation — reducing manual rebuild work across brands;
- design-system automation — auditing tokens and components for drift and duplication;
- structured research and internal workshops to evaluate tools against real setup tasks, not just novelty.
AI внедрялся как изменение процесса производства, а не как список инструментов, добавленных поверх старого:
- Claude, Cursor, Figma MCP — прототипирование и связь структурированных требований с рабочим frontend;
- ChatGPT / Codex — исследовались для скриптинга и повторяющихся задач;
- AI-генерация изображений — тестировалась для промо-графики казино;
- автоматизация лендингов — снижение ручной пересборки между брендами;
- автоматизация дизайн-системы — аудит токенов и компонентов на расхождения и дублирование;
- структурированные исследования и внутренние воркшопы для оценки инструментов на реальных задачах, а не ради новизны.
Selected Initiatives
Impact
Team Impact
- a grown, more self-sufficient design team;
- clearer development paths for middle and senior designers;
- explicit ownership instead of ambiguous responsibility;
- better day-to-day collaboration across the team.
Process Impact
- more predictable delivery timelines;
- fewer repeated mistakes carried between projects;
- a smoother, more consistent front-end handoff;
- a shared quality bar applied the same way each time.
Product Impact
- a more unified visual language across client brands;
- a design system that actually scales in daily setup use;
- more consistent output across markets and brands;
- a shorter path from design decision to shipped screen.
Strategic Impact
- a stronger, more credible design function inside the company;
- AI-assisted workflows introduced deliberately, not reactively;
- a foundation the team can keep building on as it grows further;
- less dependence on manual, one-off production work.
Влияние на команду
- выросшая, более самостоятельная дизайн-команда;
- более ясные пути развития для middle- и senior-дизайнеров;
- явная ответственность вместо размытой;
- более гладкое повседневное взаимодействие в команде.
Влияние на процесс
- более предсказуемые сроки поставки;
- меньше повторяющихся ошибок между проектами;
- более гладкий, последовательный frontend handoff;
- общая планка качества, применяемая одинаково каждый раз.
Влияние на продукт
- более единый визуальный язык между клиентскими брендами;
- дизайн-система, реально масштабирующаяся в повседневном setup;
- более стабильный результат по рынкам и брендам;
- более короткий путь от дизайн-решения до продакшн-экрана.
Стратегическое влияние
- более сильная, авторитетная дизайн-функция внутри компании;
- AI-assisted workflows внедрены сознательно, а не реактивно;
- основа, на которой команда может продолжать расти дальше;
- меньше зависимости от ручного, разового производства.
Reflection
What worked best was treating the team and the process as the actual design problem — not a side effect of shipping screens. Standardizing the pipeline was more valuable than any single template inside it.
What needed rethinking: some early process rules were tighter than the team actually needed, and had to be loosened once real projects tested them. AI adoption also moved faster in some areas than the evidence justified, which is part of why this case deliberately separates "explored" from "proven."
What I'd take into the next design-leadership role: standardize the process, not the judgment behind it — and treat every new process as a hypothesis to test against real projects, not a policy to enforce from day one.
Лучше всего сработало отношение к команде и процессу как к настоящей дизайн-задаче — а не побочному эффекту выпуска экранов. Стандартизация пайплайна оказалась ценнее любого отдельного шаблона внутри него.
Что потребовало пересмотра: некоторые ранние правила процесса оказались жёстче, чем реально нужно команде, и их пришлось смягчить, когда их проверили реальные проекты. Внедрение AI в некоторых местах тоже опережало доказательства — отчасти поэтому в этом кейсе сознательно разделены «протестировано» и «доказано».
Что я возьму в следующую лидерскую роль: стандартизировать процесс, а не суждение за ним — и относиться к каждому новому процессу как к гипотезе, которую нужно проверить на реальных проектах, а не как к политике, вводимой с первого дня.