Test assignment · Product · Mobile · 2026
СОвместные поездки в т-путешествиях
Product designer
UX/UI
Product management
Frontend
Marketing
Product management
Frontend
Marketing
Figma
overview
Задача: спроектировать функционал внутри приложения Т-Банка, который поможет пользователю организовать совместную поездку с другими людьми и оптимизировать фиксацию трат и сбор денег до, во время и после поездки. Все вводные тут
Роль: Product Designer (исследование, UX, UI, прототипирование и тестирование). Работа выполнена в качестве тестового задания за 6 дней
разбор проблемы
Разрозненность процесса: информация, переводы и расчеты находятся в разных местах
Сбор денег до поездки: 37% сталкивались со сложностями при сборе денег на общие траты, нужно договариваться, скидываться и отслеживать переводы вручную
Непрозрачность оплат: 33% хотя бы раз не понимали, кто уже оплатил свою часть
Учет расходов в поездке: траты происходят в разных форматах (карта/наличные), фиксируются вручную, теряются в чатах
Результаты
Подтвердилось
·
Люди, которые ведут финансы поездки, часто собирают информацию и считают все вручную / составляют формулы, из-за чего теряют много времени и сил
·
Не все участники хотят участвовать в организации и расчетах, вовлеченность неравномерная. Некоторые хотят просто быстро посмотреть, должны ли они кому-то
и какая это сумма
и какая это сумма
·
Когда в поездке появляются траты «в моменте», их сложно быстро зафиксировать
и потом корректно разделить. Иногда участники объединяют несколько трат
и рассчитываются за них позже
и потом корректно разделить. Иногда участники объединяют несколько трат
и рассчитываются за них позже
·
В поездках одновременно сосуществуют разные модели: где-то траты делят поровну,
где-то по факту, где-то не считают вовсе
где-то по факту, где-то не считают вовсе
·
До поездки участники часто заранее обсуждают общий бюджет и лимит, а потом ориентируются на него при выборе билетов и жилья
·
Информация о расходах и оплатах часто разрознена. Пользователи изначально полагаются на доверие и не хотят тратить время на контроль расчетов, но при сомнениях им приходится вручную проверять суммы.
Не подтвердилось
·
Гипотеза о необходимости напоминаний о долгах не подтвердилась, проблема скорее
в фиксации трат, расчетах и статусах оплаты
в фиксации трат, расчетах и статусах оплаты
Исследование
Целевые пользователи, респонденты, инсайты, выводы и идеи для решений в Figma.
Также был проведен конкурентный анализ паттернов и механик и тестирование прототипа
Также был проведен конкурентный анализ паттернов и механик и тестирование прототипа
Проведено 9 интервью, количественный опрос не делала, поскольку количественные данные, подтверждающие боль и актуальность, были даны. В поездке есть 2 роли — основные организаторы, берущие на себя большую ответственность, а есть «пассивные» участники поездки
Участник
· Оплачивает свою часть
· Хочет быстро понимать, кто сколько должен
· Смотрит общую картину, чтобы быть в курсе
· Хочет быстро понимать, кто сколько должен
· Смотрит общую картину, чтобы быть в курсе
«Организатор»
· Собирает деньги
· Оплачивает жилье и билеты
· Отслеживает переводы
· Фиксирует общие расходы
· Оплачивает жилье и билеты
· Отслеживает переводы
· Фиксирует общие расходы
контекст
Совместная поездка распадается на множество отдельных задач: нужно договориться
о билетах и жилье, оплатить, собрать деньги, отслеживать, кто уже оплатил свою часть,
а кто — нет, возникают совместные траты наличными и картой, которые тоже нужно учитывать и делить.
Сейчас пользователи часто координируются вне одного продукта: мессенджеры, ссылки, переводы друг другу, вручную ведут заметки по расходам и договоренностям
о билетах и жилье, оплатить, собрать деньги, отслеживать, кто уже оплатил свою часть,
а кто — нет, возникают совместные траты наличными и картой, которые тоже нужно учитывать и делить.
Сейчас пользователи часто координируются вне одного продукта: мессенджеры, ссылки, переводы друг другу, вручную ведут заметки по расходам и договоренностям
user flow
Сначала собрала развернутый user flow, где учла все эти сценарии, чтобы понять механику. Выделила основной сценарий — фиксация траты и возврат долга.
Также учтены corner cases для ключевых сценариев
· До поездки — сбор денег
· Во время — фиксация трат
· После — погашение долгов
· Во время — фиксация трат
· После — погашение долгов
На основе джобов я выделила ключевые сценарии, покрывающие все этапы поездки:
JTBD: когда я еду в поездку с другими людьми, я хочу понимать все траты и кто кому должен, чтобы не тратить время на расчеты и поиск информации и не путаться в деньгах
Основные job stories
·
Когда во время совместной поездки другие участники оплачивают за меня расходы,
я хочу выяснить, за что и сколько должен, чтобы вернуть свою часть денег
и не разбираться в чужих расчетах
я хочу выяснить, за что и сколько должен, чтобы вернуть свою часть денег
и не разбираться в чужих расчетах
·
Когда я заплатил за другого участника, я хочу понимать погашен ли долг, чтобы
не требовать повторно уже возвращенные деньги и избежать неловкого разговора
не требовать повторно уже возвращенные деньги и избежать неловкого разговора
·
Когда я узнаю, сколько должен другому участнику за расходы в поездке, я хочу вернуть ему свою часть денег, чтобы быстрее завершить расчеты и не оставлять за собой долгов
·
Когда во время поездки я оплатил общий расход и нужно разделить его поровну,
я хочу рассчитать равную долю каждого участника, чтобы не пришлось считать ее вручную и все внесли согласованную сумму
я хочу рассчитать равную долю каждого участника, чтобы не пришлось считать ее вручную и все внесли согласованную сумму
·
Когда во время поездки мы оплачиваем общий чек и на каждого приходится разная сумма расходов, я хочу разделить трату на разные суммы для каждого участника, чтобы никто
не платил за чужие покупки и расчеты были справедливыми
не платил за чужие покупки и расчеты были справедливыми
·
Когда во время поездки я только что оплатил общий расход за других участников
и еще помню, кто в нем участвовал, я хочу зафиксировать сумму и долю каждого, чтобы позже не восстанавливать детали по чекам, перепискам и памяти
и еще помню, кто в нем участвовал, я хочу зафиксировать сумму и долю каждого, чтобы позже не восстанавливать детали по чекам, перепискам и памяти
Job stories
Приоритизация
· Оплата долгов
· Бюджет
· Заказы через Т-Путешествия
· От кого и какую сумму ждем
· Сборы
· История
· Дополнительные сервисы
· Бюджет
· Заказы через Т-Путешествия
· От кого и какую сумму ждем
· Сборы
· История
· Дополнительные сервисы
«К оплате» самый первый как основное действие. Блок «Заказы» использую как смысловой
и визуальный разделитель, чтобы не перегружать экран однотипными финансовыми
блоками. «Ждете оплату» оставила рядом с финансовым контекстом, но ниже, так как
это менее срочное действие.
и визуальный разделитель, чтобы не перегружать экран однотипными финансовыми
блоками. «Ждете оплату» оставила рядом с финансовым контекстом, но ниже, так как
это менее срочное действие.
решения
Точки входа
·
«Путешествия» > «Поездки» > конкретная поездка
·
«Путешествия» > «Совместная поездка» > конкретная поездка
·
«Все операции» > конкретная операция > «Добавить в поездку»
·
Экран успеха после операции > «Добавить в поездку»
Не подтвердилось
·
Гипотеза о необходимости напоминаний о долгах не подтвердилась, проблема скорее
в фиксации трат, расчетах и статусах оплаты
в фиксации трат, расчетах и статусах оплаты
Собрала основную информацию о поездке на главном экране: сколько пользователь должен сам, сколько должны ему, общий бюджет, заказы в Т-Путешествиях, сборы и историю трат внутри поездки. «К оплате» поставила первым как основное действие
Пользователь может добавить новую трату внутри поездки или привязать уже совершенную операцию. Дальше указывает, кто оплатил, выбирает участников и способ разделения суммы. После этого долг автоматически распределяется между участниками. Оставила несколько способов деления, потому что в поездках расходы
не всегда делят поровну, но этот вариант по умолчанию
не всегда делят поровну, но этот вариант по умолчанию
Погашение долга: пользователь может перевести деньги прямо из сценария поездки или отметить уже совершенную оплату (наличными или через другой банк). Во втором случае платеж отправляется получателю
на подтверждение, статус долга обновляется для обоих участников
на подтверждение, статус долга обновляется для обоих участников
Подтверждение получения: после того как «должник» отмечает, что долг оплачен наличными или через другой банк, пользователь получает запрос на подтверждение. Он проверяет сумму и подтверждает, что деньги пришли, после этого статус долга обновляется у обоих участников
Тестирование
Протестировала основной сценарий на 3 пользователях, после чего внесла правки
Во время тестирования заметила, что зафиксированный банк не всегда считывается как очевидный
и достаточный выбор. У одного пользователя возник прямой вопрос, почему нельзя выбрать другой банк
и появлялось сомнение, все ли так
Решение: вернула привычный паттерн выбора банка, а приоритетным остается банк, который получатель выбрал в Т-Банке самостоятельно
и достаточный выбор. У одного пользователя возник прямой вопрос, почему нельзя выбрать другой банк
и появлялось сомнение, все ли так
Решение: вернула привычный паттерн выбора банка, а приоритетным остается банк, который получатель выбрал в Т-Банке самостоятельно
Во время тестирования 2 пользователя замешкались на втором шаге. Одному мешал визуальный шум данных
на фоне, второго смутило одинаковое расположения кнопок на двух экранах. Оба пользователя предпочли
второй вариант
Решение: вынесла выбор способа оплаты на отдельный экран и убрала лишний контекст
на фоне, второго смутило одинаковое расположения кнопок на двух экранах. Оба пользователя предпочли
второй вариант
Решение: вынесла выбор способа оплаты на отдельный экран и убрала лишний контекст
ограничения
Это тестовое задание, поэтому у меня не было доступа к реальным продуктовым данным продукта, техническим ограничениям и бизнес-приоритетам команды.
Исследование и тестирование проводились на небольшой выборке, поэтому результаты помогают проверить основные сценарии, но не подтверждают решение на масштабе аудитории
Исследование и тестирование проводились на небольшой выборке, поэтому результаты помогают проверить основные сценарии, но не подтверждают решение на масштабе аудитории
