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

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

Роль: Senior Product Designer
Платформы: iOS / Android
Команда: PM, аналитик, UX researcher, iOS dev, Android dev, backend dev
Срок: 2 месяца
Контекст: B2B2C / Fitness Tech / Mobile / MVP

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

Проблема: Coach был скорее профилем тренера, чем его ежедневным рабочим инструментом. Расписание жило во внешних каналах, а сам продукт не видел реальную доступность и загрузку.

Что я сделал: помог собрать задачу в целостный продуктовый сценарий, участвовал в исследовании, синтезировал данные, сформулировал гипотезы, сравнил несколько подходов, спроектировал финальный UX-сценарий и довёл решение до handoff в разработку.

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

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

Статус: решение передано в разработку. Post-launch метрик на момент завершения моей части ещё не было, поэтому ниже я честно разделяю результат дизайн-этапа и ожидаемый продуктовый эффект после релиза.

DDX Coach — внутренний мобильный продукт для тренеров в экосистеме DDX Fitness. Он находится на стыке нескольких контуров сразу: операционной работы тренера, клиентской записи, внутренних заявок и будущих связок с CRM, уведомлениями и оплатой.

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

Из-за этого Coach оставался полезной точкой присутствия тренера в экосистеме, но ещё не становился полноценным рабочим инструментом.

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

• доступности тренера для записи;
• управления загрузкой;
• обработки заявок;
• будущих уведомлений;
• истории тренировок и архива;
• связки с CRM и дальнейших монетизационных сценариев.

Это сразу задавало правильную рамку: задача была не в том, чтобы «сделать календарик», а в том, чтобы собрать первую рабочую модель реального процесса.

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

На практике это выглядело так:

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

Ключевая проблема была в отсутствии единого источника правды по расписанию.

Это било сразу по трём сторонам.

Для тренера — лишняя ручная координация, зависимость от внешних инструментов и постоянное переключение между каналами.

Для клиента — непрозрачная запись и лишний шаг в виде переписки «когда вам удобно».

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

Важный момент: проблема была не в том, что тренеры не хотели вести график. Они уже это делали. Но делали вне продукта. Значит, задача была не в создании новой привычки, а в переносе существующего поведения внутрь Coach.

Без сценария расписания Coach оставался скорее маркетинговой витриной, чем рабочим инструментом тренера.

Это ограничивало продукт сразу в нескольких направлениях:

• не было прозрачной основы для цифровой записи;
• бизнес не видел нормальную воронку от интереса клиента до подтверждённой тренировки;
• нельзя было полноценно строить следующие слои: уведомления, архив, CRM-связку, оплату;
• продукт хуже удерживал тренера как ежедневный инструмент.

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

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

Цели первой итерации

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

Критерии успеха на этапе дизайна

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

Ограничения

• mobile-first;
• iOS и Android;
• жёсткий квартальный дедлайн;
• MVP-рамка по стоимости реализации;
• зависимость от будущей логики записей, ролей, статусов и правил редактирования.

Я вёл задачу от входа в проблему до handoff в разработку. Это была не роль «дизайнера на отрисовке», а полноценная работа на стыке исследования, продуктовой логики и проектирования сценария.

В моей зоне ответственности были:

• разбор постановки и user stories;
• декомпозиция сценария;
• конкурентный и смежный ресерч;
• синтез качественных и количественных сигналов;
• формулировка гипотез;
• сравнение концептов;
• проектирование UX-сценария;
• прототипирование;
• пользовательская проверка решений;
• финальная логика, UI и handoff.

Часть работы шла в тесной связке с командой:

• интервью проводили вместе с исследователем;
• аналитические сигналы обсуждали с аналитиком и PM;
• MVP-срез и технические ограничения согласовывали с разработкой.

Отдельно важен момент ownership: когда встал вопрос, как вести себя продукту при изменении графика, если на эти дни уже есть записи, я не согласился просто «срезать» проблему. Вместо этого предложил рабочее MVP-правило: новый график применяется только к дням без существующих записей, а уже согласованные тренировки сохраняются. Это позволило не сломать пользовательскую логику и при этом уложиться в рамку итерации.

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

На что я опирался

• постановка и user stories;
• обсуждение контекста с продуктовой командой;
• бенчмарк booking-сервисов, scheduling-паттернов и смежных решений;
• глубинные интервью с тренерами;
• количественный опрос;
• быстрые пользовательские проверки концептов.

Какие сегменты мы смотрели

• Новички — ещё не выстроили собственную операционную систему, им важнее понятный вход и guided flow;
• Тренеры со своей клиентской базой — уже привыкли к внешним инструментам и ожидают скорости и предсказуемости;
• Более загруженные и опытные тренеры — работают с плотным расписанием, где цена ошибки и сбоя в графике заметно выше.

Ключевые инсайты

1. Потребность в управлении графиком уже была сформирована
Тренеры и без продукта вели расписание. Значит, задача была не в создании новой привычки, а в переносе уже существующего поведения в более управляемый цифровой контур.
2. Для регулярной работы сильнее работает модель “правила графика”, а не ручной выбор отдельных дат
Для сценария тренера важна не единичная запись, а повторяемый рабочий ритм. Поэтому шаблонный подход лучше масштабировался на длительный период и лучше поддерживал дальнейшее редактирование.
3. Пользователю нужен не только ввод правил, но и визуальная валидация результата
Одной формы недостаточно. После настройки графика тренеру важно быстро проверить глазами, как результат выглядит в привычной календарной логике. Предпросмотр выступал не «украшением», а инструментом контроля.
4. Новички и опытные тренеры ждут разного уровня помощи
Новичкам полезнее guided flow, а опытным — скорость и предсказуемость. Слишком «учебный» сценарий проигрывает в регулярном использовании, а слишком «профессиональный» повышает порог входа.
5. Изменение графика при существующих записях — не edge case
Как только появляются реальные клиенты и реальные слоты, любое изменение графика становится конфликтной продуктовой задачей, а не просто редактированием пары полей.

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

Ключевые гипотезы

• если строить график как набор правил, а не как ручной выбор дат, сценарий будет лучше масштабироваться и проще поддерживаться;
• если после настройки показывать результат в календарной форме, пользователь будет увереннее сохранять график;
• если отделить базовую настройку от сложных конфликтных случаев, решение получится реалистичным для MVP;
• если не пытаться полностью автоматизировать conflict management в первой итерации, можно быстрее вывести в реализацию базовую рабочую модель.

Какие подходы сравнивали
У нас было два заметных полюса.

1. Календарный сценарий
Более привычный визуально и понятный на первом контакте, но хуже подходил под длительный период, повторяемые правила и регулярное редактирование.
2. Сценарий на основе правил / шаблона
Лучше поддерживал реальную рабочую логику тренера, был устойчивее на масштабе и лучше ложился на будущую модель записи. Но требовал аккуратной информационной архитектуры и более продуманного first-time experience.

Почему победил не «чистый» вариант
На пользовательской проверке стало видно, что одна только форма правил даёт хорошую операционную модель, но не до конца закрывает потребность быстро валидировать результат глазами.

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

Поэтому финальное решение стало гибридом:
сначала тренер задаёт правила графика, затем видит итог в календарном предпросмотре.

Именно эта сборка лучше всего балансировала:

• скорость настройки;
• понятность первого входа;
• предсказуемость результата;
• реалистичность для MVP.

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

Как он работал

1. Тренер задаёт период действия графика.
2. Настраивает рабочие часы.
3. При необходимости добавляет перерывы.
4. Выбирает шаг бронирования.
5. Определяет, какие дни рабочие, а какие — нет.
6. Перед сохранением получает календарный предпросмотр итогового графика.
7. Уже этот график становится основой для дальнейшей логики записи.

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

Шаблонная логика поддерживала реальный режим работы тренера
Тренеру нужен не набор случайных дат, а повторяемая схема доступности.

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

Сценарий оставался MVP-реалистичным
Мы не пытались решить всю систему записи сразу, а строили базовый устойчивый слой, на который можно было опереться в следующих итерациях.

На этапе handoff ключевой задачей было не «дополировать интерфейс», а сохранить пользовательскую логику внутри реальных ограничений разработки.

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

• собраны финальные макеты и состояния;
• зафиксированы переходы и правила поведения;
• проведён handoff;
• решение прошло инженерное обсуждение;
• часть сценариев была осознанно упрощена под MVP.

Главные компромиссы
1. Упростили отдельные механики выбора времени
Часть решений в ранних вариантах была дороже в реализации, чем позволяла рамка квартала. Вместе с командой мы выбрали более простой вариант, который сохранял базовую задачу пользователя, но снижал стоимость разработки.
2. Не стали полноценно решать conflict management в первой итерации
Самый сложный продуктовый момент возникал при изменении графика, если на эти дни уже были записи.

Полноценный сценарий с явным списком конфликтов, переносами, предупреждениями и дополнительной логикой уведомлений не помещался в MVP.

Поэтому мы зафиксировали рабочее правило первой версии:

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

На момент завершения моей части решение ещё не было в проде, поэтому я разделяю результат дизайн-этапа и ожидаемый продуктовый эффект после релиза.

Что реально было достигнуто

• разрозненная постановка была собрана в целостный MVP-сценарий;
• команда получила согласованную логику настройки графика;
• основные UX-риски были проверены до реализации;
• спор между competing approaches был снят через исследование и проверку;
• решение было доведено до handoff и согласовано с разработкой в рамках квартала;
• в рамках MVP была зафиксирована логика, которая защищает уже существующие записи при изменении графика.

Какой эффект ожидался после запуска

Для тренера

• меньше ручной координации;
• меньше зависимости от мессенджеров и внешних календарей;
• более понятное управление доступностью для записи.

Для клиента

• более прозрачный путь к записи;
• меньше лишней переписки;
• более предсказуемый сценарий выбора времени.

Для бизнеса

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

Что стоило бы мерить после релиза

• долю тренеров, которые настроили график;
• количество доступных слотов;
• долю записей, дошедших до подтверждения внутри цифрового контура;
• время от интереса клиента до подтверждённой записи;
• количество конфликтов и ручных переносов при изменении графика.

1. Расписание — это не экран, а операционная модель продукта
Если смотреть на него только как на UI-сущность, легко упустить половину реальной проблемы.

2. Хорошее решение не всегда лежит в одном концепте
Здесь сработал не «чистый» календарь и не «чистая» форма, а гибрид, который точнее закрывал реальные ожидания пользователя.

3. Зрелый дизайн — это не только про usability, но и про delivery reality
Часть силы решения была не в сложности сценария, а в том, что он помещался в квартал и не ломался на реализации.

4. Компромисс — часть product thinking
Важно не прятать ограничения, а собирать решение, которое остаётся логичным даже после MVP-среза.

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