Продуктовый дизайнер
с опытом
в финтех- и B2B-продуктах. Работал над MVP
и редизайнами сложных платформ, создавал дизайн-системы и проводил UX-исследования. Считаю,
что сильные продуктовые решения должны опираться
на данные, а не на догадки.
Product designer · Fintech & B2B
Толя Катаев
2025
The work you do while you procrastinate is probably the
2025
The work you do while you procrastinate is probably the
- Сделать инициатором сделки финансирующую сторону, это упростит запуск сценариев и снизит количество ошибок на старте.
- Если пересобрать логику запросов в единый понятный поток, пользователям будет проще понимать текущий статус и следующие шаги.
- Если добавить уведомления и явную обратную связь после действий, снизится количество ручных проверок и обращений в поддержку.
- Если унифицировать поведение компонентов и сократить количество модальных окон, интерфейс станет предсказуемее и понятнее.
Гипотезы
- Сложная и нестабильная UX-архитектура. Интерфейс формировался фрагментарно. Со временем появилось много вложенных модальных окон, компоненты вели себя по-разному, навигация стала разрозненной.
- Неудачная модель работы с запросами и продуктами. Запросы делились на входящие и исходящие и постоянно меняли статус и расположение.
- Коммуникация вне платформы. Обсуждение запросов и документов происходило в почте и мессенджерах. В самом продукте отсутствовали уведомления. Пользователям приходилось вручную проверять изменения. Это приводило к потере информации и замедляло процессы.
- Инициатор запроса. По словам пользователей, это выглядело нелогично: именно фактор управляет процессом финансирования и лучше понимает, какие данные и документы нужны.
Ключевые проблемы
В рамках редизайна было проработано более 100 экранов. В кейсе я показал только ключевые потоки, но изменения коснулись всего личного кабинета: запросов, профиля пользователя, профиля компании, уведомлений и вспомогательных экранов.
При юзабилити-тестировании пользователи отмечали, что стало понятнее, что происходит
с запросом и какие шаги нужно сделать дальше. Это позволило снизить количество ошибок
на старте запросов, ускорить согласование между сторонами и уменьшить нагрузку на поддержку.
Результат и вывод
Мы пробовали сделать жёсткий пошаговый сценарий работы с запросом, чтобы снизить количество ошибок. Но пользователи воспринимали это как излишнее ограничение и хотели больше гибкости. В итоге мы упростили поток.
Также мы рассматривали вариант ограничить запрос одной связкой документов. Пользователям оказалось удобнее работать с несколькими связками в рамках одного запроса, а не создавать отдельные запросы под каждый кейс. В итоге мы отказались от этого ограничения.
Что не сработало
Стало понятно, что пользователи часто теряют контекст: не понимают, на каком этапе находится запрос, не получают обратной связи после действий и вынуждены вручную проверять изменения — через почту и мессенджеры.
Перед началом проектирования мы провели серию интервью и кастдевов с пользователями платформы: поставщиками и представителями финансирующей стороны.
Исследование
Главный экран и продукты. На главном экране пользователь теперь видит: список доступных продуктов, недоступные продукты с пояснениями, текущий статус доступа. Это помогло убрать путаницу и сразу дать понимание, чем можно пользоваться прямо сейчас.
Решение
Обратная связь и уведомления. В продукт добавили уведомления о ключевых изменениях: смена статуса заявки, новые действия от контрагентов, изменения по документам. Пользователям больше не нужно вручную проверять обновления.
Коммуникация. Отдельно мы встроили чат прямо в контекст запроса. Теперь участники обсуждают вопросы и уточнения не в почте или мессенджерах, а внутри продукта — рядом
с конкретным запросом и его документами. Это снизило количество ручных проверок, потерю контекста и ощущение, что процесс «теряется» между участниками.
Логика запросов. Мы пересобрали работу с запросом в единый поток. У запроса появился один основной экран вместо разбросанных форм. В одном месте стали видны все контрагенты, документы и договоры. На каждом этапе доступны только логичные и ожидаемые действия. Пользователь теперь видит, что уже заполнено, чего не хватает и что можно сделать дальше. Это снизило количество ручных проверок и ощущение, что процесс «теряется».
Работал на стыке дизайна, продукта и бизнеса: анализировал текущее решение, участвовал
в исследованиях, предлагал продуктовые изменения и проектировал решения, которые затем валидировались через прототипы и тестирование.
Я отвечал за пересборку личного кабинета с фокусом на логику пользовательских сценариев, прозрачность процессов и снижение количества ошибок.
Моя роль
Продукт уже активно использовался, но со временем интерфейс стал запутанным. Ошибки в UX приводили к задержкам процессов, потере данных и финансовым рискам.
Платформа помогает финансировать поставки и работать с несколькими контрагентами.
В одной сделке участвуют три стороны: финансирующая компания, поставщик и покупатель.
Контекст
Роль: Product Designer
Product designer · Fintech & B2B
Личный кабинет B2B-платформы
Продуктовая логика
Исследование
Прототипирование
Проектирование
