Fintech · B2B · Web-платформа · UX/UI · Дизайн-система
Личный кабинет мерчанта: как мы сделали сложные финансовые операции понятными
UX/UI для B2B-платформы, где ошибка пользователя стоит денег: платежи, возвраты и оспаривание платежей (чарджбэки).
Клиент
Финансовая организация, обслуживающая малый бизнес (NDA)
Услуги
UX-исследование, проектирование сценариев, UI-дизайн, дизайн-система
Платформа
Web, desktop-first
Статус
Проект завершён
ИЗОБРАЖЕНИЕ 1
Главный экран кабинета: дашборд с таблицей транзакций и открытой боковой панелью
О проекте
Финансовая организация, обслуживающая малый бизнес, запускала новый кабинет мерчанта. Через него владельцы кафе, магазинов и их бухгалтеры принимают платежи, возвращают деньги клиентам и отвечают на оспаривания платежей.
Эти операции стоят денег. Ошибка в возврате необратима, пропущенный дедлайн по спору означает потерю суммы, а непонятный статус превращается в звонок в поддержку. Наша задача была не нарисовать интерфейс, а сделать так, чтобы пользователь не ошибался и всегда понимал, что происходит.
Что мы сделали
- UX-исследование и разбор бизнес-правил
- Проектирование сценариев возвратов, платежей и споров
- Интерфейсы кабинета мерчанта и сервисных экранов
- Дизайн-система
Главные UX-проблемы
01
Высокая цена ошибки
Возврат нельзя отменить, спор нельзя переподать. Интерфейс должен останавливать пользователя до ошибки, а не сообщать о ней после.
02
Сложные состояния
У возврата четыре статуса с разными причинами. Пользователь не обязан знать, чем «отклонён» отличается от «не выполнен», он должен знать, что делать дальше.
03
Юридически значимый процесс
Ответ на спор требует решения, комментария, документов и подтверждения достоверности данных. В одной длинной форме мерчант теряется и пропускает дедлайн.
04
Плотные данные
Таблицы с суммами, датами, статусами и идентификаторами нужно читать по восемь часов в день без усталости.
05
Две аудитории
Мерчанту нужна простота, сотруднику организации нужен полный контекст по тому же мерчанту.
UX-решения
Не дать ошибиться
Проблема. возврат необратим, а условия его выполнения сложные: ограниченное окно, достаточный баланс, отсутствие активного спора.
Решение. интерфейс проверяет условия до действия. Если возврат невозможен, кнопка остаётся на месте, но рядом объясняется причина. Перед отправкой пользователь видит сумму и последствия.
Почему так. скрытая кнопка заставляет искать, куда она пропала. Заблокированная кнопка без причины приводит к обращению в поддержку. Объяснение причины закрывает оба случая.
ИЗОБРАЖЕНИЕ 2
Детали транзакции: действия «Отправить чек» и «Оформить возврат», недоступный возврат с объяснением причины
Говорить на языке пользователя
Проблема. система различает отмену платежа и возврат, а мерчанту нужно одно: вернуть деньги клиенту.
Решение. в интерфейсе одно действие «Оформить возврат». Какая операция запускается внутри, определяется статусом платежа. Тип операции в списке собран из нескольких технических полей в понятную подпись.
Почему так. пользователь принимает решение о деньгах, а не об API.
Каждый статус отвечает на вопрос «что мне делать»
Проблема. статус «отклонён» сам по себе ничего не объясняет.
Решение. у каждого статуса есть цвет, подпись, причина и следующий шаг. При нехватке средств на балансе интерфейс сообщает причину и предлагает вернуть деньги клиенту другим способом.
Почему так. цвет работает как быстрый сигнал, но не как единственный носитель смысла.
ИЗОБРАЖЕНИЕ 3
Статусы возврата: цвет, подпись, причина и следующий шаг
Разбить сложный процесс на шаги
Проблема. ответ на спор включает решение, аргументы, файлы и юридическое подтверждение.
Решение. три шага: решение, доказательства, проверка и отправка. Ветка «принять спор» короче и не заставляет проходить лишнее. Сохранение черновика позволяет собрать документы и вернуться. Тип файла выбирается с пояснениями, форматы указаны заранее. На последнем шаге мерчант видит всё, что отправляет, и подтверждает достоверность данных.
Почему так. в стрессовом сценарии с дедлайном пользователю нужно видеть, где он находится и сколько осталось.
ИЗОБРАЖЕНИЕ 4
Три шага ответа на спор: Решение → Доказательства → Проверка и отправка
ИЗОБРАЖЕНИЕ 5
Загрузка доказательств: выбор типа файла, форматы, список загруженных файлов
Задать ожидания после действия
Проблема. после отправки ответа на спор мерчант не знает, что будет дальше.
Решение. финальное сообщение объясняет, сколько времени у банка-эмитента на ответ и где смотреть статус. Спорная сумма в деталях помечена как удержанная до решения.
Почему так. неопределённость после отправки порождает повторные обращения в поддержку.
ИЗОБРАЖЕНИЕ 6
Финальное сообщение после отправки ответа и список споров со статусами
Сохранять контекст
Проблема. детали операции в раскрывающихся строках ломают структуру таблицы, а модальные окна закрывают данные, с которыми сверяется пользователь.
Решение. детали и процессы открываются в правой боковой панели, список остаётся перед глазами. Пользователь переключается между операциями, не теряя место.
Почему так. в работе с большим объёмом данных потеря контекста дороже лишнего клика.
ИЗОБРАЖЕНИЕ 7
Боковая панель с деталями операции поверх списка транзакций
Показывать, почему данные выглядят именно так
Проблема. свёрнутые фильтры скрывают условия, и пользователь не понимает, почему в таблице именно эти строки.
Решение. панель фильтров свёртывается, а выбранные условия остаются видимыми чипами. Набор фильтров соответствует столбцам таблицы, сумма фильтруется по условиям «больше, меньше, равно, диапазон».
Почему так. прозрачность выборки снижает риск работать с неполными данными.
ИЗОБРАЖЕНИЕ 8
Панель фильтров: развёрнутая и свёрнутая с чипами выбранных условий
Убрать визуальный шум
Проблема. таблицы с постоянной заливкой строк быстро утомляют.
Решение. подсветка строки только при наведении, статусы различаются маркерами и текстом, а не фоном целых строк.
Почему так. снижение когнитивной нагрузки важно для людей, работающих с таблицей весь день.
Назвать вещи точно
Проблема. раздел «Платежи и возвраты» объединял два разных действия.
Решение. приём платежа выделен отдельно, а возвраты выполняются из деталей операции, где у них есть контекст.
Почему так. название раздела определяет ожидания пользователя от его содержимого.
Дизайн-система
Мы собрали единую систему компонентов: таблицы, боковые панели, фильтры и чипы, статус-бейджи, формы, пошаговые сценарии, загрузку файлов и подтверждающие окна. Она сделала интерфейс единообразным и упростила его дальнейшее развитие.
ИЗОБРАЖЕНИЕ 9
Библиотека компонентов дизайн-системы
Как мы работали
01
Разбор бизнес-правил
Определили, что система может, а что нет, и вынесли открытые вопросы на согласование до макетов.
02
Матрица состояний
Для каждой сущности описали, что видит пользователь, что он может сделать и что ему сообщает интерфейс.
03
Сценарии с граничными случаями
Недостаток средств, истёкшее окно возврата, активный спор.
04
Итерации с владельцем продукта
Регулярные ревью макетов и согласование с бизнес-направлением.
05
UI и дизайн-система
Единые компоненты для таблиц, панелей, фильтров, статусов, форм и пошаговых сценариев.
Результат
Проект завершён, клиент принял результат и остался доволен. Три ключевых процесса проработаны от основного сценария до ошибочных состояний. Интерфейс объясняет ограничения вместо того, чтобы молча блокировать действия. У клиента есть дизайн-система, которая позволяет развивать кабинет дальше без потери единообразия.
Что мы можем для вас сделать
- Спроектировать интерфейсы для продуктов, где ошибка пользователя стоит денег.
- Превратить сложные процессы (споры, согласования, регуляторные формы) в понятные сценарии.
- Сделать плотные рабочие интерфейсы удобными для ежедневной работы.
- Собрать дизайн-систему, которая ускорит разработку и сохранит качество.