Автор статьи описывает процесс проектирования интерфейса для сервиса анализа звонков отдела продаж. Система распознает аудио, делит его на реплики клиента и менеджера, проверяет разговор по чек-листу и формирует итоговую оценку. Задача дизайнера заключалась в том, чтобы превратить пять плотных слоев неструктурированных данных в экраны, которые руководитель может осмыслить за минуту. Ключевые ограничения: панель открывается между встречами, объем текста велик, а модель оценки иногда ошибается, требуя от интерфейса возможности аргументированного спора. Данные включают метаданные, аудио, транскрипт с таймкодами, результаты проверки чек-листа и свободный текст разбора модели.
Структура карточки звонка выстроена вокруг логики использования данных. Транскрипт размещается в колонке-доказательстве, так как именно к нему возвращаются при споре с оценкой. Чек-лист и анализ занимают правую часть экрана. Тип звонка (первичный или повторный) вынесен в шапку рядом с длительностью, так как от этого зависит набор пунктов проверки. Статусы пунктов чек-листа делятся на три состояния: пройден, не пройден и «оценка есть, объяснение еще считается». Чтобы не заставлять пользователя ждать полной обработки, статус приходит раньше детального объяснения, которое имеет собственное состояние загрузки. Реплики визуально разделены цветом: красный для клиента и синий для менеджера, с дублирующими подписями для ясности.
Разбор модели, представленный в виде свободного текста, был разложен на именованные поля: суть, договоренности, ошибки менеджера и рекомендации. Каждое поле имеет фиксированное место, а рекомендации содержат цитату клиента и таймкод для быстрого поиска в оригинальной записи. Внизу карточки расположена строка истории звонков, показывающая количество контактов, входящие/исходящие вызовы и средний балл, что позволяет руководителю оценивать текущий звонок в контексте всей сделки. Самый плотный элемент интерфейса — тепловая матрица «оператор × пункт чек-листа», где строки сортируются по среднему баллу, а ячейки окрашиваются в зависимости от результата проверки.
Визуализация в матрице опирается на четкое различие между нулем (пункт проверялся и не выполнен) и null (пункт не встречался в разговоре), чтобы не вводить в заблуждение. Значения кодируются в несколько дискретных цветовых категорий, а не плавный градиент, так как на темном фоне глаз лучше различает четкие оттенки. Также на дашборде используются карточки метрик с цветовой кодировкой по смыслу (красный для потерь, зеленый для роста), а не по направлению дельты. Обязательным элементом является подпись сравнения с прошлым периодом, без которой цифры теряют смысл.
Техническая реализация дизайна началась с выгрузки токенов из Figma. В макетах использовались девять стилей и два компонента, но при экспорте в CSS-переменные возникла проблема: из файла лендинга вместе с собственными переменными были выгружены 431 слой референсов из чужих макетов. В итоговой выгрузке оказалось 217 переменных, из которых 51 использовалась хотя бы один раз. Автор принял решение использовать только семантические псевдонимы и примитивы, отбросив лишнее. Цветовая палитра построена на белом с разной прозрачностью вместо серых оттенков, а обводки реализованы через внутренние тени, чтобы не сдвигать элементы при изменении границ. Типографические токены собраны в один шорткат, объединяющий начертание, размер и интерлиньяж.
