Проектирование кабинета брокера на платформе TST

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

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

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

Проблемы

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

Цели

Бизнес-цель — облегчить взаимодействие брокеров с платформой и улучшить следующие показатели:

Количество сделок, проходящих через брокеров
Средняя стоимость сделки
Прибыль площадки с комиссии от сделок

Цель для пользователя (брокера):

Ускорить работу с сервисом
Увеличить прибыль с комиссии от сделок
Снизить потерю клиентов

Команда и роли

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

UX research
IA
User flows
Wireframes
UI design
Design system
States
Responsive

UX research

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

Выводы:

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

Создание IA

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

User-flow

В этом кейсе я покажу более подробно один из флоу, спроектированных мною в рамках этого проекта — «Подбор брокером выгодной для клиента сделки и заключение сделки клиентом»

Usability-тестирование

Я нарисовала экраны по данному флоу и показала готовый прототип пяти самым въедливым брокерам :)) Варфреймы не стала показывать, потому что все брокеры — люди возрастные, и с трудом воспринимают технические новшества. Готовые экраны для них более показательны.

Выводы

Пользователи попросили сделать все ссылки голубого цвета, иначе непонятно, что на них можно нажать
Если черновик сделки сброшен, должна быть возможность вернуться не просто в раздел «Сделки и заявки в работе», а к результатам поиска по конкретному клиенту
В модалку «Черновик сделки отправлен клиенту» добавить номер судебного пакета и ФИО клиента, которому уходит черновик

Final UI

Здесь я покажу ключевой экран, с которым работают брокеры — главную страницу ЛК, дашборд со всеми состояниями. Полный флоу экранов можно посмотреть в Figma

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

Интерфейс спроектирован как система независимых модулей. Это позволяет:

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

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

Таблица вынесена в нижнюю часть как основной рабочий инструмент для действий с клиентами и сделками. Блок используется уже после анализа данных — на этапе перехода к конкретным действиям.

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

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

Размер модулей отражает приоритет информации. Наиболее важные показатели (общая прибыль) занимают больше пространства и получают больший визуальный вес.

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

States

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

Loading
Использована постепенная загрузка модулей:

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

Для графиков были спроектированы скелетоны, повторяющие форму будущих данных. Это помогает пользователю быстрее распознавать тип контента и снижает ощущение ожидания.

Empty states
Пустые состояния используются как часть пользовательского сценария, а не как «мертвые» экраны.
Каждый empty state:

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

Error states
Ошибки отображаются локально внутри модулей и не блокируют работу остальных частей интерфейса.
Для каждого компонента предусмотрен отдельный сценарий:

ошибка загрузки KPI;
ошибка графика;
ошибка таблицы.

При этом:

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

Responsive adaptation

Мобильная версия была пересобрана, а не просто масштабирована из десктопа.

переработана структура KPI-карточек;
увеличен вертикальный ритм;
добавлены аккордеоны для сложных графиков и донатов;
оптимизировано отображение графиков;
быстрый доступ к ключевым действиям сохранен.

Графики свернуты

Все развернуто

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

Улучшена читаемость и упрощена работа с таблицей:

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

Блок быстрого действия переделан в небольшую модалку в нижней части экрана для того, чтобы:

оптимизировать пространство экрана и не слишком его растягивать;
не помещать рядом два оповещения — статус обновления дашборда и быстрое действие. Это создало бы лишнюю когнитивную нагрузку.

Приоритет был отдан ключевым метрикам.
Верхняя часть экрана сохраняет:

основные KPI;
фильтрацию периода;
статус обновления данных.

Это позволяет быстро оценить состояние дашборда даже при работе с мобильного устройства.

Тестирование финального UI

После проектирования финального интерфейса провела «коридорное тестирование», чтобы проверить:

понятна ли структура дашборда;
насколько хорошо читаемы аналитические блоки;
удобна ли работа с таблицей;
как воспринимается адаптивная версия;
насколько быстро брокеры проходят ключевой сценарий.

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

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

Итоги

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

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

следующий кейс

на главную