Т-Банк — совместные поездки
- b2c
- fintech
- jtbd
- сценарии
- исследования
- дизайн-система
Контекст
Компания друзей едет вместе — и почти сразу начинается: кто бронирует жильё, кто скидывается на еду, кто кому вернёт потом. Обычно это живёт в переписке, заметках и переводах «по памяти». Я встроил этот сценарий прямо в Т-Банк — чтобы группа вела планы, общие траты и расчёты в одном месте: до, во время и после поездки.
Проблема
Дело было не в том, чтобы «поделить счёт». В групповой поездке сложность глубже: важно не только посчитать, кто кому должен, но и не скатиться в неловкость, недоверие и постоянные напоминания. Поэтому я решал две задачи сразу — сделать расчёты прозрачными и снизить напряжение внутри группы, не перегружая основной банковский флоу.
Роль
Вёл кейс целиком: от исследования до макетов. Собрал JTBD и карту флоу, спроектировал ключевые экраны — создание поездки, участников, планы и траты — и проработал состояния под передачу в разработку.
Цели
Чтобы вокруг поездки люди чаще возвращались в Т-Банк: планировать, скидываться, оплачивать и закрывать расчёты внутри приложения, а не в чатах и заметках.
Дать группе одно общее прозрачное пространство: всем видно, кто участвует, что запланировано, какие траты появились и что осталось закрыть.
Для меня главный признак успеха — не «создали поездку», а «дошли до финальных расчётов». Значит, продукт довёл группу до состояния «все рассчитались», а не завёл ещё один список трат.
Исследование
Начал с брифа, конкурентов и JTBD — хотел понять, почему обычный «сплиттер расходов» не закрывает групповую поездку. Сравнил travel-first и money-first продукты, разложил путь на «до / во время / после» и собрал JTBD.
Главный вывод оказался не про деньги: проблема не в дележе счёта, а в потере общего контекста. Договорённости, участники, сборы и траты разбросаны по чатам и заметкам — никто не видит картину целиком. Значит, продукт должен не столько считать, сколько удерживать общий контекст и снижать напряжение в группе.
JTBD
Что нужно пользователю
- Когда мы только начинаем планировать поездку, я хочу быстро зафиксировать состав группы и базовые договорённости, чтобы понять, кто реально участвует и что планирует.
- Когда до поездки появляются общие траты и авансы, я хочу видеть, какие обязательства уже взяты и кто сколько должен внести.
- Когда в поездке возникают совместные расходы, я хочу сразу понимать, кто оплатил и кого касается трата, чтобы не пересчитывать всё вручную.
- Когда поездка заканчивается, я хочу быстро закрыть хвосты и увидеть финальные расчёты между участниками, чтобы завершить поездку без споров.
- Когда мы тратим общие деньги с друзьями, я хочу, чтобы правила и статусы были прозрачны для всех — чтобы не возникало неловкости и недоверия.
- Когда поездка организуется группой без явного лидера, я хочу, чтобы ответственность была распределена и видима, чтобы всё не держалось на одном человеке.
Гипотезы
- 01
Если сделать главным объектом не расход, а поездку, пользователю будет проще видеть общий контекст: участников, план, сборы, расходы и расчёты.
- 02
Если добавить слой «План», пользователи смогут фиксировать договорённости до появления расходов: жильё, билеты, общий бюджет, ответственных и сборы.
- 03
Если сбор денег привязать к конкретному пункту поездки — жильё или экскурсия — пользователям будет понятнее, за что они переводят деньги.
- 04
Если после поездки выделить отдельный этап расчётов, пользователям будет проще закрыть долги и не потерять забытые расходы.
Решение
Раз проблема в потере контекста, а не в дележе счёта, я сфокусировал MVP на одном: связать поездку в единый понятный сценарий внутри Т-Банка. Сознательно оставил за скобками то, что усложняло бы MVP без пользы для сути — например, скан QR-чеков. Вот что вошло — и почему именно это.
Приглашение участников
Поездка начинается с создания: пользователь выбирает друзей из контактов и получает ссылку-приглашение — её можно отправить в любой чат, а друзья подтверждают участие по ней.
Создание планов
До поездки группа фиксирует договорённости: что оплатить, кого это касается и сколько вносит каждый. У каждого пункта есть ответственный — он меняет сумму, участников или описание, если условия поменялись. Так план остаётся живым и не тонет в переписке.
Планы участников
Когда участник создаёт план с суммой, остальные видят его во вкладке «Запросы от друзей» и сразу переводят свою часть внутри Т-Банка. Договорённость превращается в понятный платёж, а после оплаты перевод виден всем во вкладке «Совместные траты» — для прозрачности.
Траты во время поездки
Не всё планируется заранее — экскурсия, такси, продукты. Такую трату участник добавляет как совместную, выбирает, между кем делить, и делится ссылкой или QR для оплаты. А если кто-то вернул наличными, организатор траты отмечает поступление вручную.
Запрос к переводу
Когда появляется совместная трата, у остальных она всплывает в «Запросах от друзей» — с уже посчитанной суммой. Не нужно считать вручную или искать реквизиты: открыл, увидел свою часть, перевёл внутри Т-Банка. Статус виден всем — кто уже перевёл, а кто нет.
Финальные расчёты
После поездки у каждого видно, что осталось закрыть: кто должен ему и кому должен он. По каждому расчёту — детали, напоминание о переводе или отметка о наличном возврате.
Итоги
Собрал разрозненный сценарий — планы, траты, расчёты — в одно пространство поездки внутри Т-Банка. Без отдельного приложения и без «ещё одного списка расходов»
Дальше я бы проверил прототип на большем числе людей и докрутил точные сценарии: наличные возвраты, частичное закрытие долгов, скан QR-чеков, автоматическое распределение. Отдельно — умное определение трат: приложение замечает операции во время поездки и само предлагает добавить их, без ручного ввода.