ТБанк
Цель задания состояла в том, чтобы создать удобный интерфейс для операторов колл-центра, который позволит им легко и быстро назначать встречи с клиентами, оставившими заявки на получение карты. Важно было учесть несколько ключевых функций: возможность консультировать клиента, просматривать и редактировать его адреса, а также управлять микрофоном во время разговора.
Чтобы получить банковскую карту, нужно оставить заявку на сайте или по телефону.
Как только карта готова, оператор созванивается с клиентом и назначает встречу клиента с курьером. Карту могут привезти домой, на работу или в удобное клиенту место и время
Среднее время обработки (AHT – англ. average handling time)
Показатель потерянных заявок (AAR – англ. average abandonment rate)
Индекс контроля качества (QA – англ. quality assurance)
Длительность звонка
Я, как оператор, могу:
проконсультировать клиента по оформленному продукту
увидеть рабочий/домашний адрес клиента для назначения встречи или добавить новый
выключить микрофон
назначить встречу
Для меня процесс — это не строгое руководство, а скорее набор инструментов, которые можно адаптировать под конкретную задачу. В этой задаче определил основные этапы: исследование, анализ, проектирование и тестирование.
Провести интервью с операторами колл-центров не получилось, хотя очень хотелось, так как их проблематично найти. Поэтому я решил изучить ситуацию по-другому: читал статьи о работе операторов, узнал, как оценивают их работу и что включает их рабочий день. Также посмотрел видеообзоры существующих интерфейсов для колл-центров, чтобы лучше понять их потребности и сделать эффективное решение
Разработал информационную архитектуру, основываясь только на ТЗ. Выписал все существительные из задания, которые могут быть связаны с интерфейсом. В итоге получалась такая информационная архитектура.
Когда работал над CJM, старался смотреть на задачу шире: понять все процессы, которые проходят за рамками интерфейса, и кто в них участвует. Я также обозначил ограничения, которые могут помешать пользователю следовать по пути, и добавил шаги, возвращающие пользователя обратно в сценарий. В процессе определил возможные действия на пути пользователя и выделил те шаги, которые относятся именно к интерфейсу
Когда приступаю к проектированию, всегда начинаю с создания вайрфреймов. Это помогает сосредоточиться на композиции и логике интерфейса, не отвлекаясь на детали дизайна. Таким образом, я могу сначала выстроить структуру и логику взаимодействия с интерфейсом, а уже потом переходить к визуальному оформлению.
Главный экран
Первый экран представляет собой список заявок, где оператор может быстро находить нужные с помощью поисковой строки и фильтров. Заявки разделены по вкладкам, что помогает быстрее ориентироваться в текущих задачах. У каждой заявки свой ID, чтобы можно было легко найти нужную.
Информация о клиенте
Оператор может просматривать информацию о заявке, не переходя на другую страницу. Экран делится на три части, чтобы вся нужная информация была на виду. В одной части — список заявок, в другой — детали о клиенте, в третьей — детали о продукте. В блоке с информацией о продукте есть карта, которая показывает, входит ли адрес клиента в зону доставки.
Процесс звонка
В процессе звонка появляется небольшая плавающая панель, которую можно перемещать по экрану, чтобы оператор мог держать её перед глазами. В панели оператор может управлять звонком: ставить на паузу, выключать микрофон, завершать звонок. Также предусмотрена функция для быстрого доступа к скрипту звонка, который можно заранее подготовить в личном кабинете и выбрать нужный во время разговора. Это может помочь оператору выполнять несколько задач без лишних переключений.
Так выглядит попап с возможностью отправки сообщений клиенту и попап для назначения встречи. Оператор может сверить данные, которые ввел во время звонка, и сразу назначить курьера.
Сделал прототип для основного сценария назначения встречи. Можно потыкать и посмотреть, как всё работает на практике — от списка задач до назначения встречи. Все элементы интерактивные, так что можно понять, как будет ощущаться интерфейс, когда оператор реально начнёт им пользоваться.
Потрогать прототип можно тут: Кликабельный прототип
Протестировал интерфейс, чтобы убедиться, что всё работает так, как задумано, и операторам будет удобно пользоваться системой. Провёл 20 немодерируемых юзабилити-тестирований. В итоге 18 респондентов успешно справились с заданием, 2 столкнулись с трудностями. Это показало, что интерфейс в целом интуитивен, но есть моменты, которые можно доработать для улучшения опыта пользователей.
Иногда приходится проектировать интерфейсы сложных систем, вроде внутренних корпоративных продуктов, где не так просто найти подходящие референсы. В таких ситуациях помогает работа с информационной архитектурой и CJM. Они помогают разложить весь процесс по полочкам, посмотреть на него целиком. Это особенно важно, когда нужно учитывать множество шагов и ролей в продукте.
Еще один момент — не всегда есть возможность провести интервью с пользователями. Тут приходят на помощь открытые исследования. Читаешь статьи, смотришь видео, изучаешь, как устроены существующие системы, и это уже дает довольно хорошее представление о том, что нужно пользователю.
Результаты тестирования показали, что интерфейс работает неплохо: большинство респондентов справились с заданиями. Но остались нюансы, которые требуют доработки, чтобы интерфейс стал еще более удобным.
