Product / UX Designer

Краткое описание

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

Сложность состояла в том, что жизненный цикл заявки (подача → рассмотрение → платёж → участие) пересекается с жизненным циклом события (создание → публикация → управление участниками), и обе логики должны были сосуществовать в одном интерфейсе без перегрузки ни одного из сегментов.

Задачи → Решения

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

Решение: Главный экран разделён на два отдельных ролевых состояния («Функции участника» / «Функции организатора») с переключением контекста. Онбординг из двух шагов определяет первичную роль и формирует соответствующий профиль — либо анкету участника, либо анкету организатора.

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

Решение: Иерархия явно разведена в навигации: у участника — «Мои команды» / «Моя команда», у организатора — «Мои организации» / «Моя организация» / «Мои участники». Каждая сущность имеет собственную страницу с QR-кодом для офлайн-верификации членства, что закрывает сценарий физического присутствия на соревновании.

Задача: Процесс подачи заявки на событие включает финансовые сценарии (платная / бесплатная заявка), возможность отзыва и несколько статусных состояний («На рассмотрении», «Предстоящие»). Ошибка в отображении статуса может привести к двойной оплате или потере места.

Решение: В разделе «Мои события» реализована явная статусная модель с отдельными экранами для каждого действия — отзыв бесплатной и платной заявки спроектированы как самостоятельные сценарии с разными подтверждениями. Это устраняет неоднозначность в критически важном пользовательском действии.

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

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

Описание процесса

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

Информационная архитектура строилась от жизненного цикла объектов: событие → заявка → статус → действие для участника; событие → создание → управление участниками → документы для организатора. Это позволило сформировать навигационные разделы, которые отражают реальные задачи, а не произвольную классификацию функций.

UI Kit для нейро-верстки

Работая над этим UI китом, я строил его с учётом единственного ограничения, которое задаёт всю архитектуру: компоненты должны читаться нейросетью для авто-верстки так же точно, как они читаются человеком-разработчиком. Это означало, что неоднозначность в наименовании, дублирование визуально похожих состояний или «умные» исключения из паттерна — недопустимы.

Я начал с атомарного слоя: кнопки, инпуты, иконки, чекбоксы, свитчи. Для каждого компонента я фиксировал полный граф состояний ещё до того, как переходил к молекулам. Иерархия именования строится по схеме [Тип] / [Вариант] / [Состояние] — например, Button Primary / CTA — lime / Loading. Это не просто соглашение по именованию, это протокол передачи: нейро-верстка парсит именно этот путь, чтобы определить, какой класс и какой стейт генерировать.

Краткое описание

Система сопровождения заказов на стороне покупателя и оператора: от момента готовности до выдачи.

Конечные пользователи получают push-уведомления и виджеты на главном экране телефона, отражающие актуальный статус заказа; сотрудники точки видят те же статусы в виде Kanban-доски.

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

Задачи → Решения

Задача: Push-уведомления на Android и iOS рендерятся по-разному — разный размер превью, различная обрезка текста, неодинаковое поведение action-кнопок.

Решение: Разработана единая контентная модель уведомления с вариативными шаблонами под обе платформы. Все четыре ключевых статуса («Готова», «Готов к получению», «Выдан», «Нет новостей») проработаны как отдельные визуальные состояния с уникальной иконографией и CTA — это видно на экране сравнительного разбора Android vs iOS.

Задача: iOS-виджет должен был передавать состояние заказа без открытия приложения, при этом масштабируясь под разные размеры виджетной сетки. 

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

Описание процесса

Прежде чем открыть Figma, я провёл аудит того, что уже существует в продукте. У нас были push-уведомления и стандартные iOS-виджеты — они покрывали статус заказа, но только в момент, когда пользователь осознанно смотрит на телефон.

Dynamic Island закрывал другой сценарий: человек использует телефон для чего-то другого, и заказ должен «дотянуться» до него периферийно, не требуя переключения контекста.

Это изменило постановку задачи. Я переформулировал её так: не «как показать статус», а «как сообщить об изменении статуса за 0.3 секунды краем зрения».

Исследование ограничений

Изучил документацию ActivityKit и собрал список ограничений:

• Три состояния с разными допустимыми размерами
• Lock Screen Activity как отдельный layout с другой геометрией
• Частота обновлений — не realtime, а по push или локальному триггеру
• Время жизни активности — максимум 8 часов, после чего система принудительно завершает

Это сразу сформировало список дизайн-решений, которые не работают: бегущая строка, анимированный прогресс-бар обновляющийся каждые 10 секунд, текстовые метки в Minimal-состоянии.

Геймификация

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

Механика 1 — Компенсационные баллы при задержке

Логика начисления: Баллы начисляются не единовременно, а нарастающим итогом — это удерживает пользователя от отмены и создаёт эффект «уже столько накопил, жалко бросать».

Ключевое решение: показывать баллы как уже начисляемые, а не "начислим после". Глагол настоящего времени — «копятся», «зарабатываешь" — создаёт ощущение процесса, а не обещания.

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

Этап 1 — Анонс (заказ готовится):
«Заберёшь заказ сам — получишь +80 баллов на следующий»
Это якорь. Пользователь уже знает про награду, ещё не получив заказ.

Этап 2 — Напоминание (заказ готов):
«Заказ ждёт тебя! Забери в течение 15 мин — и +80 баллов твои»
Лимит времени здесь не угроза, а усилитель ценности. FOMO работает в пользу продукта.

Этап 3 — Момент выдачи (финальный push):
«Получено! +80 баллов зачислены. Уже можно тратить»
Мгновенное подтверждение — закрывает петлю и формирует условный рефлекс: «забрал = получил».

Краткое описание

Веб-портал для управления сервисными заявками с двумя разграниченными ролями: Заявитель и Исполнитель.

Заявители подают обращения, отслеживают их статус и оценивают выполнение; Исполнители принимают заявки в работу и ведут коммуникацию внутри карточки.

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

Описание процесса

Продукт обслуживает два принципиально разных сценария использования — подача и отслеживание заявки (Заявитель) и приём и исполнение заявки (Исполнитель).

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

Описание процесса

Карточка заявки в обоих ролевых вариантах построена по принципу «детали + коммуникация» — верхняя часть содержит мета-данные и статус, нижняя — тред взаимодействия.

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

Краткое описание

Ядро продукта — интеграция цифрового и физического опыта: приложение буквально открывает двери студии.

От первого входа и выбора студии до покупки абонемента, бронирования тренировок и физического прохода в зал.

Пользователь фитнес-студии взаимодействует с сервисом не только внутри экрана — он сканирует QR, проходит по биометрии, оплачивает через несколько платёжных инструментов и ожидает, что все статусы его абонементов и посещений будут синхронизированы без задержек.

График загруженности

Цель и бизнес-контекст: Задача формулировалась так: упростить пользователю выбор времени для посещения зала на основе визуальной информации о загруженности.

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

Процесс: 

Итерация 1 — «О студии».
Сначала секция жила в экране «О студии». Логика понятна: там же часы работы, характеристики зала. Но на практике пользователь, который хочет знать «а сейчас там много народу?», не пойдёт в «О студии» — он смотрит на главный экран. Информация была технически доступна, но фактически скрыта за лишним шагом навигации.

Итерация 2 — слайдер внутри блока «Время работы».
Следующая идея — объединить краткую загруженность сейчас и полный график в один блок с переключением через слайдер. Экономия места, логичная группировка. Но здесь возникло два принципиальных возражения, которые дизайнер зафиксировал текстом:

Финальное решение:

Отдельный именованный блок «График загруженности» прямо на главном экране, ниже блока студии и карточки абонемента.

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

Чат с поддержкой / Ассистент

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

Спроектировано 9 состояний: пустой чат, диалог, индикатор печати бота, не отправленное сообщение с recovery-паттерном (отправить снова / удалить), нет интернета, эскалация к менеджеру.

Фича ушла в разработку — в итоге в релиз попала упрощённая версия: без бота, только связь с менеджером. Все 9 состояний остались в дизайне как задел на следующую итерацию, когда AI-часть будет готова технически.

Система промокодов

Одна из самых структурно сложных фич в проекте, потому что начиналась не с UI, а с вопроса: откуда пользователь вообще попадает в промокод?

Выделили три точки входа и спроектировали каждую отдельно:

• Через магазин абонементов — поле ввода прямо в флоу покупки. Ушло в релиз.
• Через профиль — отдельный раздел «Промокоды» + баннер «Приведи друга». Беклог.
• Через сторис — история «Особая возможность!» с кнопкой «Скопировать промокод». Беклог.

Хороший пример того, как дизайн помогает расставить приоритеты: когда видишь все три точки входа рядом, сразу понятно, что релизить первым.

Краткое описание

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

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

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

Процесс

Проектирование личного кабинета я начал с картирования всех пользовательских сценариев через flow-диаграмму (секция «Переходы между экранами ЛК и функционал»).

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

Системное решение

Намеренно не создавал отдельный «B2B-кабинет»: это привело бы к дублированию разработки и разрыву пользовательского опыта.

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

Задача → Решение

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

Решение: В разделе «Заказы» реализованы фильтрация и сортировка с явными состояниями на Desktop и Mobile (отдельные экраны «Фильтры» и «Сортировка» на мобайле). Карточка заказа содержит статус, номер, дату, сумму и превью товаров. Страница заказа раскрывает полный состав с фотографиями позиций, итоговым расчётом и таймлайном статусов.