Product / UX Designer
Дизайн системы & AI
СИЛЬНЫЕ СТОРОНЫ
Как я работаю
Собираю интерфейсы так, чтобы продукт был понятен пользователю, устойчив к сценариям и пригоден к разработке без лишних уточнений.
[01]
Сценарии
Проектирую пользовательские потоки, роли и edge cases, чтобы интерфейс не ломался на реальных действиях.
[02]
Системность
Собираю структуру и состояния так, чтобы продукт можно было развивать без хаотичных переделок.
[03]
Архитектура
Использую Figma и AI-инструменты, чтобы ускорять исследование, структуру, вайрфреймы и передачу в разработку без потери качества.
[04]
Продукт
Работаю с кабинетами, CRM, helpdesk, multi-role и mobile-сценариями, где важны не просто экраны, но и поведение системы.
ПОРТФОЛИО
Кейсы, в которых видно мышление
Здесь собраны проекты, где мне приходилось разбираться в логике продукта, выстраивать интерфейсы под реальные сценарии и работать с задачами, у которых не было готового ответа.
ФИЛОСОФИЯ
Дизайн через сценарий
Люблю разбирать продукт не как набор экранов, а как систему: понимать архитектуру, связи между сценариями, слабые места и точки, где пользователь теряется.
Мне важны задачи, в которых нужно не просто быстро собрать визуал, а сначала разобраться в логике, задать правильные вопросы, выстроить план и только потом собирать решение. В такой работе для меня ценны порядок, предсказуемый процесс и возможность делать интерфейс, который можно спокойно развивать дальше.
Сильнее всего я раскрываюсь в B2B и продуктовых интерфейсах, где от дизайна ждут не только аккуратный внешний вид, но и ясную логику, структурность и способность поддерживать продукт в развитии. Мне близки команды, где ценят спокойный диалог, системный подход и зрелое отношение к задаче: сначала понять, как всё устроено, потом сделать решение, которое можно развивать дальше без лишнего хаоса.
Тип проекта:
B2C/B2B платформа
Роль:
Product Designer
Платформа
Web Desktop/Mobile
Год
2026
Продукт:
Личный кабинет — платформа для участников и организаторов спортивных соревнований
Краткое описание
Платформа для организации и отслеживания спортивных соревнований: турнирные сетки, матчи, участники, фильтрация по дисциплинам. Основная аудитория — игроки и организаторы любительских и полупрофессиональных турниров.
Сложность состояла в том, что жизненный цикл заявки (подача → рассмотрение → платёж → участие) пересекается с жизненным циклом события (создание → публикация → управление участниками), и обе логики должны были сосуществовать в одном интерфейсе без перегрузки ни одного из сегментов.
Сложность состояла в том, что жизненный цикл заявки (подача → рассмотрение → платёж → участие) пересекается с жизненным циклом события (создание → публикация → управление участниками), и обе логики должны были сосуществовать в одном интерфейсе без перегрузки ни одного из сегментов.
Задачи → Решения
Задача: Один пользователь может выступать в двух ролях — участника и организатора — с принципиально разными задачами, данными и сценариями. Единый интерфейс рисковал либо перегрузить участника организаторскими инструментами, либо наоборот.
Решение: Главный экран разделён на два отдельных ролевых состояния («Функции участника» / «Функции организатора») с переключением контекста. Онбординг из двух шагов определяет первичную роль и формирует соответствующий профиль — либо анкету участника, либо анкету организатора.
Решение: Главный экран разделён на два отдельных ролевых состояния («Функции участника» / «Функции организатора») с переключением контекста. Онбординг из двух шагов определяет первичную роль и формирует соответствующий профиль — либо анкету участника, либо анкету организатора.
Задача: Организаторы управляют как организациями, так и командами, причём участники тоже имеют команды — это потенциально запутанная иерархия с риском когнитивного смешения ролей и сущностей.
Решение: Иерархия явно разведена в навигации: у участника — «Мои команды» / «Моя команда», у организатора — «Мои организации» / «Моя организация» / «Мои участники». Каждая сущность имеет собственную страницу с QR-кодом для офлайн-верификации членства, что закрывает сценарий физического присутствия на соревновании.
Решение: Иерархия явно разведена в навигации: у участника — «Мои команды» / «Моя команда», у организатора — «Мои организации» / «Моя организация» / «Мои участники». Каждая сущность имеет собственную страницу с QR-кодом для офлайн-верификации членства, что закрывает сценарий физического присутствия на соревновании.
Задача: Процесс подачи заявки на событие включает финансовые сценарии (платная / бесплатная заявка), возможность отзыва и несколько статусных состояний («На рассмотрении», «Предстоящие»). Ошибка в отображении статуса может привести к двойной оплате или потере места.
Решение: В разделе «Мои события» реализована явная статусная модель с отдельными экранами для каждого действия — отзыв бесплатной и платной заявки спроектированы как самостоятельные сценарии с разными подтверждениями. Это устраняет неоднозначность в критически важном пользовательском действии.
Решение: В разделе «Мои события» реализована явная статусная модель с отдельными экранами для каждого действия — отзыв бесплатной и платной заявки спроектированы как самостоятельные сценарии с разными подтверждениями. Это устраняет неоднозначность в критически важном пользовательском действии.
Задача: Оба типа пользователей обязаны загружать документы (медицинские справки, удостоверения) — операция с высоким риском ошибки, особенно на мобильном устройстве в условиях соревнований.
Решение: Разделы «Документы участника» и «Документы организатора» спроектированы симметрично, с отдельным экраном ошибки при добавлении документа. Пустые состояния и состояния ошибок охвачены на обеих платформах, что снижает брошенность формы в критический момент.
Решение: Разделы «Документы участника» и «Документы организатора» спроектированы симметрично, с отдельным экраном ошибки при добавлении документа. Пустые состояния и состояния ошибок охвачены на обеих платформах, что снижает брошенность формы в критический момент.
Описание процесса
Я начал с определения двух параллельных пользовательских траекторий — участника и организатора — и сразу понял, что попытка сделать из них одну унифицированную навигацию приведёт к компромиссам, невыгодным ни для кого. Вместо этого я выстроил архитектуру вокруг ролевого контекста: главный экран стал точкой переключения, а не общим дашбордом.
Информационная архитектура строилась от жизненного цикла объектов: событие → заявка → статус → действие для участника; событие → создание → управление участниками → документы для организатора. Это позволило сформировать навигационные разделы, которые отражают реальные задачи, а не произвольную классификацию функций.
Информационная архитектура строилась от жизненного цикла объектов: событие → заявка → статус → действие для участника; событие → создание → управление участниками → документы для организатора. Это позволило сформировать навигационные разделы, которые отражают реальные задачи, а не произвольную классификацию функций.
UI Kit для нейро-верстки
Работая над этим UI китом, я строил его с учётом единственного ограничения, которое задаёт всю архитектуру: компоненты должны читаться нейросетью для авто-верстки так же точно, как они читаются человеком-разработчиком. Это означало, что неоднозначность в наименовании, дублирование визуально похожих состояний или «умные» исключения из паттерна — недопустимы.
Я начал с атомарного слоя: кнопки, инпуты, иконки, чекбоксы, свитчи. Для каждого компонента я фиксировал полный граф состояний ещё до того, как переходил к молекулам. Иерархия именования строится по схеме [Тип] / [Вариант] / [Состояние] — например, Button Primary / CTA — lime / Loading. Это не просто соглашение по именованию, это протокол передачи: нейро-верстка парсит именно этот путь, чтобы определить, какой класс и какой стейт генерировать.
Я начал с атомарного слоя: кнопки, инпуты, иконки, чекбоксы, свитчи. Для каждого компонента я фиксировал полный граф состояний ещё до того, как переходил к молекулам. Иерархия именования строится по схеме [Тип] / [Вариант] / [Состояние] — например, Button Primary / CTA — lime / Loading. Это не просто соглашение по именованию, это протокол передачи: нейро-верстка парсит именно этот путь, чтобы определить, какой класс и какой стейт генерировать.
Результаты
- Объединены два продуктовых сценария (участник и организатор) в единую платформу без потери ролевой специфики — пользователь не чувствует себя «не на своём экране»
- Полностью охвачен жизненный цикл заявки: от подачи до отзыва с учётом платёжного статуса — 4 состояния с явными CTA, исключающими двусмысленность
- Спроектированы все критические edge case’ы: пустые состояния, ошибки загрузки документов, смена контактных данных — что снижает нагрузку на поддержку в самых частых точках отказа
Ожидания
- Введение уведомлений и статусных изменений в реальном времени (изменение статуса заявки, приближение события) — сейчас логика статусов есть, но push-механика не покрыта
- Разработка роли «капитана команды» как отдельного уровня прав внутри командного модуля — зачатки этой логики уже видны в экранах «Моя команда | Юзер не является капитаном»
Тип проекта:
B2C
Роль:
Product Designer
Платформа
iOS/Android
Год
2026
Продукт:
Сервис управления заказами
Краткое описание
Система сопровождения заказов на стороне покупателя и оператора: от момента готовности до выдачи.
Конечные пользователи получают push-уведомления и виджеты на главном экране телефона, отражающие актуальный статус заказа; сотрудники точки видят те же статусы в виде Kanban-доски.
Ключевой инсайт — покупатель не читает уведомления, он их сканирует: поэтому каждый статус должен быть различим без открытия приложения, а виджет — заменять необходимость вообще заходить внутрь.
Конечные пользователи получают push-уведомления и виджеты на главном экране телефона, отражающие актуальный статус заказа; сотрудники точки видят те же статусы в виде Kanban-доски.
Ключевой инсайт — покупатель не читает уведомления, он их сканирует: поэтому каждый статус должен быть различим без открытия приложения, а виджет — заменять необходимость вообще заходить внутрь.
Задачи → Решения
Задача: Push-уведомления на Android и iOS рендерятся по-разному — разный размер превью, различная обрезка текста, неодинаковое поведение action-кнопок.
Решение: Разработана единая контентная модель уведомления с вариативными шаблонами под обе платформы. Все четыре ключевых статуса («Готова», «Готов к получению», «Выдан», «Нет новостей») проработаны как отдельные визуальные состояния с уникальной иконографией и CTA — это видно на экране сравнительного разбора Android vs iOS.
Решение: Разработана единая контентная модель уведомления с вариативными шаблонами под обе платформы. Все четыре ключевых статуса («Готова», «Готов к получению», «Выдан», «Нет новостей») проработаны как отдельные визуальные состояния с уникальной иконографией и CTA — это видно на экране сравнительного разбора Android vs iOS.
Задача: iOS-виджет должен был передавать состояние заказа без открытия приложения, при этом масштабируясь под разные размеры виджетной сетки.
Решение: Спроектирована компонентная система виджетов с несколькими типоразмерами и набором состояний, покрывающих весь жизненный цикл заказа — от минимального до расширенного формата с адаптацией контента под каждый.
Решение: Спроектирована компонентная система виджетов с несколькими типоразмерами и набором состояний, покрывающих весь жизненный цикл заказа — от минимального до расширенного формата с адаптацией контента под каждый.
Описание процесса
Прежде чем открыть Figma, я провёл аудит того, что уже существует в продукте. У нас были push-уведомления и стандартные iOS-виджеты — они покрывали статус заказа, но только в момент, когда пользователь осознанно смотрит на телефон.
Dynamic Island закрывал другой сценарий: человек использует телефон для чего-то другого, и заказ должен «дотянуться» до него периферийно, не требуя переключения контекста.
Это изменило постановку задачи. Я переформулировал её так: не «как показать статус», а «как сообщить об изменении статуса за 0.3 секунды краем зрения».
Dynamic Island закрывал другой сценарий: человек использует телефон для чего-то другого, и заказ должен «дотянуться» до него периферийно, не требуя переключения контекста.
Это изменило постановку задачи. Я переформулировал её так: не «как показать статус», а «как сообщить об изменении статуса за 0.3 секунды краем зрения».
Исследование ограничений
Изучил документацию ActivityKit и собрал список ограничений:
Это сразу сформировало список дизайн-решений, которые не работают: бегущая строка, анимированный прогресс-бар обновляющийся каждые 10 секунд, текстовые метки в Minimal-состоянии.
- Три состояния с разными допустимыми размерами
- Lock Screen Activity как отдельный layout с другой геометрией
- Частота обновлений — не realtime, а по push или локальному триггеру
- Время жизни активности — максимум 8 часов, после чего система принудительно завершает
Это сразу сформировало список дизайн-решений, которые не работают: бегущая строка, анимированный прогресс-бар обновляющийся каждые 10 секунд, текстовые метки в Minimal-состоянии.
Геймификация
Задержка заказа — это момент наибольшего раздражения пользователя. Большинство продуктов реагируют на него извинением. Более сильное решение — переключить эмоциональный режим с потери на выигрыш: ты не ждёшь дольше, ты зарабатываешь.
Механика 1 — Компенсационные баллы при задержке
Логика начисления: Баллы начисляются не единовременно, а нарастающим итогом — это удерживает пользователя от отмены и создаёт эффект «уже столько накопил, жалко бросать».
Ключевое решение: показывать баллы как уже начисляемые, а не "начислим после". Глагол настоящего времени — «копятся», «зарабатываешь" — создаёт ощущение процесса, а не обещания.
Механика 2 — Поощрение за получение заказа
Логика: пользователь, который дошёл до кассы и забрал заказ — это конверсия. Её нужно поощрять и создавать к ней предвкушение заранее, а не после.
Этап 1 — Анонс (заказ готовится):
«Заберёшь заказ сам — получишь +80 баллов на следующий»
Это якорь. Пользователь уже знает про награду, ещё не получив заказ.
Этап 2 — Напоминание (заказ готов):
«Заказ ждёт тебя! Забери в течение 15 мин — и +80 баллов твои»
Лимит времени здесь не угроза, а усилитель ценности. FOMO работает в пользу продукта.
Этап 3 — Момент выдачи (финальный push):
«Получено! +80 баллов зачислены. Уже можно тратить»
Мгновенное подтверждение — закрывает петлю и формирует условный рефлекс: «забрал = получил».
Механика 1 — Компенсационные баллы при задержке
Логика начисления: Баллы начисляются не единовременно, а нарастающим итогом — это удерживает пользователя от отмены и создаёт эффект «уже столько накопил, жалко бросать».
Ключевое решение: показывать баллы как уже начисляемые, а не "начислим после". Глагол настоящего времени — «копятся», «зарабатываешь" — создаёт ощущение процесса, а не обещания.
Механика 2 — Поощрение за получение заказа
Логика: пользователь, который дошёл до кассы и забрал заказ — это конверсия. Её нужно поощрять и создавать к ней предвкушение заранее, а не после.
Этап 1 — Анонс (заказ готовится):
«Заберёшь заказ сам — получишь +80 баллов на следующий»
Это якорь. Пользователь уже знает про награду, ещё не получив заказ.
Этап 2 — Напоминание (заказ готов):
«Заказ ждёт тебя! Забери в течение 15 мин — и +80 баллов твои»
Лимит времени здесь не угроза, а усилитель ценности. FOMO работает в пользу продукта.
Этап 3 — Момент выдачи (финальный push):
«Получено! +80 баллов зачислены. Уже можно тратить»
Мгновенное подтверждение — закрывает петлю и формирует условный рефлекс: «забрал = получил».
Результаты
- Объединены три разрозненных канала (push Android, push iOS, виджет) в единую систему статусов с общей контентной моделью — разработчики получили сквозную спецификацию вместо трёх отдельных ТЗ
- Извинение закрывает инцидент. Баллы монетизируют лояльность — пользователь с негативным опытом уходит с большим балансом, чем пользователь с нейтральным.
- Push-уведомление «Нет новостей» переработано из информационного в проактивный триггер с конкретными CTA, что напрямую снижает нагрузку на поддержку по вопросам «где мой заказ»
Тип проекта:
B2B SaaS
Роль:
Product Designer
Платформа
Web
Год
2025
Продукт:
Система управления сервисными заявками (портал внутренних обращений)
Краткое описание
Веб-портал для управления сервисными заявками с двумя разграниченными ролями: Заявитель и Исполнитель.
Заявители подают обращения, отслеживают их статус и оценивают выполнение; Исполнители принимают заявки в работу и ведут коммуникацию внутри карточки.
Ключевая проблема, которую решает система — отсутствие единого прозрачного канала между инициатором запроса и ответственным лицом, что приводит к дублированию обращений и потере контекста по ходу решения.
Заявители подают обращения, отслеживают их статус и оценивают выполнение; Исполнители принимают заявки в работу и ведут коммуникацию внутри карточки.
Ключевая проблема, которую решает система — отсутствие единого прозрачного канала между инициатором запроса и ответственным лицом, что приводит к дублированию обращений и потере контекста по ходу решения.
Описание процесса
Продукт обслуживает два принципиально разных сценария использования — подача и отслеживание заявки (Заявитель) и приём и исполнение заявки (Исполнитель).
Это определило разделение навигационных моделей: у каждой роли своя точка входа, свой главный экран и своя логика работы с карточкой, хотя физически карточка заявки частично разделяется между ролями.
Это определило разделение навигационных моделей: у каждой роли своя точка входа, свой главный экран и своя логика работы с карточкой, хотя физически карточка заявки частично разделяется между ролями.
Описание процесса
Карточка заявки в обоих ролевых вариантах построена по принципу «детали + коммуникация» — верхняя часть содержит мета-данные и статус, нижняя — тред взаимодействия.
Такая структура отражает реальный рабочий процесс: сначала смотришь что это, потом работаешь с историей. Для Исполнителя добавлена возможность менять статус заявки прямо из карточки без переключения контекста.
Такая структура отражает реальный рабочий процесс: сначала смотришь что это, потом работаешь с историей. Для Исполнителя добавлена возможность менять статус заявки прямо из карточки без переключения контекста.
Результаты
- Весь жизненный цикл заявки — от подачи до закрытия и оценки — покрыт единым интерфейсом без выхода в сторонние каналы (почта, телефон)
- Два полностью разграниченных ролевых пространства реализованы на базе общей компонентной библиотеки, что сокращает стоимость поддержки и развития интерфейса
- Процесс создания заявки структурирован в пошаговый флоу, устраняющий неполные обращения и снижающий нагрузку на операторов за счёт обязательного заполнения ключевых полей
Что ожидается дальше:
- Введение расширенной фильтрации и сортировки в таблице Исполнителя (по типу, приоритету, дедлайну) для работы с возрастающим объёмом заявок
- Добавление дашборда аналитики для руководителей / администраторов — третья роль, логически следующая из архитектуры системы, с агрегированными метриками по срокам исполнения и загруженности команды
Тип проекта:
B2C
Роль:
Product Designer
Платформа
iOS/Android
Год
2025 - 2016
Продукт:
мобильное приложение для сети фитнес-студий, закрывающее полный цикл взаимодействия клиента
Краткое описание
Ядро продукта — интеграция цифрового и физического опыта: приложение буквально открывает двери студии.
От первого входа и выбора студии до покупки абонемента, бронирования тренировок и физического прохода в зал.
Пользователь фитнес-студии взаимодействует с сервисом не только внутри экрана — он сканирует QR, проходит по биометрии, оплачивает через несколько платёжных инструментов и ожидает, что все статусы его абонементов и посещений будут синхронизированы без задержек.
От первого входа и выбора студии до покупки абонемента, бронирования тренировок и физического прохода в зал.
Пользователь фитнес-студии взаимодействует с сервисом не только внутри экрана — он сканирует QR, проходит по биометрии, оплачивает через несколько платёжных инструментов и ожидает, что все статусы его абонементов и посещений будут синхронизированы без задержек.
График загруженности
Цель и бизнес-контекст: Задача формулировалась так: упростить пользователю выбор времени для посещения зала на основе визуальной информации о загруженности.
Для бизнеса это напрямую конвертируется в рост повторных визитов и снижение недовольства от переполненности — когда человек приходит и видит забитый зал, это негативный опыт, который влияет на продление абонемента.
Процесс:
Итерация 1 — «О студии».
Сначала секция жила в экране «О студии». Логика понятна: там же часы работы, характеристики зала. Но на практике пользователь, который хочет знать «а сейчас там много народу?», не пойдёт в «О студии» — он смотрит на главный экран. Информация была технически доступна, но фактически скрыта за лишним шагом навигации.
Итерация 2 — слайдер внутри блока «Время работы».
Следующая идея — объединить краткую загруженность сейчас и полный график в один блок с переключением через слайдер. Экономия места, логичная группировка. Но здесь возникло два принципиальных возражения, которые дизайнер зафиксировал текстом:
Финальное решение:
Отдельный именованный блок «График загруженности» прямо на главном экране, ниже блока студии и карточки абонемента.
Главный экран — это не компромисс, а единственное место, где график решает свою задачу. Он живёт ниже блока «Мои тренировки», то есть попадает в поле зрения именно тогда, когда пользователь уже думает о визите — видит расписание, прикидывает время, и тут же может проверить, будет ли зал свободен. Контекст правильный, момент правильный, действие очевидное.
Для бизнеса это напрямую конвертируется в рост повторных визитов и снижение недовольства от переполненности — когда человек приходит и видит забитый зал, это негативный опыт, который влияет на продление абонемента.
Процесс:
Итерация 1 — «О студии».
Сначала секция жила в экране «О студии». Логика понятна: там же часы работы, характеристики зала. Но на практике пользователь, который хочет знать «а сейчас там много народу?», не пойдёт в «О студии» — он смотрит на главный экран. Информация была технически доступна, но фактически скрыта за лишним шагом навигации.
Итерация 2 — слайдер внутри блока «Время работы».
Следующая идея — объединить краткую загруженность сейчас и полный график в один блок с переключением через слайдер. Экономия места, логичная группировка. Но здесь возникло два принципиальных возражения, которые дизайнер зафиксировал текстом:
Финальное решение:
Отдельный именованный блок «График загруженности» прямо на главном экране, ниже блока студии и карточки абонемента.
Главный экран — это не компромисс, а единственное место, где график решает свою задачу. Он живёт ниже блока «Мои тренировки», то есть попадает в поле зрения именно тогда, когда пользователь уже думает о визите — видит расписание, прикидывает время, и тут же может проверить, будет ли зал свободен. Контекст правильный, момент правильный, действие очевидное.
Чат с поддержкой / Ассистент
Ассистент живёт в иконке чата в правом углу шапки главного экрана. Это не пункт в навигации и не отдельная вкладка — он всегда в поле зрения, одно касание от любого состояния главного экрана. Сознательное решение о приоритете: ассистент — быстрый канал связи, а не раздел приложения.
Спроектировано 9 состояний: пустой чат, диалог, индикатор печати бота, не отправленное сообщение с recovery-паттерном (отправить снова / удалить), нет интернета, эскалация к менеджеру.
Фича ушла в разработку — в итоге в релиз попала упрощённая версия: без бота, только связь с менеджером. Все 9 состояний остались в дизайне как задел на следующую итерацию, когда AI-часть будет готова технически.
Спроектировано 9 состояний: пустой чат, диалог, индикатор печати бота, не отправленное сообщение с recovery-паттерном (отправить снова / удалить), нет интернета, эскалация к менеджеру.
Фича ушла в разработку — в итоге в релиз попала упрощённая версия: без бота, только связь с менеджером. Все 9 состояний остались в дизайне как задел на следующую итерацию, когда AI-часть будет готова технически.
Система промокодов
Одна из самых структурно сложных фич в проекте, потому что начиналась не с UI, а с вопроса: откуда пользователь вообще попадает в промокод?
Выделили три точки входа и спроектировали каждую отдельно:
Хороший пример того, как дизайн помогает расставить приоритеты: когда видишь все три точки входа рядом, сразу понятно, что релизить первым.
Выделили три точки входа и спроектировали каждую отдельно:
- Через магазин абонементов — поле ввода прямо в флоу покупки. Ушло в релиз.
- Через профиль — отдельный раздел «Промокоды» + баннер «Приведи друга». Беклог.
- Через сторис — история «Особая возможность!» с кнопкой «Скопировать промокод». Беклог.
Хороший пример того, как дизайн помогает расставить приоритеты: когда видишь все три точки входа рядом, сразу понятно, что релизить первым.
Результаты
- Спроектирован и задокументирован полный пользовательский путь от регистрации до ежедневного использования на двух платформах (iOS + Android), включая биометрический вход и QR-доступ в студию — интеграция, которая убирает очередь на стойке ресепшена.
- Система состояний абонементов (активный, истёкший, заморожен, без абонемента) объединена в единую дизайн-систему: четыре статуса покрыты без четырёх отдельных логик главного экрана.
- Фича промокодов — от пустого поля до шаринга через iOS Share Sheet — покрыта полным UserFlow с 13 состояниями экранов, что снизило риск edge cases при разработке.
Что ожидается дальше:
- Расширение функциональности ассистента: судя по текущим состояниям (сообщения, связь с менеджером, эскалация), следующий шаг — автоматизация типовых запросов и интеграция с CRM студии.
- Функция «Приведи друга» обозначена в беклоге — реферальная механика с промокодами уже заложена в дизайн-системе как основа; остаётся проработать мотивационные экраны и сценарий начисления.
Тип проекта:
B2C
Роль:
Product Designer
Платформа
iOS/Android
Год
2025 - 2016
Продукт:
мобильное приложение для сети фитнес-студий, закрывающее полный цикл взаимодействия клиента
Краткое описание
Ядро продукта — интеграция цифрового и физического опыта: приложение буквально открывает двери студии.
От первого входа и выбора студии до покупки абонемента, бронирования тренировок и физического прохода в зал.
Пользователь фитнес-студии взаимодействует с сервисом не только внутри экрана — он сканирует QR, проходит по биометрии, оплачивает через несколько платёжных инструментов и ожидает, что все статусы его абонементов и посещений будут синхронизированы без задержек.
От первого входа и выбора студии до покупки абонемента, бронирования тренировок и физического прохода в зал.
Пользователь фитнес-студии взаимодействует с сервисом не только внутри экрана — он сканирует QR, проходит по биометрии, оплачивает через несколько платёжных инструментов и ожидает, что все статусы его абонементов и посещений будут синхронизированы без задержек.
График загруженности
Цель и бизнес-контекст: Задача формулировалась так: упростить пользователю выбор времени для посещения зала на основе визуальной информации о загруженности.
Для бизнеса это напрямую конвертируется в рост повторных визитов и снижение недовольства от переполненности — когда человек приходит и видит забитый зал, это негативный опыт, который влияет на продление абонемента.
Процесс:
Итерация 1 — «О студии».
Сначала секция жила в экране «О студии». Логика понятна: там же часы работы, характеристики зала. Но на практике пользователь, который хочет знать «а сейчас там много народу?», не пойдёт в «О студии» — он смотрит на главный экран. Информация была технически доступна, но фактически скрыта за лишним шагом навигации.
Итерация 2 — слайдер внутри блока «Время работы».
Следующая идея — объединить краткую загруженность сейчас и полный график в один блок с переключением через слайдер. Экономия места, логичная группировка. Но здесь возникло два принципиальных возражения, которые дизайнер зафиксировал текстом:
Финальное решение:
Отдельный именованный блок «График загруженности» прямо на главном экране, ниже блока студии и карточки абонемента.
Главный экран — это не компромисс, а единственное место, где график решает свою задачу. Он живёт ниже блока «Мои тренировки», то есть попадает в поле зрения именно тогда, когда пользователь уже думает о визите — видит расписание, прикидывает время, и тут же может проверить, будет ли зал свободен. Контекст правильный, момент правильный, действие очевидное.
Для бизнеса это напрямую конвертируется в рост повторных визитов и снижение недовольства от переполненности — когда человек приходит и видит забитый зал, это негативный опыт, который влияет на продление абонемента.
Процесс:
Итерация 1 — «О студии».
Сначала секция жила в экране «О студии». Логика понятна: там же часы работы, характеристики зала. Но на практике пользователь, который хочет знать «а сейчас там много народу?», не пойдёт в «О студии» — он смотрит на главный экран. Информация была технически доступна, но фактически скрыта за лишним шагом навигации.
Итерация 2 — слайдер внутри блока «Время работы».
Следующая идея — объединить краткую загруженность сейчас и полный график в один блок с переключением через слайдер. Экономия места, логичная группировка. Но здесь возникло два принципиальных возражения, которые дизайнер зафиксировал текстом:
Финальное решение:
Отдельный именованный блок «График загруженности» прямо на главном экране, ниже блока студии и карточки абонемента.
Главный экран — это не компромисс, а единственное место, где график решает свою задачу. Он живёт ниже блока «Мои тренировки», то есть попадает в поле зрения именно тогда, когда пользователь уже думает о визите — видит расписание, прикидывает время, и тут же может проверить, будет ли зал свободен. Контекст правильный, момент правильный, действие очевидное.
Чат с поддержкой / Ассистент
Ассистент живёт в иконке чата в правом углу шапки главного экрана. Это не пункт в навигации и не отдельная вкладка — он всегда в поле зрения, одно касание от любого состояния главного экрана. Сознательное решение о приоритете: ассистент — быстрый канал связи, а не раздел приложения.
Спроектировано 9 состояний: пустой чат, диалог, индикатор печати бота, не отправленное сообщение с recovery-паттерном (отправить снова / удалить), нет интернета, эскалация к менеджеру.
Фича ушла в разработку — в итоге в релиз попала упрощённая версия: без бота, только связь с менеджером. Все 9 состояний остались в дизайне как задел на следующую итерацию, когда AI-часть будет готова технически.
Спроектировано 9 состояний: пустой чат, диалог, индикатор печати бота, не отправленное сообщение с recovery-паттерном (отправить снова / удалить), нет интернета, эскалация к менеджеру.
Фича ушла в разработку — в итоге в релиз попала упрощённая версия: без бота, только связь с менеджером. Все 9 состояний остались в дизайне как задел на следующую итерацию, когда AI-часть будет готова технически.
Система промокодов
Одна из самых структурно сложных фич в проекте, потому что начиналась не с UI, а с вопроса: откуда пользователь вообще попадает в промокод?
Выделили три точки входа и спроектировали каждую отдельно:
Хороший пример того, как дизайн помогает расставить приоритеты: когда видишь все три точки входа рядом, сразу понятно, что релизить первым.
Выделили три точки входа и спроектировали каждую отдельно:
- Через магазин абонементов — поле ввода прямо в флоу покупки. Ушло в релиз.
- Через профиль — отдельный раздел «Промокоды» + баннер «Приведи друга». Беклог.
- Через сторис — история «Особая возможность!» с кнопкой «Скопировать промокод». Беклог.
Хороший пример того, как дизайн помогает расставить приоритеты: когда видишь все три точки входа рядом, сразу понятно, что релизить первым.
Результаты
- Спроектирован и задокументирован полный пользовательский путь от регистрации до ежедневного использования на двух платформах (iOS + Android), включая биометрический вход и QR-доступ в студию — интеграция, которая убирает очередь на стойке ресепшена.
- Система состояний абонементов (активный, истёкший, заморожен, без абонемента) объединена в единую дизайн-систему: четыре статуса покрыты без четырёх отдельных логик главного экрана.
- Фича промокодов — от пустого поля до шаринга через iOS Share Sheet — покрыта полным UserFlow с 13 состояниями экранов, что снизило риск edge cases при разработке.
Что ожидается дальше:
- Расширение функциональности ассистента: судя по текущим состояниям (сообщения, связь с менеджером, эскалация), следующий шаг — автоматизация типовых запросов и интеграция с CRM студии.
- Функция «Приведи друга» обозначена в беклоге — реферальная механика с промокодами уже заложена в дизайн-системе как основа; остаётся проработать мотивационные экраны и сценарий начисления.