Подготовка события
14 → 4 дняСборка из модулей вместо проекта с нуляКейс № 02 · SaaS · Events · 2022–23 · GCC
Каждое мероприятиесобиралось с нуля за двенедели и съедало всю команду.Теперь — 4 дня и клиентнастраивает сам.
Кейс за минуту
Подробнее о результате ↓- Моя роль
- Единственный продуктовый дизайнер, затем руководитель дизайн-направления
- Ключевое решение
- Заменить разработку каждого события с нуля на модульную платформу с 5 ролевыми интерфейсами.
- Результат
- Сборка 14→4 дня · самостоятельная настройка 0→80% · 1–2→3–6 параллельных проектов.
TL;DR — что изменилось
MetaKit превратил кастомную разработку событий в self-service продукт.
Project lead time
6 → 1 месКоманда впервые могла обещать срокиПараллельные проекты
1–2 → 3–6Потолок роста перестал упираться в devSelf-service
0 → 80%Рутинные изменения клиент делает самCSAT
4.8/5По пост-ивент опросам клиентовEventagrate делает виртуальные мероприятия для корпоратов GCC. Каждый проект собирался как стартап с нуля: кастомная разработка, кранчи, сделки уходили к конкурентам. Задача — превратить это в продукт, где клиент собирает событие без 20 созвонов.
Метрики собраны по таймлайнам реальных проектов, доле задач без dev/саппорта и пост-ивент опросам клиентов.
01 Проблема
Каждое событие было новым продуктом, а live-сценарий не прощал ошибок.
Контекст
Клиент приходил в Eventagrate не за интерфейсом, а за готовым мероприятием в метаверсе: 3D-пространство, зоны, экраны, трансляции, модерация, роли и контент под конкретный запуск.
Каждый раз большая часть системы собиралась заново. Даже небольшие изменения — логотип на стенде, название комнаты, текст на экране — проходили через Eventagrate.
Пока один проект шёл к запуску, взять параллельно второй было почти невозможно. Потолок был не в нехватке клиентов, а в том, как работала система.
Пользователь
Клиенты хотели настраивать события сами, без 20 созвонов по каждому поводу. Но любой контент, роль или настройка требовали ручного вмешательства. Поверх — страх live: когда 2000 человек онлайн, модератору нужна уверенность в каждом действии, а организатору — состояние системы в один взгляд.
Бизнес
Команда Eventagrate не могла обещать сроки. Сделки уходили к конкурентам, пока команда была занята предыдущим проектом. Вести больше 1–2 проектов параллельно было невозможно. Потолок роста — в dev-ресурсе, а не в спросе.
5 ролей с разными задачамиLive-сценарии без права на промахSelf-service без страха сломать эфирДесятки экранов без расползания системы
02 Моя роль
Я проектировал не админку для всех, а продукт, который заменяет кастомную разработку.
Зона ответственности
Единственный дизайнер на продукте. Провёл 5 интервью, спроектировал архитектуру под 5 ролей, собрал ключевые флоу и design system, сопровождал реализацию и проверял итерации на живых событиях.
Задача
Превратить кастом-разработку в продукт с клиентским self-service: Roles & Permissions → Content → Moderation → Analytics, safe-сценарии и дизайн-система под долгие сессии мониторинга.
03 Исследование
Каждой роли нужен свой темп, контекст и уровень защиты.
5 интервью с людьми, которые руками выводят события в эфир — организаторы, модераторы, клиентские админы. Дальше — итерации на реальных проектах: выкатывали версии на ближайшие события, смотрели, где ломается сценарий, исправляли.
Универсальный UI = всем неудобно одинаково
Модератор видит финансы, контент-менеджер — системные настройки, клиент — внутреннюю кухню агентства.
Live — это стресс, в котором ошибаются
Нужны не больше функций, а протекты от случайных промахов.
Клиент хочет контроль, но боится live
Противоречие решается превью-режимом и откатом, а не запретом правок.
Dashboard отвечает «всё ок или горит?»
Это операционный центр во время события, а не аналитика для отчётов.
«Клиент подписал контракт на саммит через 4 недели — хочу собрать событие из готовых модулей, а не писать ТЗ.»
«Поменялся спикер за 2 дня до события — хочу обновить стенд сам, без созвона с агентством.»
«2000 человек в чате, спам и провокации — хочу банить быстро и не заблокировать не того пользователя.»
РольСитуацияЗадачаПрепятствия раньшеРешение в MetaKit
OrganizerСроки жёсткие, клиент подписал контрактСобрать событие из блоков, вывести в liveКастом-разработка, 20+ созвонов, нет сроковКонфигуратор, шаблоны модулей, ~4 дня до go-live
Client AdminПоменять стенд за 2 дня до событияОбновить без созвона с агентствомНет доступа к правкам, всё через devSelf-service, превью, откат в один клик
Content ManagerДесятки стендов, брендинг, расписаниеУвидеть изменения до публикацииПравки вручную, риск сломать liveDrafts + preview, изменения с откатом
Moderator2000 человек в чате, спамБанить быстро без промаховСтресс live, легко ошибиться в юзереSafe actions: confirm на деструктивных
Tech AdminНовый клиент, интеграции с CRMНастроить системные параметры разКастом-работа на каждый проектПереиспользуемые интеграции в админке
04 Как изменился сценарий
Из стартапа с нуля — в конструктор события с модулями и self-service.
Было
- 20+ созвонов между клиентом и продактами
- Разработка под каждое событие
- Непредсказуемые сроки из-за очереди в разработке
- Кранчи перед запуском как обязательный этап
Стало
- Шаблоны и модули: Roles → Content → Moderation → Analytics
- ~80% рутинных изменений клиент делает без агентства
- Агентство может обещать дату на этапе продаж
- Dev-ресурс нужен только на нестандартные интеграции
05 Развилки
Четыре продуктовые развилки определили архитектуру MetaKit.
Доступ
Универсальный UI или роли?
АльтернативаОдна админка для всех
Быстрее в разработке, проще в поддержке
Почему не подошло
Каждая роль всё равно ищет своё сквозь чужие экраны
Решение5 ролевых интерфейсов
Каждая роль видит только свои задачи; ниже support и онбординг
Архитектура
Монолит или модули?
АльтернативаЕдиная платформа
Общие настройки для всех форматов
Почему не подошло
Форматы слишком разные: от брифинга до конференции на 2000
РешениеМодульная архитектура
Каждый модуль независим, событие собирается под формат
Опасные действия
Разрешения или протекты?
АльтернативаТолько права доступа
Явно разделить, кто может банить
Почему не подошло
Проблема в стрессе: легко разбанить не того
РешениеSafe actions
Деструктивные действия требуют подтверждения
Live-контент
Доверие или блокировка?
АльтернативаЗапретить изменения в live
Безопаснее для репутации
Почему не подошло
Закрывает главный запрос клиента — «хочу менять сам»
РешениеDrafts + preview + откат
Контроль у клиента, риск сломать live минимальный
06 Проверка на реальных событиях
Каждая итерация проверялась не в лаборатории, а на событиях с последствиями.
Каждый выпуск новой версии проходил на реальном событии с участниками, организаторами и последствиями.
Dashboard
Первая версия была аналитической — модератор не успевал её читать. Переделали в операционный экран: статусы зелёным/красным, короткие алерты, минимум цифр.
Chat Management
Модераторы ошибались в юзерах при банах: похожие никнеймы, длинный список. Добавили confirm и расширенный попап с информацией о пользователе.
Content Manager
Клиент случайно опубликовал черновик на тестовом событии. Переделали через drafts: изменения сохраняются, но публикуются только явным действием.
07 Решения
Пять слоёв, которые превратили event-проекты в продукт.
Модульная архитектура
Roles & Permissions → Content → Moderation → Analytics. Система как набор независимых блоков, которые собираются в событие под нужный формат.
Эффект: один продукт под разные форматы событийРоли вместо универсальной админки
5 ролевых интерфейсов на общей design system: Organizer, Client Admin, Content Manager, Moderator, Tech Admin.
Эффект: онбординг новой роли — час вместо дняDashboard как операционный центр
Не аналитика для отчётов, а ответ на один вопрос — «всё ок или горит?» Статусы цветом, короткие алерты, мгновенный вердикт.
Эффект: состояние события видно в один взглядSafe actions для live-модерации
Деструктивные действия требуют подтверждения. Расширенный попап показывает информацию о пользователе перед баном.
Эффект: промахи модераторов в live упалиSelf-service для клиента
Клиент готовит изменения в драфте, видит превью, публикует когда уверен. Откат — в один клик.
Эффект: ~80% рутинных изменений без агентства08 Витрина
Пять слоёв витрины — тот же продукт глазами гостя.
Основной кейс — система со стороны организатора. Витрина показывает обратную сторону экрана: как тот же продукт выглядит для участника в 3D-зале. Полный путь — от входа до live-зала и оверлеев:
Интерфейс поверх 3D-зала
Интерфейс участника — отдельный слой поверх 3D-сцены: лёгкое «жидкое стекло» с чатом слева, навигацией по зонам сверху и действиями снизу. Панели прижаты к краям и притушены, чтобы сцена и присутствие оставались в центре.
Эффект: UI поверх сцены, не разрушая погружениеЧат как привычный мессенджер
Имена и аватары вместо хешей, группировка реплик, реакции, статусы прочтения — паттерны привычного мессенджера.
Эффект: порог входа в общение практически нулевойExpress: сказать · показать · отреагировать
Три разрозненные кнопки — фразы, эмоции, анимации — свёл в один хаб с вкладками Say / Do / React.
Эффект: 3 кнопки → один понятный хабЛокализация на присутствие
Фразы — закрытый набор, поэтому летят ключом и рендерятся у каждого на его языке. Интерфейс зеркалится в RTL целиком, без правок контента.
Эффект: один контент, комфортный на любом языкеПереодеть, а не переписать
Кастомизация под клиента живёт на токенах: смена бренд-цвета одной переменной перекрашивает весь зал, без правок экранов.
Эффект: новый клиент без переписывания системы09 Design System
Без дизайн-системы 5 ролей и десятки экранов расползлись бы за один спринт.
Dark theme с «заглублением»
Карточки темнее фона. Меньше контраста = меньше усталости в долгих сессиях мониторинга. Решение пришло из наблюдений за модераторами: после 4 часов в светлой теме внимание садится.
Цвет и компоненты
Зелёный #37CA8C — primary actions и online/live статусы. Красный — только деструктивные действия, никогда для акцента. Компоненты: buttons, inputs, tabs со счётчиками, badges, tables.
10 Влияние
Команда Eventagrate перестала работать в режиме «каждый проект — новый стартап».
На команду
Команда впервые могла обещать сроки клиенту на этапе продаж. Кранчи перед запуском исчезли как обязательный этап, dev-ресурс нужен только на нестандартные интеграции. Параллельно стало возможно вести 3–6 проектов вместо 1–2.
На бизнес
- Быстрее закрывали сделки — могли обещать сроки
- Меньше инцидентов и кранчей перед запуском
- Потолок роста сместился со скорости разработки на скорость продаж
МетрикаБылоСтало
Конфигурация события~14 дней~4 дня
Project lead time~6 мес~1 мес
Параллельных проектов1–23–6
Self-service0%80%
11 Итог
Главная инвестиция — в роли, защиту от live-стресса и дизайн-систему.
Что я унёс
Универсальный интерфейс выглядит дешевле и проще, но в продукте, где у каждой роли свой стресс и свой темп, он не работает. Safe actions — не про недоверие к пользователю, а про защиту от стресса.
Система
Design system при таком объёме экранов — не «приятно иметь», а «без неё всё развалится за месяц». Без токенов и компонентов 5 ролей × десятки экранов превратились бы в зоопарк за спринт.
Что сделал бы иначе
Раньше зафиксировал бы baseline-метрики
Self-service, время подготовки, CSAT — всё измеряли постфактум. С baseline импакт выглядел бы убедительнее.
Тестировал бы dashboard на live раньше
Первая версия была аналитической и не работала во время событий. Это выяснилось на итерациях, но проблему можно было обнаружить раньше.
Раньше вовлёк бы операционную команду
Модераторы и контент-менеджеры реагировали на проблемы уже в продакшне. Часть итераций можно было сделать дешевле.
