Дизайн личного кабинета финтеха: от прототипа к продукту

Коротко

• Личный кабинет готов к показу партнёрам, когда их операционисты работают в нём без вас: есть роли, статус у каждой выплаты, путь исправления ошибок и журнал изменений.
• Дизайн личного кабинета B2B начинайте с ролей: администратор, менеджер, согласующий, наблюдатель. Выплату готовит один человек, а согласует другой — принцип четырёх глаз.
• У каждой выплаты один статус со временем, ответственным и следующим шагом. Даже статус paid может смениться на failed: так прямо пишет Stripe.
• Реестр выплат проверяйте построчно до согласования: строка, поле, способ исправления. Чистые строки идут дальше, остальные ждут.
• NVP прошёл путь от брифа до кабинета для партнёров за 15 дней: дизайн на компонентах самого продукта, первый редизайн — в коде уже на следующий день.

Личный кабинет финтех-сервиса готов к показу партнёрам, когда их операционная команда может работать в нём без вас на созвоне. Для платформы выплат это четыре вещи: роли, где подготовка выплаты отделена от согласования, статус у каждого платежа, понятный путь при ошибке и журнал изменений. Прототип кабинета NVP мы довели до этого уровня за 15 дней от брифа.

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

Примеры — из NVP, финтех-платформы для компаний с большими командами фрилансеров: она подключает, проверяет и платит самозанятым, ИП и исполнителям по ГПХ (договорам гражданско-правового характера). Ещё два примера — внутренние системы, которые мы сделали: CRM для Encore и бэк-офис RYTM. Если прототипу сначала нужен взгляд со стороны, начните с нашего разбора UX-аудита для SaaS.

Чем кабинет для партнёров отличается от демо

Демо работает, пока за рулём основатель. Кабинет готов для партнёров, когда за руль садится кто-то другой: новый пользователь сам видит, что случилось с каждым платежом, что его задерживает и чей следующий шаг. Первая эвристика юзабилити от Nielsen Norman Group (NN/g), исследовательской компании в области UX, говорит об этом прямо:

«Сайты и приложения должны ясно сообщать пользователям, в каком состоянии находится система: ни одно действие с последствиями для пользователей не должно выполняться без их ведома». — Nielsen Norman Group, Visibility of System Status, 2018 (перевод наш)

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

Демо и кабинет для партнёров по зонам. Наш рабочий чек-лист (2026), а не данные исследования: в колонке «Демо» — типичные пробелы, а не прототип конкретного клиента.

У NVP был рабочий прототип для всего процесса, но он выглядел как внутренний инструмент, а в мае его предстояло показать партнёрам. Продукт должен был восприниматься как серьёзный B2B-сервис — и на ноутбуке, и на телефоне.

Какие роли нужны в личном кабинете B2B

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

Разделение менеджера и согласующего называют принципом четырёх глаз, или maker-checker: один человек готовит платёж, второй, с правом согласования, проверяет и выпускает его. Так ни один логин не выведет деньги в одиночку. В NVP так и устроено: менеджеры готовят реестр, уполномоченные сотрудники его согласуют.

В интерфейсе принцип четырёх глаз выглядит так:

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

Та же карта ролей нужна любому личному кабинету B2B, включая внутренние системы. Когда мы перевели Encore, дубайское агентство PR, медиа и ивентов, с Asana на собственную CRM, клиенты получили доску в режиме просмотра: следят за работой, но ничего не меняют. Это та же роль наблюдателя, только для человека вне компании.

Как устроить онбординг и проверки исполнителей

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

В NVP на каждого исполнителя, которому платит компания, нужны договор, акт приёмки (документ о том, что работа сделана и принята), а если он самозанятый — ещё и чек. К тому же массовые выплаты могут привести к блокировке счёта компании. Поэтому процесс идёт в жёстком порядке:

1. Приглашение: компания приглашает исполнителей всех трёх типов в один сценарий выплат.
2. Документы: исполнитель загружает их через защищённый кабинет.
3. Проверки: до начала работ — проверка патента и проверка по реестру контролируемых лиц.
4. Задание: менеджер ставит задание и ведёт его до приёмки.
5. Подписание: исполнитель подписывает договор и акт OTP-кодом (одноразовым паролем).
6. Согласование: шаг по принципу четырёх глаз из предыдущего раздела.
7. Выплата: деньги уходят с номинального счёта (его ведёт платформа, но деньги на нём принадлежат её клиентам) в банк или на кошелёк.

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

Статусы выплат: что видит пользователь и что может сделать

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

Часть состояний задаёт банк, а не вы. В справочнике API Stripe на октябрь 2026 года у выплаты пять статусов: pending (ожидает), in_transit (в пути), paid (выплачена), failed (не прошла) и canceled (отменена). Сменить статус на failed или canceled выплата может в течение 5 рабочих дней. Там же есть оговорка:

«Некоторые выплаты, которые не прошли, могут сначала отображаться как paid, а затем смениться на failed». — Stripe API reference, The Payout object, октябрь 2026 (перевод наш)

Из-за этой фразы в модели ниже есть статус «Возврат». Деньги, которые показали как выплаченные, а потом вернули, должны выглядеть иначе, чем выплата, которая так и не ушла.

Базовая модель статусов, которую мы рекомендуем для B2B-выплат, а не реальный список статусов NVP. Названия у провайдеров разные; статусы Stripe — выше (октябрь 2026).

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

Смена статуса должна доходить и до тех, кто сейчас не смотрит в экран: в CRM Encore ответственный получает сообщение в Telegram, как только на него ставят задачу. В бэк-офисе RYTM, который мы сделали для хронобиологического бренда с Бали, вебхук (автоматическое уведомление от Stripe серверу) переводит запись в статус «оплачено», как только Stripe подтверждает оплату. Запланированные, проведённые и записи с возвратом команда видит в одном списке.

UX финтеха: массовые выплаты и ошибки платежей

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

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

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

Таблице выплат нужны и стандартные паттерны массовой работы, которых часто нет в прототипах:

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

Неуспешной выплате нужны причина и способ исправления, а не код. Только в API Stripe на октябрь 2026 года 18 кодов ошибок выплат — от закрытого счёта до неверного имени владельца. Переведите каждый в фразу, по которой можно действовать («Банк сообщает, что счёт закрыт. Запросите у исполнителя новые реквизиты»), и дайте кнопку, которая открывает нужное поле. Для изменений из-за внешних событий эвристика NN/g требует объяснять случившееся кратко и понятно.

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

Дизайн дашборда: что показать на первом экране

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

NN/g делит дашборды на операционные, которые быстро дают критичную информацию во время срочной работы, и аналитические, которые помогают анализировать и принимать решения. Обоим нужен обзор с одного взгляда на одном экране. Ещё NN/g отмечает, что люди точно сравнивают длины и положение на плоскости, поэтому величины для сравнения лучше показывать столбцами и линиями.

В NVP дашборд — первый экран после входа, сделанный к майскому показу партнёрам. Семь блоков прототипа мы пересобрали в одну иерархию: наверху деньги и риски, ниже динамика и комплаенс, затем воронки. На экране это 4 KPI-карточки (ключевые показатели эффективности) от оборота до открытых предупреждений, динамика оборота с переключателем периода, комплаенс и просроченные документы, воронки онбординга и заданий.

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

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

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

В статье NN/g о доверии к дизайну 2016 года названы 4 фактора доверия: качество дизайна, раскрытие условий заранее, полный, точный и актуальный контент и связь с остальным интернетом. Раскрытие заранее включает указание всех дополнительных комиссий и сборов. В платформе выплат комиссия, лимит и сумма к зачислению должны стоять на экране согласования, а не в PDF с условиями.

Журнал аудита (запись о том, кто, что и когда сделал) закрывает первый вопрос партнёра о комплаенсе. Показывайте его пользователям, а не только разработчикам: короткая история на каждой выплате и полный журнал в настройках с фильтрами по сотруднику и дате. В бэк-офисе RYTM, который мы сделали, сотрудники входят через Google, их изменения попадают в журнал аудита, а каждое движение остатков по складам записывается.

Кейс · RYTMАйдентика, сайт, магазин и бэк-офис для велнес-бренда4языка в магазине и онлайн-записи

Публичный сайт — часть того же первого впечатления. В исследовании Туха и коллег 2012 года визуальная сложность и прототипичность (насколько сайт типичен для своей категории) влияли на оценку эстетики уже за первые 50 мс, а сайты с низкой сложностью и высокой прототипичностью воспринимались как очень привлекательные. Для финтех-дизайна вывод простой: продукт должен выглядеть как финтех. Для NVP мы сделали и публичный сайт, который проводит посетителя по шести модулям продукта.

Кейс NVP: от прототипа до кабинета для партнёров за 15 дней

Мы проектировали на компонентах самого продукта и разобрали экраны раньше, чем взялись за визуал. Первый редизайн заработал в коде NVP на следующий день после брифа, а финальный дашборд мы сдали за 15 дней — точно к майскому показу партнёрам.

Что позволило уложиться:

1. До первого пикселя мы разобрали все 18 экранов прототипа.
2. Мы проектировали на компонентах shadcn/ui, на которых построен сам продукт (это открытый набор React-компонентов, которые живут прямо в коде), поэтому первый редизайн заработал в его коде уже на следующий день.
3. 7 блоков дашборда мы пересобрали вокруг денег и рисков.
4. Мы отрисовали все состояния: форма задания и выплаты — пустая, заполненная, с ошибкой и успешная, загрузка реестра — в четырёх состояниях.

Кейс · NVPВыплаты и документы для компаний с фрилансерами15 днейот брифа до дашборда, готового к показу партнёрам

Скорость важна, потому что каждый круг на живых экранах улучшает продукт. В обзоре четырёх кейсов Якоба Нильсена 1993 года, среди которых был прототип домашнего банкинга, медианный прирост юзабилити составил 38% за итерацию и 165% от первой версии до последней.

Полная дизайн-система на этом этапе не нужна. В Design Systems 101 от NN/g (2021) сказано: для proof of concept или раннего прототипа, который ещё будет меняться, полноценная дизайн-система вряд ли окупится в ближайшее время.

Общая библиотека компонентов окупается и так: в эксперименте Figma 2019 года дизайнеры с дизайн-системой выполнили задачу на 34% быстрее. Задачей был экран приложения-агрегатора банковских счетов, и Figma считает эту цифру максимальной экономией, которую стоит ждать в реальной работе.

Чек-лист: готов ли кабинет к демо для партнёров

Пройдите по списку вместе с человеком, который ни разу не видел прототип. Каждое «нет» — вопрос, который команда партнёра задаст на встрече.

• У каждой роли свой вход и свой первый экран: администратор, менеджер, согласующий, наблюдатель.
• Ни одна выплата не уходит по клику одного человека: готовит один, согласует другой.
• У каждой выплаты один статус со временем, ответственным и следующим шагом, и называется он везде одинаково.
• Неуспешные и возвращённые выплаты показывают причину простыми словами и открывают поле для исправления.
• Загрузка реестра проверяет каждую строку до согласования и пропускает чистые строки дальше.
• Документы, проверки и лимиты стоят рядом с суммой, а на экране согласования видны комиссия и сумма к зачислению.
• Каждое изменение попадает в журнал аудита, который пользователь может открыть.
• У каждой формы есть пустое, заполненное, ошибочное и успешное состояния, а демо идёт на реалистичных данных.
• Согласования и уведомления работают на телефоне.
• Публичный сайт называет те же модули, что и продукт.

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

Частые вопросы

Что такое принцип четырёх глаз в платёжном сервисе?

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

Сколько времени занимает дизайн личного кабинета?

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

Нужна ли дизайн-система для личного кабинета на старте?

Полноценная — обычно нет. NN/g в статье Design Systems 101 (2021) пишет, что для раннего прототипа, который ещё будет меняться, полная дизайн-система вряд ли окупится в ближайшее время. Проектируйте на библиотеке компонентов, на которой уже работает продукт, например shadcn/ui. В эксперименте Figma 2019 года дизайнеры с дизайн-системой справились с задачей на 34% быстрее, и Figma считает это максимальной экономией.

Чем личный кабинет B2B отличается от B2C?

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

Нужна ли мобильная версия личного кабинета B2B?

Да, для действий, которые не ждут: согласований, предупреждений и проверки статуса выплаты. Загрузку реестров и отчёты можно оставить десктопными. NVP должен был выглядеть серьёзным B2B-сервисом и на ноутбуке, и на телефоне; его платформы — десктопный веб, мобильный веб и PWA (веб-приложение, которое устанавливают из браузера). Перед демо пройдите сценарий согласования с телефона.

Источники

1. Visibility of System Status (Usability Heuristic #1) · Nielsen Norman Group, 2018
2. The Payout object, API reference · Stripe, 2026
3. Dashboards: Making Charts and Graphs Easier to Understand · Nielsen Norman Group, 2017
4. Trustworthiness in Web Design: 4 Credibility Factors · Nielsen Norman Group, 2016
5. The role of visual complexity and prototypicality regarding first impression of websites: Working towards understanding aesthetic judgments · International Journal of Human-Computer Studies, Google Research, 2012
6. Iterative User Interface Design · Nielsen Norman Group, 1993
7. Design Systems 101 · Nielsen Norman Group, 2021
8. Measuring the value of design systems · Figma, 2019

Поделиться статьёй

Об авторе

Artsiom Yankovich

Руководитель дизайна и стратегии

Ведёт дизайн и стратегию: от логики продукта до бренда. 9+ лет, 150+ проектов.

Вся команда