СИЗАР, запись и аналитика разговоров
B2B-система записи и аналитики разговоров для контроля качества. Спроектировал продукт с нуля: журналы, фильтры, карточку разбора и словари. Макеты ушли в разработку без переработки логики, продукт продан заказчику.
Задача
Служба контроля качества и служба безопасности оценивают работу оператора сразу по нескольким параметрам: что он говорил, что делал на экране, следовал ли скрипту.
Раньше эти данные лежали порознь: запись звонка отдельно, видео с экрана отдельно. Чтобы разобрать один спорный разговор, проверяющий собирал материалы вручную и сопоставлял их сам.
Продукт собрал эти потоки в один инструмент разбора. Проверяющий не ищет запись, он собирает доказательство. Отсюда два требования к структуре: быстро отобрать нужные разговоры из тысяч и разобрать конкретный без потери контекста.
Единый паттерн журналов
В системе четыре разных объекта: сессия сотрудника, обращение, звонок, активный звонок. Сценарий один: отобрать, открыть, разобрать.
Свёл их к общему паттерну: счётчик записей, таблица, фильтр, переход в карточку. Модули отличаются составом колонок, но не логикой. Это дало предсказуемость при переходе между разделами и сняло с команды четыре независимых раздела в разработке.
Фильтры: гибкость важнее компактности
Запрос проверяющего это пересечение условий: период, сотрудник, номер, тип обращения, статус записи, плюс несколько временных интервалов сразу. Инлайн-фильтры в шапке таблицы такой объём не держат, модальное окно закрывает результат.
Вынес фильтры в выезжающую справа панель: вмещает любое количество условий и не перекрывает таблицу. Условия сгруппированы по логике запроса: время, участники, информация об обращении, статусы аудио и видео. Количество найденных записей показывается до применения фильтра, чтобы не закрывать панель ради проверки выборки.
Карточка обращения: всё на одном экране
Здесь разрозненные материалы сходятся в один экран. Требование бизнеса: при разборе спорного разговора видеть всё сразу, без вкладок. Переключение рвёт цепочку рассуждения, пользователь теряет момент, к которому привязана претензия.
Карточка собрана вокруг одной таймлинии: аудиодорожка, записи экранов, субтитры с таймкодами, маркеры речевой аналитики и таблица вызовов внутри обращения, с переводами и конференциями, где состав участников меняется по ходу.
Разгрузил экран не вкладками, а разделением по типу задачи: разбор конкретного момента в основном потоке, агрегаты по разговору в целом (речь и тишина, распределение реплик, перебивания, лексика) в блоке статистики ниже.
Состояния вместо happy path
Аудио, видео и аналитика приходят асинхронно и не всегда: видео загружается, номер попал в исключения записи, модуль видео не подключён у заказчика.
Если проектировать только успешный сценарий, пользователь видит пустое место и решает, что система сломана. Статусы аудио и видео вынес отдельными колонками в таблицу, доступность материала видна до открытия карточки. Внутри карточки отсутствие данных объясняется причиной. Выгрузка блокируется, пока не все записи получили финальный статус, чтобы не отдать неполный комплект материалов.
Словари: управление тем, что размечает аналитику
Словари задают, какие слова аналитика считает запрещёнными, нежелательными, обязательными и желательными. Ошибка в словаре меняет разметку тысяч обращений.
Версионирование это требование бизнеса: словарь дорабатывается новой версией, без удаления и переобучения модели. Спроектировал словарь как сущность с версиями, статусами, периодом действия и каналом анализа, а не как список слов.
Устранение дубликатов это моё предложение. При анализе загрузки из xls стало ясно: одно слово может попасть в два активных словаря разных категорий, и разметка становится непредсказуемой. Чистить файл вручную до загрузки значит перекладывать на пользователя работу системы. Вместо этого система находит дубликаты после загрузки и предлагает перенести слово в текущий словарь или оставить как есть.
Ограничения
Один дизайнер, сжатые сроки, большой объём интерфейсов. Предложил взять за основу Ant Design с визуальной кастомизацией вместо системы с нуля: готовые компоненты для тяжёлых таблиц и форм сократили время на вёрстку и тестирование и освободили ресурс под продуктовую логику.
Итог
Разбор, который раньше собирался вручную из нескольких источников, стал одним экраном с общей таймлинией. Все разделы ушли в разработку без переработки логики, продукт вышел в релиз и был продан заказчику.
Ключевым в проекте оказалась не отрисовка экранов, а решение, что считать единицей работы пользователя. Проверяющий работает не с записью, а с доказательством, и как только это стало точкой отсчёта, определились и структура журналов, и состав карточки обращения, и то, что состояния данных нужно проектировать наравне с успешным сценарием.
В системах с асинхронными данными состояния это не крайние случаи, а половина продукта. И в условиях одного дизайнера на проект решение по дизайн-системе влияет на скорость команды сильнее, чем любое отдельное интерфейсное решение.