Совместный счёт

Проектирование | Дизайн интерфейса

Совместный счёт в приложении FinRise

Создание функционала совместного счёта («Копилки») для объединения группы людей, планирующих общее накопление.

Совместный накопительный счет в приложении FinRise

Роль: Product Designer

Клиент: FinRise

Период реализации: Ноябрь 2025 — Февраль 2026

1.1. Контекст

FinRise — MVP финтех-приложения (minimum viable product) для управления личными финансами с возможностью создавать внутренние счета. На текущий момент реализованы два типа счетов: депозитный и накопительный. Приложение позволяет отслеживать поступления и траты в заданном интервале времени, планировать и контролировать расходы. При этом в текущей версии нет ни одного сценария для совместного накопления.

1.2. Проблема

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

трудоёмкому ручному учёту в формате «кто, сколько и когда внёс»;
конфликтам и недоверию внутри группы из-за непрозрачности баланса;
потере мотивации — перечисления в «копилку» становятся редкими, а процесс накопления часто саботируется.

Банковские приложения не умеют группировать переводы по целям. В итоге совместное накопление превращается во вторую бухгалтерию.

1.3. Задача

Спроектировать в приложении FinRise функционал совместного счёта («Копилки»),который позволит группе людей копить на общую цель: видеть прогресс, отслеживать взносы каждого и договориться о правилах траты.

1.4. Ограничения

Интеграция в существующий UX приложения FinRise
Работа внутри экосистемы: на этапе MVP поступление средств осуществляется только с внутренних счетов пользователей FinRise
Приглашение внешних участников (не зарегистрированных в FinRise) реализуется через реферальную ссылку: авторизация по номеру телефона и СМС-коду. Интеграция с Системой быстрых платежей (СБП) и внешними банками вынесена в план развития следующих версий.

Главный экран приложения. Блок существующих счетов. Задача по реализации дополнительного счета.

Раздел приложения «Счета».

В начале я провёл сравнительный анализ восьми финансовых продуктов, в которых присутствует функционал совместных накоплений: Revolut, Monzo, Т-Банк, Сбер, ВТБ, ЮMoney, Райффайзенбанк и Ally Bank. Сформировал таблицу возможностей совместных накоплений в каждом приложении, а также провел аудит пользовательского опыта ключевых сценариев.

Цель: изучить решения по совместным счетам в приложениях конкурентов и выявить функциональные пробелы для проработки в приложении FinRise.

Revolut

Monzo

Т-Банк

Сбербанк

ЮMoney

Ally Bank

Monzo

Revolut

Monzo

Т-Банк

Сбербанк

ЮMoney

Ally Bank

Monzo

Revolut

Сбербанк

Revolut

Monzo

Т-Банк

Сбербанк

ЮMoney

Ally Bank

Monzo

Revolut

Monzo

Т-Банк

Сбербанк

ЮMoney

Ally Bank

Monzo

Revolut

2.1. Сводная таблица функционала

Разработчик (Продукт)	Участники	Вывод средств
(Group Pockets)	Не ограничено	С разрешения владельца счёта
(Joint Pots)	2	Равные права
(Совместный счёт)	до 10
(Цели + Совместный доступ)	до 10	Только пополнение
(Семейная копилка)	до 6
(Совместные счета)	до 10
(Конверт)	1 (индивидуальный счёт)	Владелец счёта
(Savings Buckets)	2

— Доступно

— Недоступно

— Реализовано частично

8 продуктов

5 гипотез

5 решений

На основе анализа 8 продуктов я сформулировал 5 предположений о болях пользователей. Эти предположения (гипотезы B1–B5) впоследствии были проверены в интервью с реальными пользователями (раздел 3).

№	Вывод	Предположение	Гипотеза	Статус	Решение для FinRise
1	Разрыв между целеполаганием и совместностью Лучшие инструменты визуализации целей (Райффайзенбанк, Сбер) — индивидуальные. Совместные счета (Т-Банк, ЮMoney) не имеют фокуса на цель.	Пользователи стоят перед выбором цели накопления или совместного пользования общего счета.	Пользователи выбирают: удобное целеполагание или совместное накопление.	Подтверждена 4/10 респондентов	Объединить в интерфейсе жесткое целеполагание (сумма, срок, визуальный прогресс) и мультипользовательский доступ.
2	Асимметрия прав в интерфейсе В 90% рассмотренных продуктов создатель счета — единоличный владелец денег. Остальные участники — бесправные «доноры». Исключение — Monzo, но там нужен полноценный joint account.	Неравные права и роли в интерфейсе («Владелец» и «Участник») создают психологический барьер и снижают вовлечённость.	Неравноправие в интерфейсе («Владелец» и «Участник») создаёт психологический барьер и снижает вовлечённость.	Подтверждена 5/10 респондентов	Внедрить интерфейсное равенство. На уровне UI все участники видят одинаковые экраны и обладают равными правами, а правила вывода средств прозрачно регулируются соглашением при старте.
3	Отсутствие персонального трекинга вкладов Продукты либо скрывают, кто сколько внёс (Revolut), либо выдают в виде нечитаемой ленты транзакций (ЮMoney). Ни один конкурент не показывает личный прогресс каждого участника.	Отсутствие наглядного личного вклада приводит к конфликтам и путанице кто сколько внес, чей взнос в сумме больше.	Отсутствие наглядного личного вклада приводит к межличностным конфликтам и путанице.	Подтверждена 7/10 респондентов	Аватары участников с персональными шкалами выполнения своей доли («Алексей: 45 000 ₽ из 50 000 ₽»).
4	Игнорирование социальной механики Финансовые приложения относятся к совместным накоплениям как к обычной транзакционной рутине. Нет промежуточного празднования или челленджей.	Динамика сборов угасает из-за отсутствия внешних триггеров и напоминаний.	Динамика сборов угасает из-за отсутствия внешних триггеров и напоминаний и похвалы за внутренние достижения прогресса.	Подтверждена 4/10 респондентов	Спроектировать систему автоматических дружелюбных триггеров (стрики, поздравления с достижением шага цели), которые снимут с создателя счета роль «коллектора».
5	Высокий барьер входа Для старта совместного накопления банки требуют пройденный KYC (Monzo, Т-Банк) или громоздкие «семейные группы» (ВТБ, Сбер).	Длинный путь авторизации участников совместного счета заставляет их возвращаться к обычным переводам на карту.	Длинный и сложный путь авторизации участников заставляет возвращаться к обычным способам перевода финансов.	Подтверждена 8/10 респондентов	Мгновенный вход для внешних участников по реферальной ссылке или QR-коду (номер телефона + СМС-код) с возможностью сразу увидеть интерфейс совместного счета «Копилки».

3. Исследование: интервью с пользователями

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

Эти паттерны были синтезированы в 3 унифицированные персоны — они стали базой для приоритизации функционала в MVP.

Метод: глубинные качественные интервью

Выборка: 10 респондентов, имеющих опыт совместного планирования финансов

Платформа: Мессенджеры

Продолжительность: 20 – 40 мин.

Дата: декабрь 2025

Персона 1

«Анна, 27 лет, продакт-менеджер» (Планирующая пара)

Демография:

25–35 лет, совокупный доход средний / выше среднего.

Контекст:

Живёт вместе с партнёром (в браке или без), копит на крупные цели (первый взнос по ипотеке, отпуск, ремонт).

Боли:

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

Мотивация:

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

JTBD 1:

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

JTBD 2:

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

Персона 2

«Денис, 30 лет, разработчик» (Компания друзей)

Демография:

20–30 лет, студенты старших курсов, молодые специалисты.

Контекст:

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

Боли:

Кто-то постоянно забывает сдать деньги, организатору неловко выступать в роли просителя и «выбивать» долги, хаос в чатах мессенджеров.

Мотивация:

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

JTBD 1:

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

JTBD 2:

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

Персона 3

«Марина, 43 года, мама двоих детей» (Семья с детьми)

Демография:

35–50 лет, имеет детей школьного возраста, активно подключает старшее поколение (бабушек/дедушек).

Контекст:

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

Боли:

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

Мотивация:

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

JTBD:

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

Инсайт 1

Рутина ручного учёта.

7 из 10 респондентов тратят до 30 минут в неделю на заполнение сторонних таблиц, заметок или бумажных блокнотов просто потому, что банковское приложение не умеет группировать переводы по целям.
Инсайт 2

Психологический дискомфорт роли «Участника сбора».

Пользователи признались, что когда они видят в приложении плашку «Владелец счета: [Имя]», у них снижается мотивация вносить туда деньги, так как они подсознательно не воспринимают этот счёт как свой собственный.
Инсайт 3

Потребность в краудфандинговом UX.

Респонденты хотят видеть интерфейс, похожий на платформы вроде Kickstarter или социальные счетчики дедлайнов (в стиле «осталось 40 дней, собрано 60%»), а не выписку по расчётному счёту.
Инсайт 4

Автоматизация деликатных напоминаний.

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

По результатам исследования ключевых сценариев 8 финансовых продуктов и 10 проведенных интервью я сформулировал 11 конкретных решений: часть функционала вошла в ядро MVP, часть запланирована на последующие релизы (v1.1 и v2.0), несколько фичей отложены до подтверждения долгосрочной ценности.

В таблице ниже — приоритизированный набор функционала: сначала решения, критичные для запуска первой версии (Must-have для MVP), затем улучшения, которые усиливают опыт в ближайших релизах, и отдельно учтена часть дополнительного функционала, сформированного из потребностей респондентов, участвовавших в интервью.

Метод: фреймворк MoSCoW

4.1. План решений по MVP

Приоритет / Функционал	Гипотеза	Обоснование	Релиз	Комментарий
Индивидуальный трекер вкладов	B3 Отсутствие наглядного личного вклада приводит к межличностным конфликтам и путанице.	Подтверждено 7/10 респондентов. Устраняет ручной учёт взносов.	Текущая версия MVP.	⚡ Риск без реализации: Продукт не решает главную проблему, пользователи продолжат пользоваться привычными способами.
Упрощённый онбординг (ссылка/QR)	B5 Длинный и сложный путь авторизации участников заставляет возвращаться к обычным способам перевода финансов.	Главный барьер для 8/10 респондентов. Быстрый вход без KYC для малых сумм.	Текущая версия MVP.	⚡ Риск без реализации: Высокий отток (Drop-off) на этапе приглашения участников.
Интерфейсный паритет прав	B2 Неравноправие в интерфейсе («Владелец» и «Участник») создаёт психологический барьер и снижает вовлечённость.	Снимает сильный психологический барьер «второстепенности» (5/10 респондентов).	Текущая версия MVP.	⚡ Риск без реализации: Низкая вовлечённость приглашённых участников.
Визуальное целеполагание (Дата + Срок + Прогноз)	B1 Пользователи выбирают: удобное целеполагание или совместное накопление.	Ценность для 4/10 респондентов, критично для долгосрочных целей пар.	Релиз v1.1. Базовый экран — в MVP, умный предиктивный прогноз — в v1.1.
Системные push-напоминания	B4 Динамика сборов угасает из-за отсутствия внешних триггеров и напоминаний и похвалы за внутренние достижения прогресса.	Закрывает боль «неловких разговоров» для сегмента друзей (4/10 респондентов).	Релиз v1.1. В MVP — ручной триггер «Напомнить всем», в v1.1 — автоматический функционал.
Экспорт истории операций (PDF/CSV)	B3 Отсутствие наглядного личного вклада приводит к межличностным конфликтам и путанице.	Необходимо узкому сегменту пользователей (1/10 респондентов) для детального аудита.	Перенесено в v2.0.
Анонимные взносы		Специфический сценарий для благотворительности или касс взаимопомощи (1/10 респондентов).	Перенесено в v2.0.
Pledge-механика (Обещание платежа)		Механика фиксации намерения сдать деньги без моментального списания.	Перенесено в v2.0.
Начисление процентов на остаток «Копилки»		Усложняет юридическую структуру MVP, не является core-ценностью для пользователей на старте.
Прямая интеграция с внешними банками через СБП		Ограничение архитектуры MVP. Все транзакции идут строго через внутренние счета FinRise.
Внутригрупповое P2P-кредитование		Высокие юридические риски, требует дополнительных банковских лицензий.

— Must-have

— Should-have

— Could-have

— Won’t-have

На основе интервью и валидации гипотез B1–B5 я построил карту текущего пути клиента при совместных накоплениях. Она помогает увидеть полную картину: от осознания потребности до достижения цели. Карта выявляет ключевые боли, эмоциональные спады и возможности для улучшения опыта.

Ключевой персонаж: Анна, 27 лет, продакт-менеджер. Синтезирует в себе паттерны планирования и чувствительность к интерфейсному равноправию.
Сценарий: Вместе с партнером копит на первоначальный взнос для покупки квартиры (цель: 3 000 000 ₽, срок — 18 месяцев).

Этап	1 Осознание и Поиск	2 Создание «Копилки»	3 Первый взнос	4 Регулярный трекинг	5 Целевая трата	6 Расформирование
Действие	Ищет способ копить вместе, находит FinRise.	Создаёт копилку: сумма, срок, отправляет инвайт партнёру.	Партнёр переходит по ссылке → регистрация → первый взнос.	Заходят на дашборд, смотрят прогресс, вносят регулярно.	Цель достигнута. Перевод на оплату.	Анна или участник решает выйти из копилки (ссора, разногласие, отмена цели).
Мысли	«Надоели таблицы. Где счёт — наш, а не только мой?»	«Не будет ли 20 шагов регистрации? Партнёр разберётся?»	«Деньги защищены? Вижу шкалу — я не гость».	«15% за месяц. Партнёр не отстаёт — супер!»	«Ура! Как безопасно вывести деньги?»	«Как разделить остаток? Хочу забрать свою часть и уйти.»
Эмоции	Надежда ⭐⭐⭐ Сомнение ⭐⭐⭐	Вовлечённость ⭐⭐⭐⭐⭐ Тревога ⭐⭐⭐⭐	Облегчение ⭐⭐⭐⭐⭐ Удовлетворение ⭐⭐⭐⭐⭐	Мотивация ⭐⭐⭐⭐⭐ Спад тонуса ⭐⭐⭐	Эйфория ⭐⭐⭐⭐⭐ Осторожность ⭐⭐⭐⭐	Напряжение ⭐⭐⭐⭐⭐ Доверие ⭐⭐⭐⭐⭐
Точки контакта	App Store, маркетинговый лендинг, социальные сети.	Flow создания совместного счета, отправка приглашений.	Страница онбординга, экран открытия внутреннего счёта, первое push-уведомление.	Дашборд копилки, периодический push-отчёт.	Экран вывода средств, push-оповещение для всех участников.	Экран расчёта долей, подтверждение от всех участников, перевод на личные счета.
Проблемы / боли	Продукт кажется закрытым для друзей и неформальных групп.	Опасение сложного КYC для участников. Поле «владелец счета» = напряжение.	Боязнь, что деньги принадлежат только Анне. Не видно, сколько внёс другой.	Успеем к дедлайну? Интерес падает через 2–3 месяца.	Один заберёт всё без спроса?	Споры о долях. Выход одного = закрытие копилки?
Возможности	Позиционирование: «Копите с кем угодно».	Первый вопрос: «На что копим?» Нет поля «владелец».	Баланс общий, взносы видны всем. Push группе.	Прогноз: «Успеете на 2 недели раньше». Стрики, milestones.	Multi-sig: трата требует согласия всех. Категория траты.	Авто-расчёт долей. Выход одного без закрытия копилки.

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

6.1. Открытие совместного накопительного счета «Копилка»

1 Пользователь запускает приложение, вводит пароль для входа, попадает на главную страницу приложения.

2 В блоке «Счета» нажимает кнопку с плюсом для создания нового счета. Выбирает счет «Копилка» и нажимает «Далее».

3 На странице настройки совместного счета заполняет все необходимые данные, выбирает способ распределения суммы общего накопления и переходит «Далее».

4 На этапе приглашения участников совместного счета пользователь может выбрать их из доступного списка пользователей приложения или отправить приглашение из списка контактов.

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

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

Экран успешного завершения создания совместного счета.

Совместный счет «Копилка» в разделе счетов на главном экране.

6.2. Функциональное наполнение раздела

1 Пользователь запускает приложение, вводит пароль для входа, попадает в свой профиль.

2 В блоке «Счета» нажимает кнопку с плюсом для создания нового счета.

3 Выбирает тип счета из предложенных вариантов.

4 Подтверждает создание счета через СМС-код.

5 Новый счет появляется в списке с нулевым балансом.

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

Запуск (Week 1-2)

Первичное внедрение и базовая активность

Конверсия в создание

Клик по кнопке → Успешное создание «Копилки»

Целевое значение: >40%

Созданные «Копилки»

Общее количество созданных счетов

Целевое значение: 100+ за 2 недели

Раннее использование (Week 3-4)

Вовлечение партнёров и первые транзакции

Приглашённые партнёры

Среднее число активных партнёров на одну «Копилку»

Целевое значение: 2-4 человека

Время до первого взноса

Медианное время от открытия ссылки до первого взноса

Целевое значение: <24 часа

Зрелость (Month 2+)

Регулярное использование и удержание

Retention (Day 30)

% пользователей, активных через 30 дней

Целевое значение: >35%

TVL

Общая сумма средств во всех «Копилках»

Показывает общий объём доверия к фиче

Источники метрик: бенчмарки успешных финтех-приложений (Revolut, Monzo, N26), а также метрики юзабилити из Nielsen Norman Group.

MVP решает задачу запуска совместного накопления: создать «Копилку», пригласить участников и видеть прогресс без ручного учёта. Дальше ключевой вызов — удержать динамику сборов, которая, по результатам интервью, угасает через 2–3 месяца. Поэтому в развитии продукта я сфокусировался на механиках, поддерживающих регулярность и вовлечённость группы.

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

Стрики регулярности (Streaks): Счётчик недель непрерывного пополнения «Копилки» группой. Сброс счётчика мотивирует участников не пропускать платежи.