Плюсы:

• Второй проект. Не придется тратить время на «притирку» и организацию совместной работы.
• Делаем для людей. Заказчик, невзирая на технический бэкграунд, умеет и хочет разговаривать про людей, а не про профессиональные роли.
• Одна пользовательская роль. Не нужно пытаться совместить в одном интерфейсе инструменты для пользователей с разными задачами.
• Разумные требования к эстетике. Заказчик понимает, что главное в профессиональном интерфейсе — удобство и функциональность, а не креатив в угоду моде.

Минусы:

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

Процесс

Плюсы явно перевешивали минусы, а технически сложных решений мы не боимся. Первым делом приступили к изучению.

ИЗУЧЕНИЕ СИСТЕМЫ

В общем виде все выглядело так. Система берет из указанного места аудиозаписи звонков. Затем при участии пользователя проверяет записи: сверяет голос с «черным списком» и анализирует кластеры из нескольких десятков разговоров для поиска «аномалий». Кластерный анализ проводится по двум алгоритмам — для повышения точности.

1. Сравнение голоса. Каждой записи присвоен ID. Чаще всего это телефонный номер звонящего. Система берет записи с одним и тем же ID за определенный период и сравнивает голос. Если в какой-то фонограмме голос отличается, она попадает к инженеру-безопаснику — на ручную обработку.
2. Сравнение ID. Происходит по тому же принципу, что и сравнение голоса. Система отбирает звонки с одинаковым голосом и сравнивает ID. Если один и тот же голос связан с разными ID— оповещает инженера.

ПОЛЬЗОВАТЕЛИ И СЦЕНАРИИ

Как мы уже говорили, пользователь у нас один — инженер-безопасник. Это профи, готовый разбираться в системе. Заказчик предоставил нам основные сценарии использования системы, мы обсудили их и детализировали до уровня, на котором можно создавать прототипы.

ПЕРВАЯ ВЕРСИЯ

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

По эскизам мы вместе с заказчиком прошли все сценарии. Что-то уточняли и корректировали, но в целом интерфейс сложился, и мы перешли к детальному проектированию.

Выглядит простовато? Да, все так. Получилось просто. Но история на этом не закончилась.

ВТОРАЯ ВЕРСИЯ

Как мы уже говорили, продукт находится в стадии формирования. Когда смотришь не на набор букв в ТЗ, а на рабочий прототип, видение продукта меняется. В нашем случае заказчик решил, что система может функционировать сама — с минимальным участием пользователя. Администратор настраивает правила — запуск регулярных проверок, — а потом получает уведомления, если что-то идет не так. Это почти не влияет на ядро, но смещает фокус во взаимодействии — вместо того чтобы регулярно проверять задания, нужно реагировать на инциденты.

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

1. Поговорили с заказчиком про новые идеи, уточнили технические возможности. Пришли к консенсусу — для отображения инцидентов удобен формат дашборда.
2. Оформили результаты беседы в виде списка ожиданий и описания сценариев в свободной форме.

1. Обсудили с заказчиком детали и приступили к эскизному проектированию.

Принципиальное отличие видно уже на эскизах. Вместо истории проверок — история событий. Плюс краткая сводка в верхней части экрана. И логика работы инженера — не смотреть отчеты, а реагировать на события. Можно переходить к деталям и цвету.

Панель управления — основной экран — это что-то вроде ToDo-листа. Инженер открывает страницу и видит, что ему нужно сделать, какие события обработать.

Детальное проектирование профессионального интерфейса — это работа с незаметными на первый взгляд мелочами. Расскажем про них.

 

Сводный отчет по проверкам мы выполнили в виде диаграммы. В нашем примере заметных аномалий нет, и инженер не будет фокусироваться на этой части экрана. Но, если график будет неравномерным (например, произойдет внезапный скачок количества инцидентов), пользователь поймет, что случилось нечто серьезное: утечка данных, брешь в системе безопасности или иное событие, которое требует отдельного расследования.

События распределены по трем группам: сравнение с черным списком, проверка кластеров по ID и проверка кластеров по голосу. Указан статус: новое событие (без пиктограммы), в процессе проверки (часы) и обработано (галочка). Так инженер сразу видит, где еще требуется его участие, а где он уже сделал свою работу.

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

Цвет на осциллограмме показывает, где начинается и кончается голос звонящего — инженер слушает именно его. Серые участки — голос оператора, его инженеру не слышно.

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

Здесь акцент смещен на временной срез. Можно посмотреть отчет за определенный период и обработать инциденты внутри этого периода. Это актуально, когда проверки проводятся, например, не ежедневно, а раз в неделю.

Еще один сценарий — ручная проверка.

Все примерно так же, как и при автоматической проверке. Просто исходная точка другая — у нас появился новый черный список, и мы хотим проверить по нему наши старые фонограммы.

Конечно, нужен экран настроек.

Здесь стоит упомянуть про «интеграцию». Система без проблем интегрируется с любым модулем аудиозаписи — нужно лишь указать источник фонограмм. Разговоры всегда записываются в два канала: в одном — голос звонящего (его-то мы и проверяем), во втором — голос оператора контакт-центра (нас это не интересует).

При выборе источника фонограмм возможны два варианта. Первый — когда в каталоге лежит конфигурационный файл, и наша система оттуда считывает, какой канал нужно анализировать.

Второй случай — когда конфигурационного файла нет. Тогда система предложит инженеру прослушать несколько записей и указать канал вручную.

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

Мы сделали две итерации в таком дизайне и поняли: когда объем контента растет, картинка «разваливается». Что это значит? Акценты смещаются и оказываются не там, где нужно. Недостатки хорошо видны.

1. Сводка подозрительных событий (цифры в кружочках) не воспринимается как единый блок информации. Чтобы исправить это, мы расположили кружки более компактно.
2. Осциллограммы ярче графика в верхней части экрана и сразу перетягивают все внимание на себя. А должно быть так — сначала взгляд привлекает график, и, если видимых проблем нет, глаза скользят дальше по экрану. Осциллограммы не должны быть броскими, привлекать к ним внимание незачем — когда дело дойдет до работы с ними, глаз сфокусируется сам.
3. Левая панель визуально кажется более значимой, что не вполне соответствует реальному положению вещей.

Про людей

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

Но есть нюансы. Профессиональный интерфейс — продукт не одноразовый. Людей, которым он нужен, меньше, но используют его чаще и плотнее. Поэтому в идеале UX-решение надо проверять на этих реальных людях. И адаптировать под них. Сделать это один раз недостаточно. Суть в том, чтобы делать это постоянно. Выпустить продукт, получить фидбек, улучшить интерфейс или изменить его радикально.

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

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

Результат

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

Смысл

Идеи нужно визуализировать. Даже если это «всего лишь» интерфейс чисто технической системы. Нельзя сказать, что команда «Собаки Павловой» создала продукт от начала и до конца, но лапу мы приложили к этому делу. Помогли заказчику оформить свой замысел в графике и увидеть, что идеи стоящие, их можно реализовать, они не усложнят, а наоборот, упростят работу с системой.

 

Подробнее на сайте.

Перейти на сайт