Октябрь 2023 - Июнь 2024 MetaKit

Каждое мероприятие собиралось с нуля за две недели и съедало всю команду. Теперь — 4 дня, а клиент управляет значимой частью события сам.

SaaS Events Admin panel Self-service Role-based UX

Подготовка события: 14 дней → 4 дня (−71%)

Срок запуска проекта: ~6 мес → ~1 мес

CSAT: 4.8/5

Самостоятельное управление без разработчиков и саппорта: 0% → 80%

Eventagrate делала виртуальные мероприятия в метаверсе для корпоратов из GCC: министерства, крупные компании, международные конференции. Не просто платформу — а мероприятие под ключ: 3D-пространство, зоны, трансляции, модерация, роли, контент и запуск.

Контекст

Клиент приходил в Eventagrate не за интерфейсом, а за готовым мероприятием в метаверсе. Команда собирала 3D-пространство, зоны, экраны, трансляции, модерацию, роли и контент под конкретный запуск.

Каждый раз большая часть системы собиралась заново. Даже небольшие изменения — логотип на стенде, название комнаты, текст на экране — проходили через Eventagrate.

Пока один проект шёл к запуску, взять параллельно второй было почти невозможно. Eventagrate упирался в потолок не из-за нехватки клиентов, а из-за того, как работала система.

Проблема

Эта модель работала. Но она не масштабировалась.

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

Пока один проект шёл к запуску, на параллельный почти не оставалось ресурса. Eventagrate упирался в потолок роста не из-за нехватки заказов — а из-за того, как была устроена работа внутри.

Моя роль

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

Я вёл проект end-to-end: от разбора клиентских требований и структуры системы — до UI, дизайн-системы и сопровождения реализации.

Команда: PM, фронтенд, бэкенд, я как дизайнер и гендиректор в роли product owner.

Что выяснилось на старте

Классического discovery с интервью здесь не было. Вместо этого у нас был полезный материал: руководитель продаж собрала список из 23 требований — сводку самых частых клиентских запросов из прошлых проектов.

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

Что мы стандартизировали

Вошло в платформу

Контент по зонам и стендам

Названия комнат и agenda

Базовая модерация

Управление ролями

Причина

Повторялось почти в каждом проекте

Частые правки перед запуском

Критично для live сценариев

Нужно для безопасного self-service

Что мы оставили кастомным

Осталось проектным

Digital twin

Аватары и motion capture

Сложные broadcast сценарии

Причина

Сильно зависит от конкретного ивента

Дорогой и сложный кастом

Требовали отдельно настройки

Очень быстро стало видно три вещи.

Контент — главное узкое место. Больше трети запросов касались одного: клиент хочет сам менять логотипы, текстуры, agenda, экраны, названия комнат — без разработчиков. Это самая частая причина созвонов и правок через команду.

Live нельзя отдавать без защиты от ошибки. Трансляции, модерация, Q&A — всё это происходит во время события, когда 2000 человек онлайн. Ошибка здесь стоит слишком дорого. Значит если давать людям больше контроля — нужно думать о безопасности действий.

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

Как перестраивали систему

Разделили доступ по ролям

Вместо одной общей панели — пять ролей с чёткими границами: Organizer, Client Admin, Content Manager, Moderator, Tech Admin.

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

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

Развели подготовку и live как два разных сценария

Это понимание пришло в процессе и сильно повлияло на структуру дашборда.

Подготовка события — спокойный итеративный процесс: настраиваешь, проверяешь, публикуешь, переделываешь. Здесь важны гибкость и предпросмотр.

Live — другой режим.

Модератор открывает систему перед стартом, когда 2000 человек уже онлайн и цена ошибки высока. Первый прототип дашборда был аналитическим: графики, воронки, сравнение по зонам. Но в реальном сценарии стало ясно, что модератору не нужна аналитика. Ему нужно за несколько секунд понять: всё в порядке или что-то горит.

Операционный дашборд MetaKit для live-сценария

Я переделал экран: убрал визуализации в раздел статистики, а на дашборде оставил только операционные сигналы — что требует внимания прямо сейчас, нагрузку по зонам, расписание и статус стрима.

Chat Management в MetaKit с подтверждением деструктивного действия

То же касалось модерации чата. Chat Management — не просто список сообщений, а рабочий инструмент для управления комнатами и пользователями в реальном времени.

Деструктивные действия — бан, отключение комнаты — требуют подтверждения. Не потому что модератору нельзя доверять, а потому что в стрессе легко промахнуться. Это не абстрактная предосторожность: на одном из предыдущих проектов EDGE мы обнаружили на лайве неактивную кнопку — её нельзя было нажать в нужный момент. Исправляли в кранче, это стоило и денег, и репутации. MetaKit проектировался уже с памятью об этом.

Что порезали и почему

Параллельно с этим шла работа по другую сторону стола — что вообще не стоило делать.

3D-пространство — это Unity-сцена. Её собирает команда под конкретный бриф, и это всегда кастом. Никакой админки здесь нет и быть не может. Но внутри любого пространства — логотипы, тексты на экранах, agenda, описания стендов — структура одна и та же от проекта к проекту.

Вопрос был не про фичи, а про границу: где заканчивается кастом и начинается типовое. Мы провели её там: пространство остаётся за командой, контент внутри — переходит к клиенту.

Content Manager строился именно под эту часть — не как редактор сцены, а как менеджер типового контента внутри кастомного пространства.

Всё что выходило за эту границу — нестандартные интеграции, цифровые двойники, захват движений спикеров — шло отдельным модулем. Иногда подключалось к MetaKit, иногда жило само по себе.

Дизайн-система

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

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

Тёмная тема с заглублением — карточки темнее фона. Это не эстетика, а решение под сценарий: модератор смотрит в экран несколько часов подряд. Меньше контраста — меньше усталости.

Цветовая логика строгая: зелёный — только primary actions и live-статусы. Красный — только деструктивные действия: бан, отключение, удаление. Нигде больше. Когда видишь красную кнопку во время эфира — знаешь что это необратимо.

Всё параметризовано через Figma Variables — смена акцентного цвета под конкретного клиента занимала часы, не дни.

Что изменилось после запуска

После запуска Eventagrate перестал быть обязательным оператором каждого события.

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

Проектов действительно стало больше, хотя масштаб у каждого был разным: часть — полноценные ивенты, часть — компактные запуски. Главное изменение было не в цифрах. До MetaKit команда вела мероприятие руками. После — у клиента появилась система для самостоятельного управления, а у команды — ресурс для роста.

Что сделал бы иначе

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

Раньше разделил бы подготовку и live как две отдельные задачи. Это стало очевидным только когда я проверил реальный сценарий модератора перед стартом события. Если бы начал с этого разделения — часть решений появилась бы быстрее и с меньшими переделками.