OmEvent
UX/UI-дизайн event-платформы с несколькими ролями, кабинетами и админ-панелью
UX/UI
Product Design
Admin Panel
Dashboard
Design System
Моя роль
UX/UI Designer /
Product Designer
Команда
Ведущий дизайнер (я)
Основатель
Проектный менеджер
Разработчик
Период
2025-2026
Статус
Начал работу,
в процессе наполнения
Смотреть сайт
О проекте
OmEvent создавался как первый билетный сервис с фокусом на мероприятия в сфере саморазвития: йога, ретриты, медитации и аналогичные форматы. Платформа должна была закрывать задачи сразу нескольких ролей:
  • пользователи ищут мероприятия и покупают билеты;
  • организаторы создают события и управляют продажами;
  • администраторы модерируют платформу
задача
Создать платформу, где пользователи могут находить мероприятия и покупать билеты, организаторы — управлять событиями, продажами и участниками, а администраторы — контролировать работу сервиса через понятную систему модерации и статусов.
Главный вызов дизайна — сделать процесс покупки простым для пользователя, а управление событиями, продажами и выплатами прозрачным для организаторов и команды платформы.
Ключевые результаты
Спроектирована UX/UI-система платформы полного цикла:
Спроектирована публичная часть сервиса: каталог, страницы мероприятий, организаторов и сценарий покупки билета
Создан личный кабинет пользователя с билетами, избранным, подписками, подарками и рефералами
Спроектирован кабинет организатора как рабочий центр управления событиями, участниками, финансами и документами
Разработана админ-панель с единой логикой управления через таблицы, статусы, фильтры и быстрые действия
Собран UI-kit и основа дизайн-системы для масштабирования интерфейса и передачи в разработку
цифры после запуска
70+
зарегистрированных пользователей
40+
созданных мероприятий
30+
присоединившихся организаторов
Подход
Я начала не с отдельных экранов, а с ролей и сценариев: пользователь, организатор, администратор. После этого собрала информационную архитектуру, выделила ключевые пользовательские потоки и только затем перешла к интерфейсам и компонентам.
Пользователь
Ищет мероприятия, изучает детали, покупает билеты, сохраняет события в избранное, подписывается на организаторов, получает бонусы и участвует в реферальной программе
Боли:
  • Нет единого места для поиска такого формата мероприятий: события разбросаны по каналам, чатам и соцсетям
  • Отзывы об организаторе и его репутация зачатую неизвестны
  • Бонусы с отдельных мероприятий являются лишь формальностью: копятся в разных места и не имеют понятной пользы
Интерфейс:
  • Публичная часть
  • Личный кабинет
Инсайт:
Пользователь выбирает не только мероприятие, но и организатора, которому доверяет. Поэтому в интерфейсе была усилена роль организатора: отдельная страница, подписка и отображение в карточках событий
Организатор
Создаёт и редактирует мероприятия, управляет билетами, стоимостью, промокодами, реферальными ссылками, выплатами, отзывами
и соорганизаторами
Боли:
  • Продажи, списки участников, коммуникация и финансы часто ведутся вручную или в разных инструментах
  • Организатору сложно быстро понять, сколько билетов продано, кто записался и сколько денег доступно к выводу
  • Организатору важно продвигать не только отдельные события, но и свою репутацию внутри платформы
Интерфейс:
  • Кабинет организатора
Инсайт:
Организаторы могут быть разного уровня технической подготовки. Поэтому интерфейс должен быть прямым: меньше декоративной сложности, больше понятных таблиц, четких блоков информации, форм и быстрых действий
Администратор
Модерирует события, организаторов, пользователей, отзывы, обращения, выплаты, возвраты, предложения партнёров, промокоды и реферальные связи
Боли:
  • Теряется в большом количестве сущностей управления без единой логики: мероприятия, организаторы, пользователи, рефералы и т.д.
  • Сложно быстро находить нужный объект и принимать решение без лишних шагов
  • Информация разбросана в разных системах учета , что повышает степень ручной работы и риск ошибок
Интерфейс:
  • Кабинет администратора
Инсайт:
Админ-панель должна строиться вокруг единого паттерна управления сущностями. Разделы могут имеют разный контент, но логика работы должна быть одинаковой.
У администратора должен быть быстрый доступ к модерированию (смене статуса) сразу же, без лишних шагов
Информационная архитектура
Публичная часть
Подход
Публичная часть была спроектирована вокруг главного пользовательского пути: быстро найти подходящее мероприятие, получить достаточно информации для выбора и сделать заказа билета.
Каталог мероприятий — главный сценарий входа
страница мероприятий — точка принятия решения
Покупка билета - главный сценарий конверсии
Главная задача сервиса здесь — довести пользователя от выбора билета до оплаты без лишних сомнений и возвратов назад.
Фокус
Сохранила контекст мероприятия на всех этапах оформления:
пользователь видит основные данные о событии и выбранных билетах без возврата назад.
Разделила оформление на три шага: выбор билетов, данные участника и оплата, чтобы упростить сценарий и снизить нагрузку.
страница организатора — фактор доверия
цель пользователя
Найти подходящее событие и легко купить билет на него
Результат
Пользователь получает билет и готов участвовать в событии
следующий шаг
Возвращается на сервис, участвует
в программе лояльности
Личный кабинет
Подход
OmEvent поддерживает повторное взаимодействие с платформой через retention-механики в личном кабинете : бонусы превращаются в подарки от партнёров, а реферальные начисления в рубли, которые можно потратить на мероприятия или вывести на карту. Поэтому в интерфейсе я разделила баллы и рубли, чтобы каждая механика имела понятную ценность и не смешивалась в одном балансе.
Подарки и рефералы - инструменты удержания и продвижения
Пользователю важно видеть, что его активность в сервисе имеет ценность: за задания он получает баллы, продвигается по уровням и открывает доступ к выгодной покупке призов.
А за рефералов пользователь получает получает рубли, которые можно использовать для оплаты билетов или вывести на карту.
Фокус
Я разделила баллы и рубли, чтобы каждая механика имела понятную ценность и не смешивалась в одном балансе.
Связала механику с конкретными действиями. В балльной программе пользователь видит задания и скидки, а в реферальной мероприятия, на которые можно пригласить друзей.
«Подарки» (Программа лояльности)
«Рефералы» (Реферальная программа)
Кабинет организатора
Подход
Дизайн кабинета организатора был направлен на упрощение регулярных рабочих процессов: создания мероприятий, контроля продаж, управления участниками, финансами и документами. Интерфейс был построен вокруг жизненного цикла мероприятия — от публикации события до продажи билетов, просмотра участников и вывода средств. Все данные были разнесены по тематическим вкладкам. Такой подход помог сохранить контроль над всеми процессами, не перегружая интерфейс деталями.
Главная страница — быстрый обзор состояния
Организатору важно быстро понимать, что происходит с его мероприятиями: сколько денег накопилось, сколько билетов продано и какие события сейчас актуальны.
Мероприятия — основной сценарий кабинета
Главная задача организатора — создавать и управлять мероприятиями. Ему нужно быстро видеть список событий, понимать их статус, контролировать продажи и при необходимости переходить к редактированию.
Фокус
Я разделила “Мероприятия” на два ключевых сценария:
1) создание нового; 2) управление созданными
Ввела формат таблиц для перечня мероприятий, потому что организатору важно быстро сканировать события и принимать решения без открытия каждой карточки.
контроль созданных мероприятий
создание нового мероприятия
Участники — контроль аудитории события
Раздел участников закрывает важный операционный сценарий после покупки билета. Это не просто список пользователей, а инструмент подготовки к мероприятию.
Дополнительные рабочие инструменты
Дополнительные разделы закрывают поддерживающие сценарии: обратную связь, юридические документы и управление командой.
Баланс
карточка юр лица
публичная карточка организации
управление командой
контроль актов
Кабинет администратора
Подход
Чтобы админ-панель оставалась понятной при большом количестве сущностей, я выстроила единую модель работы для всех разделов: поиск, фильтрация, таблица и смена статуса. Это помогает администраторам быстро находить данные, принимать решения и контролировать процессы без лишних переходов.
основные решения унификации
Табличная структура
В зависимости от раздела администратор видит только те данные, которые нужны для принятия решения
Система статусов
Я свела основные действия администратора к управлению статусами в таблицах каждого раздела
Поиск и фильрация
Во всех разделах для таблиц я добавила поиск, фильтры и сортировку для быстрого управления контентом
Логика всех разделов приведена к единой понятной модели управления
Логика всех разделов приведена к единой понятной модели управления
Лёгкое управление через статусы и фильтры
Визуальная система
Подход
Дизайн-система была заложена как основа для масштабирования платформы. Важно было сохранить единый визуальный язык, но при этом учесть разные типы интерфейсов. Компоненты проектировались модульно, чтобы использовать их в разных сценариях. Такой подход помог ускорить сборку интерфейсов, сохранить консистентность между разделами и упростить передачу макетов в разработку.
рефлексия/выводы
Больше пользователей доходят до покупки
Публичная часть выстроена так, чтобы человек быстро нашёл подходящее мероприятие, понял детали и перешёл к покупке.
Ожидаем: рост переходов из каталога в карточку мероприятия и рост конверсии в покупку билета.
большая неравнодушая команда делает проект неповоротливым , много переживаний и пересогласований
большая неравнодушая команда делает проект неповоротливым , много переживаний и пересогласований
неповоротливым , много переживаний и пересогласований
Конец
Made on
Tilda