Проектирование кабинета брокера на платформе TST
следующий кейс
на главную

Цифровая платформа TST — сервис купли-продажи недействующих таймшер-сертификатов (Лотов)


Сертификат дает владельцу право на клубный отдых в Италии и Испании. Но многие клубы оказались недобросовестными и держатели сертификатов потеряли свое право на отдых. Платформа TST предоставляет более чем 120 тысячам владельцев таких сертификатов (Лотов) возможность вернуть вложенные средства.


Площадка получает комиссию от сделок, совершаемых клиентами — купля/продажа Лотов, инвестиции и аукционы. Брокеры предлагают клиентам сгенерированные системой варианты сделок на площадке («черновики сделок») и оказывают помощь в их оформлении.


Проблемы
  1. Брокерам сложно отслеживать активность клиентов
  2. Скорость обработки клиентов очень низкая из-за того, что брокеры работают в excel-файлах
  3. Брокеры практически не имеют доступа к аналитике
  4. У брокеров нет налаженного канала общения с клиентами, они тратят много времени на то, чтобы с ними связаться

Цели
Бизнес-цель — облегчить взаимодействие брокеров с платформой и улучшить следующие показатели:
  • Количество сделок, проходящих через брокеров
  • Средняя стоимость сделки
  • Прибыль площадки с комиссии от сделок
Цель для пользователя (брокера):
  • Ускорить работу с сервисом
  • Увеличить прибыль с комиссии от сделок
  • Снизить потерю клиентов

Команда и роли
В рамках этого кейса, работая в команде с младшим дизайнером, я участвовала во всех этапах работы:
  • UX research
  • IA
  • User flows
  • Wireframes
  • UI design
  • Design system
  • States
  • Responsive

UX research
Я опросила 10 человек брокеров, которые активно работают на площадке. До разработки личного кабинета они пользовались таблицами excel для хранения информации и обмена ею с коллегами и клиентами. Это было очень медленно и трудоемко.
Выводы:
  1. Необходимо создать общую базу данных по всем клиентам площадки
  2. Должна быть возможность чата с клиентами, коллегами и специалистами техподдержки
  3. Внедрение алгоритма, который будет автоматически просчитывать выгодные сделки и предоставлять их брокерам в качестве черновиков
  4. Возможность добавлять клиентов в избранное и назначать им статусы
  5. Возможность просмотреть собственный баланс и количество комиссионных от каждой сделки
  6. Генерация и подписание договоров с помощью электронной подписи прямо на площадке


Создание IA
Резюмировав результаты интервью, я определила все сущности, необходимые для кабинета брокера. Собрала эти сущности и все действия, которые можно с ними совершить, в следующую схему:
User-flow
В этом кейсе я покажу более подробно один из флоу, спроектированных мною в рамках этого проекта — «Подбор брокером выгодной для клиента сделки и заключение сделки клиентом»
Usability-тестирование
Я нарисовала экраны по данному флоу и показала готовый прототип пяти самым въедливым брокерам :)) Варфреймы не стала показывать, потому что все брокеры — люди возрастные, и с трудом воспринимают технические новшества. Готовые экраны для них более показательны.
Выводы
  • Пользователи попросили сделать все ссылки голубого цвета, иначе непонятно, что на них можно нажать
  • Если черновик сделки сброшен, должна быть возможность вернуться не просто в раздел «Сделки и заявки в работе», а к результатам поиска по конкретному клиенту
  • В модалку «Черновик сделки отправлен клиенту» добавить номер судебного пакета и ФИО клиента, которому уходит черновик
Final UI
Здесь я покажу ключевой экран, с которым работают брокеры — главную страницу ЛК, дашборд со всеми состояниями. Полный флоу экранов можно посмотреть в Figma
Основной фокус дашборда — быстрое считывание ключевых показателей, удобная работа с клиентскими данными и устойчивость интерфейса в разных сценариях: загрузка, пустые состояния, ошибки и фильтрация.
Структура построена так, чтобы пользователь сначала видел изменения по бизнес-показателям, а затем переходил к аналитике и работе с клиентами.
Интерфейс спроектирован как система независимых модулей. Это позволяет:
  • обновлять данные частично;
  • локально отображать ошибки;
  • не блокировать весь интерфейс при загрузке одного компонента.
Брокеры регулярно возвращаются к одним и тем же клиентам.
Поэтому был добавлен отдельный блок избранных пользователей для быстрого доступа к приоритетным сделкам и контактам.
Таблица вынесена в нижнюю часть как основной рабочий инструмент для действий с клиентами и сделками. Блок используется уже после анализа данных — на этапе перехода к конкретным действиям.
Графики сгруппированы в центральной части экрана, чтобы пользователь мог быстро сравнивать динамику между разными типами данных.
  • Линейные графики для отображения динамики и трендов во времени, так как позволяют быстро замечать пики, падения и повторяющиеся паттерны.
  • Кольцевые диаграммы для отображения распределения долей между объектами и помогают быстро оценивать структуру портфеля.
  • Столбчатые диаграммы подходят для сравнения показателей между периодами и категориями.
Размер модулей отражает приоритет информации. Наиболее важные показатели (общая прибыль) занимают больше пространства и получают больший визуальный вес.
В верхней зоне размещены основные показатели для мониторинга состояния портфеля и активности клиентов.
Так же добавлен блок быстрого действия, кликнув на который, брокер может сразу начать работу с черновиками сделок или запросом конкретного клиента.
States
Для всех экранов была спроектирована полноценная система состояний интерфейса.
Это позволило обеспечить устойчивую работу при загрузке данных, ошибках и пустых сценариях.
Loading
Использована постепенная загрузка модулей:
  • KPI появляются раньше графиков;
  • каждый блок загружается независимо;
  • пользователь может взаимодействовать с интерфейсом до полной загрузки страницы;
  • для указания на процесс загрузки применяется анимация мерцания.
Для графиков были спроектированы скелетоны, повторяющие форму будущих данных. Это помогает пользователю быстрее распознавать тип контента и снижает ощущение ожидания.
Empty states
Пустые состояния используются как часть пользовательского сценария, а не как «мертвые» экраны.
Каждый empty state:
  • объясняет причину отсутствия данных;
  • показывает следующий возможный шаг;
  • сохраняет структуру интерфейса.
Error states
Ошибки отображаются локально внутри модулей и не блокируют работу остальных частей интерфейса.
Для каждого компонента предусмотрен отдельный сценарий:
  • ошибка загрузки KPI;
  • ошибка графика;
  • ошибка таблицы.

При этом:
  1. Размер карточки сохраняется при ошибке загрузки
  2. Повторная загрузка доступна без обновления страницы и выполняется для конкретного модуля
  3. Для компактных KPI используется иконка повторной загрузки вместо кнопки для экономии пространства.
Тестирование окончательного варианта UI
После внесения правок в макеты я вновь показала флоу брокерам и все отметили, что интерфейс стал более понятным и простым для освоения

Итоги
Работая в файлах excel, брокеры успевали обрабатывать в среднем 5 клиентов в день. После двух месяцев работы с личным кабинетом средний показатель достиг 8,5 клиентов в день. Так же увеличилось количество заключенных сделок в месяц и, соответственно, комиссия брокеров.


Спасибо за просмотр!
Ксения Перова
+7 (915) 124 09 22
ksuwarlock@gmail.com
Telegram

следующий кейс
на главную