Кейс: TripBuddie

TripBuddie — мобильное приложение для групповых поездок

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

Инструменты

Figma

•

Claude Code

•

Codex

•

Flutter

•

md-спецификации

Статус

В процессе проектирования

Контекст и проблема

Четверо друзей решили поехать вместе, и планирование уезжает в общий чат. Через неделю там триста сообщений. Кто‑то предложил хороший ужин, но через сорок сообщений никто не помнит, о чём шла речь. Жильё выбирает организатор, потому что иначе его не выберут никогда. После поездки один человек сидит в заметках, считает, кто кому должен, и пишет: «Напоминаю про 24 евро». Чувствует он себя при этом коллектором.

Я выписал такие ситуации и увидел четыре повторяющиеся боли:

01

Идеи теряются: предложения тонут в переписке.

02

Решает громкий: организатор или самый настойчивый участник выбирает за всех.

03

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

04

Про деньги неловко напоминать: просить вернуть долг тяжело.

Главный инсайт

У всех четырёх болей общая природа. Информации хватает: ссылки, даты и суммы у группы есть. Мешает социальное трение.

Неловко:

отказаться от дорогого ужина
проголосовать против друга
напомнить о долге
быть тем, кто решает за всех

Гипотеза, которую следует проверить

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

Методология разработки

Работу над продуктом я разделил на несколько этапов:

01

Исследование пользовательского опыта

02

Формулирование гипотез

03

Проектирование продуктовой логики

04

Проработка пользовательских сценариев

Каждый уровень я фиксирую в Markdown‑документах в репозитории: продукт, доменная модель, сценарии, решения. Отдельный файл содержит правила для ИИ‑ассистента (Codex + Claude Code (в зависимости от задач)), которые потом пишут код.

Структура репозитория:

AGENTS.md

docs/product

docs/domain

docs/flows

docs/design

lib/

test/

Figma остаётся источником истины для внешнего вида, а документация отвечает на вопросы «как это устроено» и «почему».
Документы веду в диалоге с ML (Claude) он помогает с формулировками, структурой таблиц и поиском противоречий. Продуктовые решения принимаю я, и они зафиксированы в отдельном документе.

Упрощенная цепочка работы

Job to be done → Гипотезы → Сущности и связи → Состояния → Сценарии → Экраны в Figma → Код на Flutter

Исследование

Участники

7 человек

Поездка в Турцию

Одна компания

Роли

Организатор

Помощник организатора

Уступчивые участники

Проактивные участники

Нейтральные участники

Вопросы исследования

Как принимают решения

Что происходило при разногласиях

Где возникали сложности

Как их решали

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

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

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

Выводы из исследования

1 — Несогласие может остаться невысказанным

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

2 — Причин разногласий несколько

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

3 — Деньги в поездке требуют отдельного внимания

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

4 — Одно и то же решение помнят по‑разному

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

Конкуренты и их позиционирование

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

Продукт

Возможности

Точки роста

Doodle

Возможности

Опросы и голосование для согласования решений

Точки роста

Механики группового выбора

WhenAvailable

Возможности

Голосование за даты и время, приватные ответы, дедлайны

Точки роста

Возможность выражать предпочтения без влияния ответов других участников

Google Docs, Sheets

Возможности

Совместные таблицы, комментарии, формулы и расчёты

Точки роста

Гибкость, но необходимость самостоятельно организовывать информацию

Wanderlog

Возможности

Совместное планирование маршрута, сохранение мест, бронирования, бюджет и расходы

Точки роста

Комплексное планирование поездки в одном пространстве

TripIt

Возможности

Сбор бронирований и формирование единого маршрута

Точки роста

Структурирование разрозненной информации о поездке

Troupe

Возможности

Организация групповых поездок и мероприятий, приглашения, маршруты и платежи

Точки роста

Управление участниками и организационными процессами

Splitwise

Возможности

Учёт общих расходов, автоматический расчёт долгов и балансов

Точки роста

Прозрачное распределение расходов между участниками

Tricount

Возможности

Учёт расходов, разделение платежей, расчёт взаимных долгов и запросы на возврат

Точки роста

Упрощение расчётов и напоминаний о задолженностях

SquadTrip

Возможности

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

Точки роста

Снижение нагрузки на организатора при сборе денег

Pangea

Возможности

Социальные функции для путешественников, обмен планами и групповые чаты

Точки роста

Социальная составляющая путешествий

Will U Be There

Возможности

Обмен планами поездок и поиск совпадений с маршрутами друзей

Точки роста

Координация планов и контроль видимости личной информации

Для кого и зачем

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

Трение в жизни

Что делает продукт

Идеи теряются в чате

Единый список идей с ответами «иду / возможно / не иду»

Организатор решает за всех

Любой участник может вынести вопрос на голосование

Тяжело отказаться от неинтересной или дорогой активности

Ответ «не иду» без комментария; человек не попадает в делёжку расходов

Стыдно голосовать против большинства

Анонимное голосование; результаты видны после собственного голоса

Непонятно, кто что оплатил

Общий список расходов, баланс, минимум переводов

Неловко просить деньги

Напоминание от приложения

Что вошло в MVP и почему

Главное продуктовое решение я пересматривал по ходу работы.
Сначала ядром казались создание поездки и приглашения, а расходы, голосования и план по дням я отодвигал во вторую волну. Потом сверил это с основной болью, исследованием и передумал. Без этих опор продукт превращается в очередной список участников: людей он собирает, но ни одну из четырёх болей не лечит.

В MVP вошли четыре опоры:

01

Собрать группу: поездка, участники, приглашения

02

Спланировать: идеи и план по дням, кто участвует

03

Решить: голосования вместо споров

04

Рассчитаться: расходы, баланс, переводы

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

Решение 1

Войти без трения

Гипотеза

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

Что проверяем

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

Решение 2

Отказатся без объяснений

Гипотеза

Если участники смогут предлагать активности и отмечать своё отношение к ним без необходимости объяснять отказ, им будет проще выражать личные предпочтения. Это может помочь группе учитывать разные интересы, не превращая каждое несогласие в отдельное обсуждение.

Что проверяем

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

Решение 3

Голосовать без давления

Гипотеза

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

Что проверяем

Влияет ли такой формат на готовность голосовать и меняется ли распределение ответов по сравнению с открытым голосованием.

Решение 3

Рассчитаться без неловкости

Гипотеза

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

Что проверяем

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

Модель как основа интерфейса

Перед экранами я описал предметную область: 13 сущностей (поездка, участник, приглашение, активность, голосование, расход, расчёт и другие), их связи и жизненные циклы. Эту работу не видно, но она определяет, что появится на экране, а чего там быть не должно.

Пять примеров, где решение в модели прямо изменило интерфейс:

Решение в модели

Что изменилось в интерфейсе

У поездки есть статус draft (пока в ней один организатор), но пользователю он не нужен

Слова «Черновик» нет. Поездка выглядит как обычная, а вместо технического статуса стоит подсказка «Пригласите участников»

При архивации сохраняется, из какого статуса поездка ушла в архив

Участники видят понятные метки «Отменена» или «Завершена», а не абстрактное «В архиве»

Анонимный ответ хранится без идентификатора участника

Анонимность настоящая: организатор тоже не увидит, кто как проголосовал

У перевода денег есть статус «ожидает подтверждения»

Отправитель отмечает перевод, получатель подтверждает. Споров «я уже перевёл» должно быть меньше

Ответ «не иду» привязан к расходам

При добавлении расхода на активность такой участник по умолчанию исключён из делёжки

Спецификации

Каждый экран в документации описан по одной схеме: назначение, таблица элементов (контент, источник данных, поведение), таблица состояний, правила и права, edge cases, definition of done. Для голосования, например, я описал восемь состояний карточки: не проголосовал, проголосовал, анонимное, открытое, победитель, ничья, решено вручную, без голосов.
Спецификация закрывает разрыв между макетом и кодом. ИИ получает не только картинку, но и ответ на вопрос «что будет, когда…»: пропала сеть, голос отдан в последнюю секунду, поездку архивировали посреди голосования. Часть ошибок видна ещё до кода.
Дизайн‑систему я делаю вместе с экранами, а не отдельным этапом. Цель в том, чтобы Figma и код на Flutter говорили на одном языке, поэтому у каждого компонента одно имя и в дизайне, и в коде.