О продукте
Рабочее место оператора для омниканальной коммуникации с клиентами — это единое рабочее пространство для общения с клиентами в web, desktop и mobile.
Рабочее место оператора объединяет все основные каналы коммуникации с клиентом в одном интерфейсе: текстовые сообщения, звонки и историю взаимодействия.
Цель продукта — предоставить оператору единое пространство для обработки обращений независимо от канала связи и устройства.
Кросс-платформенное рабочее место со всеми текстовыми и голосовыми каналами для общения с клиентом в едином интерфейсе.
С помощью него оператор может:
  • Совершать и принимать звонки
  • Переписываться с клиентами из любого мессенджера
  • Обрабатывать все входящие заявки
Ссылка на Десктоп версию в Figma >>
Ссылка на Мобильную версию в Figma >>
Контекст продукта
К моменту начала проекта продукт уже существовал на всех трёх платформах.
Однако каждая из них развивалась отдельно:
  • отличались сценарии работы;
  • интерфейсы были устроены по-разному;
  • пользовательский опыт постепенно расходился.
Дополнительно накопились проблемы внутри самих интерфейсов.
Поэтому задача состояла не просто в редизайне отдельных экранов, а в переосмыслении рабочего места оператора как единой системы.
Цели
Перед проектом стояли три основные цели.
1. Унифицировать пользовательский опыт
Пользователь должен одинаково понимать интерфейс независимо от платформы.
2. Учесть особенности каждой среды
Desktop, web и mobile имеют разные ограничения и разные сценарии использования. Необходимо было сохранить общую логику продукта, адаптируя взаимодействие под особенности платформы.
3. Развить дизайн-систему
Существующая дизайн-система поддерживала web и desktop. Необходимо было адаптировать её для мобильного приложения, сохранив единый язык компонентов.
Моя роль
  • UX/UI дизайн
  • Глубинные интервью с пользователями
  • Проектирование пользовательских сценариев
  • Редизайн desktop и mobile
  • Развитие дизайн-системы: создание библиотеки мобильных компонентов на основе общих токенов
  • Прототипирование
  • Сопровождение разработки
Исследование
Перед началом проектирования я провела серию глубинных интервью с операторами контакт-центра. Исследование состояло из двух частей:
  • сначала я выясняла, как пользователи обычно работают с приложением, какими функциями пользуются чаще всего, что вызывает затруднения и каких возможностей им не хватает;
  • затем предлагала участникам пройти ключевые рабочие сценарии и рассказать, как они решают эти задачи сейчас.
Дополнительно я проанализировала обратную связь по существующим решениям и конкурентные продукты.
На основе полученных данных я выделила ключевые пользовательские сценарии, сформировала основные потоки и определила направления для переработки интерфейса.
Дизайн-система
Одной из задач проекта стало развитие дизайн-системы. Изначально она содержала компоненты только для web и desktop, поэтому библиотеку мобильных компонентов я собрала с нуля.
В процессе работы дизайн-система была разделена на три уровня:
  • общие компоненты;
  • desktop;
  • mobile.
Для каждого мобильного компонента я создала единый мастер-компонент. Его состояния и параметры настраивались с помощью variables — это позволило сократить количество слоёв и не увеличивать размер библиотеки. Рядом с каждым компонентом я описала и наглядно показала предусмотренные варианты его использования.
Desktop-библиотеку я также дополнила новыми компонентами для работы с чатами: баблами сообщений и элементами списка чатов. Кроме того, я переработала и пересобрала блок карточки контакта.
На всех 3 уровнях была использована одна и та же библиотека токенов.
Такой подход позволил переиспользовать общие элементы, сохранив особенности каждой платформы.
Ключевое решение 1
Разделение пространства звонков и переписки в десктопе
Проблема
В предыдущей версии десктопное приложение было построено по принципу единого окна. Софтфон находился рядом с чатами и другими разделами интерфейса.
Во время звонка оператор продолжал видеть открытый чат, из-за чего было неочевидно, относится ли текущий звонок к этому диалогу или это совершенно другой клиент.
Такое соседство разных коммуникационных контекстов создавало когнитивную нагрузку и повышало вероятность ошибок.
Решение
Я разделила рабочее пространство на два независимых окна:
  • основное окно — работа с чатами, историей, контактами и остальными разделами продукта;
  • отдельное окно софтфона — все сценарии голосовой связи, история звонков.
Так оператор мог свободно работать с сообщениями, не смешивая их визуально с текущим звонком.
Почему именно так
Звонок — это самостоятельный пользовательский контекст.
Во время разговора оператор концентрируется на голосовом взаимодействии, которое не всегда связано с тем чатом, который открыт в основном окне.
Разделение пространств сделало эту границу очевидной.
Ключевое решение 2
Настройки перестали быть разделом десктоп приложения
Проблема
Настройки были полноценным разделом приложения и открывались через основную навигацию.
Чтобы изменить параметры работы, оператор фактически покидал своё рабочее пространство.
После изменения настроек приходилось возвращаться обратно к текущей задаче.
Решение
Я вынесла настройки в отдельное окно, которое открывается из верхней панели приложения.
Теперь настройки стали вспомогательным инструментом, а не частью основного пользовательского сценария. Рабочий контекст при этом не теряется.
Почему именно так
Настройки используются эпизодически. Это не часть ежедневной обработки обращений.
Поэтому они не должны конкурировать с основными разделами приложения в навигации.
Ключевое решение 3
Адаптация софтфона под веб
Контекст
В desktop-приложении софтфон работал как отдельное окно. Благодаря этому его можно было сделать достаточно большим и разделить на две функциональные области. Правая функциональная область сворачивалась и разворачивалась при необходимости.
Такое решение хорошо подходило для десктопного приложения, где пользователь управляет несколькими окнами.
Проблема
В веб-версии такой подход был невозможен. Софтфон должен был работать внутри браузера, не перекрывая основное рабочее пространство и не занимая слишком много места.
Прямой перенос desktop-интерфейса ухудшил бы удобство работы.
Решение
Вместо двух независимых областей и большого окна софтфона, состоящего из двух частей, появился компактный интерфейс, в котором все основные сценарии были объединены в одном экране.
При этом удалось сохранить основные пользовательские действия без увеличения количества переходов.
Почему именно так
Не было задачи сделать одинаковые интерфейсы. Целью было сохранить одинаковую логику использования при разных технических ограничениях платформ. Desktop и web решают одну задачу, но делают это разными средствами.
Другие экраны
Чаты
Контакты
История
Результат
Был создан единый омниканальный интерфейс оператора, который работает в трёх средах: web, desktop и mobile.
Также была расширена дизайн-система, что позволило использовать единый набор компонентов для дальнейшего развития продукта.