Центр мониторинга группы компаний.
Укрощение Big Data.
01. ОБЗОР
Дашборд для топ-менеджмента группы компаний — это кейс, в котором небольшая инициативная команда создала инструмент, устранивший критическую проблему в скорости принятия управленческих решений.
Примечание: это внутренний продукт, поэтому мы не стали тратить время на проработку айдентики и взяли за основу нейминга ключевую фичу системы — InSight.
О продукте
InSight — это интерактивный аналитический дашборд, объединяющий метрики группы компаний в единую систему помощи принятия решений и мониторинга состояния бизнеса.
- Зачем нужен продукт: избавить топ-менеджеров от сбора статистики при помощи прямых запросов, защитить бизнес от кассовых разрывов, потери IT-льгот и других рисков.
- Главная фича: лента аномалий — система оперативных уведомлений о рисках и отклонениях, работающая на основе предиктивных паттернов.
02. МОЯ РОЛЬ
От хаоса к системе
Топы принимали решения интуитивно: единой картины бизнеса не существовало, аналитики собирали отчёты по запросу часами, а сводные данные появлялись лишь в презентациях раз в квартал, устаревая к моменту показа.
Моя задача — определить и структурировать весь массив генерируемых данных, превратив его в ежедневный рабочий инструмент для мониторинга состояния бизнеса.
Критерии успеха
Вместо того чтобы просто свести все данные в одном месте, мы спроектировали инструмент поддержки принятия решений с чёткими, измеримыми бизнес-метриками успеха:
- Скорость анализа: уменьшение времени на поиск ключевых показателей и оценку состояния бизнеса.
- Вовлеченность пользователей: рост частоты и регулярности использования продукта руководителями.
- Экономия ресурсов: сокращение операционных затрат и высвобождение ресурсов компании.
Time-to-Data -71%
Сокращение времени на обнаружение метрики в интерфейсе по сравнению с работой в отчётах, благодаря поиску и навигации.
Time-to-Insight -59%
Сокращение времени от момента открытия источника данных до обнаружения аномалии или рисков, благодаря системе инсайтов.
Operational Load -44%
Сокращение числа запросов к аналитикам со стороны топ-менеджеров по вопросам сбора и представления данных о работе компании.
User Engagement ×3
Повышение частоты использования продукта, по сравнению со старым форматом работы. Превращение продукта в ежедневный инструмент.
Примечание: время сравнивали на одних и тех же задачах в дашборде и старом табличном формате работы.
3. КЛЮЧЕВЫЕ ВЫЗОВЫ
Хочу видеть всё на одном экране
В чём была сложность:
Менеджеры требовали уместить на одном экране гигабайты данных по 15 продуктам и нескольким компаниям. Перенос метрик «в лоб» создал бы перегруженное «кладбище графиков», где поиск рисков и проблем занимал бы слишком много времени.
Как я это решил:
Я поставил под сомнение запрос «видеть всё и сразу» и выявил истинную боль руководства: потребность фокусироваться на угрозах и точках роста. Так родилась идея ленты аномалий и системный подход к приоритизации данных: от триггеров к деталям.
Ограниченность ресурсов разработки
В чём была сложность:
Задача требовала максимального сокращения Time-to-Market при ограниченном ресурсе бэкенд-разработки. Поэтапный подход к UI (верстаем только то, что уже отдаёт бэкенд) нёс в себе риски: каждый новый контракт API порождал бы новый виджет и заставлял бы фронтов заново пересобирать сетку, адаптивность и логику экранов. В итоге команда увязла бы в бесконечном рефакторинге, а запуск первой версии отложился бы на неопределенный срок.
Как я это решил:
На этапе Discovery мы спроектировали подробный базовый вижен дашборда с возможностями дальнейшего масштабирования на основе фидбека.
Чтобы не пересобирать вёрстку с каждым спринтом, я предложил задеплоить текущий вариант интерфейса сразу целиком: готовые блоки наполнялись данными, а неготовые закрывались заглушками «В разработке». Это позволило запустить продукт раньше и подключать новый функционал бесшовно для пользователей.
Что это дало:
04. Исследования
Сбор данных
Масштаб проекта требовал тщательного анализа данных. Чтобы систематизировать их состав, источники и структуру, мы разделили исследование на три этапа:
Аудит и категоризация метрик дирекций
Собрали полный список операционных и финансовых данных из четырёх основных дирекций (Продуктовой, Коммерческой, Технической и Сервисной). Это позволило составить первичный общий список метрик.
Глубинные интервью с менеджерами
Провели серию сессий с руководителями для определения управленческих сценариев. Оценили реальный контекст принятия ежедневных решений, получили данные для этапа приоритизации.
Синтез и приоритизация (Mindmap)
Очистили массив данных от дублей, систематизировали по смысловым блокам и свели в единую сквозную карту, зафиксировав состав и иерархию показателей с бизнесом.
Карта метрик стала визуальным контрактом между бизнесом и дизайном. На её основе мы расставили приоритеты и связали данные с реальными сценариями — от мгновенной оценки ситуационной картины до глубокой детализации отдельных операций.
Утверждение единой структуры данных на этапе Mindmap устранило неопределенность. Команда разработки получила требования к интеграциям, а команда Discovery — основу для будущего интерфейса.
Глубинные интервью CustDev
Топ-менеджмент был открыт к диалогу, но серьёзно ограничен во времени. Чтобы не отвлекать руководителей повторными уточнениями, мы тщательно планировали каждую встречу и собирали максимум инсайтов за одну сессию.
Подготовка
Чтобы получить максимум ценности за короткую сессию, мы сместили основной фокус на этап предварительной подготовки, который проходил в три этапа:
- Изучение контекста — подготовили аналитическую базу и артефакты для проведения интервью и карточных исследований.
- Формирование гипотез — зафиксировали конкретные предположения, чтобы проверить их на встречах.
- Проработка вопросов — составили выверенный список вопросов, фокусирующий стейкхолдеров на определённых сценариях.
Респонденты
Мы провели 14 глубинных интервью (каждое по 60–90 минут), разделив респондентов на четыре сегмента:
- Финансовый блок — СЕО, CFO, бухгалтерия.
- Управление разработкой — CPO, продакты команд.
- Технический юнит — CTO, техлиды направлений.
- Сервис и поддержка — Head of HR, руководитель сервисной дирекции.
Вопросы и
структура
CustDev-исследование строилось вокруг трёх задач проектирования:
- Триггеры и управленческие сценарии: определение алгоритмов принятия решений для проектирования логики инсайтов.
- Сквозной контекст и кросс-доменные связи: выявление смежных метрик для проектирования бесшовных аналитических сценариев.
- Валидация гипотез и ментальных моделей: проверка предположений о KPI, структуре данных и привычных паттернах поведения для синхронизации UI с реальными процессами топов.
Гипотезы
Не все данные нужны сразу
Подтверждена
Топам не нужно видеть все данные на одном экране, информацию лучше группировать и подавать порционно. Потребность видеть всё сразу часто продиктована ложным ощущением контроля. Но задача руководителя не в том, чтобы постоянно просматривать весь массив данных. Его задача — быстро замечать угрозы, риски и возможности.
Алерты во внешних каналах
Не подтверждена
Руководителям удобно получать уведомления через внешние мессенджеры (Telegram, Slack), чтобы всегда быть в курсе текущей ситуации с бизнесом.
Реальность: мессенджеры топов перегружены. Внешние алерты теряются в потоке сообщений и только раздражают. Работа топа — это стратегический анализ, а не сиюминутное тушение пожаров по пушам в телеге.
Доверие к готовым выводам
Подтверждена
Топ-менеджерам часто не хватает времени на анализ сырых данных, поэтому умная лента инсайтов, которая подсвечивает аномалии и готовит выводы, поможет быстрее находить важное. При этом ценность и доверие к таким инсайтам напрямую зависит от точности и прозрачности первопричин.
Барьер «сырого продукта»
Не подтверждена
Любой блок «В разработке» будет восприниматься топами как системный сбой, обнуляя доверие ко всему дашборду и они не будут им пользоваться.
Реальность: топ-менеджеры оказались прагматичнее, чем мы ожидали. Их не смущают заглушки «В разработке».
Инсайты
Настройка контекста
Верхнеуровневые цифры вроде «доходов за месяц» сами по себе не помогают принимать решения. Руководителю важно быстро детализировать данные по направлениям, периодам и источникам, чтобы видеть реальную картину в своей зоне ответственности.
Пассивный контроль
Половина сессий топ-менеджеров — это быстрый «чекап», чтобы убедиться, что всё в порядке. Поэтому для продукта крайне важна скорость считывания статуса системы: интерфейс должен мгновенно показать, что всё работает без происшествий.
Поиск точек роста
Руководителям важно не только видеть риски и проблемы, но и находить новые возможности, рассматривая данные под разными углами. Дашборд, сфокусированный только на проблемах, теряет часть возможной полезности.
Фокус на драйверах
В большинстве показателей есть 5–7 явных лидеров, которые определяют основной фокус интересов. Поэтому на основных страницах есть смысл ограничить таблицы, а полные списки выводить в подробной информации.
05. UX-РЕШЕНИЯ
Лента инсайтов
Инсайты стали главной фичей проекта. Изначально они не были частью концепции, а родились в процессе Discovery как результат исследования пользователей.
В основе работы ленты лежит алгоритм выявления аномалий: система ранжирует события по их влиянию на бизнес. Инсайты формируются на стыке трёх категорий — от критических угроз до умеренных отклонений и потенциальных точек роста.
Чтобы лента оставалась инструментом для принятия решений, а не превращалась в неконтролируемый поток уведомлений, мы предусмотрели гибкую систему настройки. Руководитель может регулировать порог чувствительности алгоритма, определяя, какие аномалии заслуживают внимания, а также выбирать типы сигналов, которые будут отображаться в ленте — от предиктивных трендов до операционных отклонений.
Лента инсайтов стала сквозным паттерном для всего продукта. Иерархия экрана выстроена вокруг сценариев руководителя: сначала глобальные фильтры, задающие контекст, затем основные KPI, а сразу под ними — инсайты, требующие внимания.
Под капотом работает ML-модель, которая непрерывно обучается на данных, а алгоритмы выявления аномалий постоянно дополняются новыми паттернами — на основе обратной связи и работы аналитиков.
Один контекст вместо разрозненных фильтров
Для эффективной работы с большими объёмами информации мы создали систему фильтров, которая позволяет динамически изменять срезы данных, сохраняя целостность общей картины.
Проблема: отдельная настройка фильтров
Топы привыкли работать с большими массивами данных в десятках аналитических таблиц. В каждой из них можно отдельно сортировать и фильтровать показатели, но перенос этой механики на каждый виджет в интерфейсе привёл бы к избыточной сложности.
На практике руководители обычно работают с одним срезом данных: например, анализируют один период, направление или продукт. Разные фильтры для отдельных блоков создавали бы несогласованный контекст, увеличивали количество действий и со временем превращали экран в набор хаотичных данных.
Решение: единый блок фильтров
Мы заменили точечную фильтрацию каждого виджета на единый глобальный блок фильтров для всей страницы. Одно действие пересчитывает весь контекст экрана, сохраняя привычную глубину анализа.
Однако такой подход имеет компромисс: при работе с большими объёмами данных появляется небольшая задержка пересчёта. Мы сознательно приняли этот trade-off, так как сокращение количества действий и единый согласованный срез данных дают пользователю больше ценности, чем мгновенное обновление отдельных блоков.
Эволюция концептов на примере виджета P&L
Изначально мы рассматривали классический подход с двумя отдельными графиками доходов и расходов. В процессе итераций пришли к компактному формату, который сразу подсвечивает итоговый результат и раскрывает его структуру.
Два отдельных графика для доходов и расходов
Такой вариант увеличивает когнитивную нагрузку, разрывает контекст и занимает вдвое больше места на дашборде. Пользователю приходится самостоятельно сопоставлять доходы и расходы, чтобы оценить рентабельность.
Единый график для показателя рентабельности
Вместо графиков доходов и расходов показываем график рентабельности. Система автоматически считает маржинальность и прибыль, при этом детализация состава доходов и расходов доступна при наведении на отдельные элементы графика.
График динамики P&L
с детализацией структуры
Тот же график рентабельности, но с наглядным соотношением доходов и расходов. Такая детализация помогает менеджеру быстрее оценивать структуру показателей, видеть изменения и находить нужные данные.
Итоговый дизайн
В финальной версии добавили цветовую индикацию, которая помогает сразу замечать периоды с отрицательной рентабельностью. Помимо этого добавили возможсность переключаться между рентабельностью и прибылью.
Триггеры вместо таблиц
В разделе партнёрской сети продолжили следовать инсайтам, полученным на интервью. Вместо одной большой таблицы с разными вкладками мы создали виджеты, которые выделяют наиболее значимые показатели и изменения.
Исходные данные партнёрской сети были представлены исключительно в виде таблиц: списки клиентов, партнёров, центров продаж и другие массивы информации. Очевидный подход — просто вывести эти таблицы на экран и дать менеджеру самостоятельно искать нужные показатели.
Но анализ сценариев работы показал, что менеджеру чаще важны не отдельные записи, а общая картина: сколько клиентов ушло за период, как этот показатель изменился относительно прошлого периода и какой тренд формируется. Поиск конкретного клиента в списке отвалившихся клиентов — скорее исключительный сценарий, который возникает значительно реже.
Поэтому вместо прямого отображения таблиц мы создали виджеты, которые сразу показывают значимую информацию: количество отвалов за период, динамику, тренд и график изменений. При этом пользователь может настроить необходимые срезы — период, продукт, партнера и другие параметры — а при необходимости перейти к полной таблице с детализацией.
Такой подход позволил перенести фокус с поиска данных на их анализ: менеджер быстрее понимает ситуацию, замечает изменения и принимает решения, не погружаясь в излишние подробности.
Динамические акценты
Как и в предыдущих UX-решениях, активность партнёрской сети мы показываем не через таблицы, а более наглядно. В данном случае наиболее эффективный формат это карта.
По умолчанию карта остаётся сдержанной и не перегружает пользователя лишними цветовыми акцентами. Это позволяет спокойно изучать данные по интересующему региону, не отвлекаясь на показатели, которые не нужны в текущем сценарии.
Когда появляется необходимость оценить активность партнёрской сети, пользователь в один клик включает соответствующий слой. Карта сразу выделяет проблемные зоны и регионы с просевшими показателями, помогая быстро понять, где ситуация требует внимания.
Что это даёт: интерфейс подстраивается под задачу, не утомляет при ежедневном мониторинге и по одному клику показывает ситуацию по регионам, сокращая время оценки активности партнёрской сети.
06. UX-ТЕСТЫ
Принципы проверки гипотез
Мы не тестировали всё подряд. UX-тестирование подключали там, где оно могло существенно повлиять на решение — и при этом оправдывало затраты времени команды и менеджеров. Принципы, которые определяли, что, когда и как мы проверяли:
В первую очередь проверяем гипотезы, которые критически влияют на продуктовый сценарий или управленческие решение.
Тестируем, если:
- Ошибка дорого обойдется.
- Есть несколько решений.
- Не хватает контекста.
Задача: снять неопределённость перед критическим решением, а не найти максимум проблем.
Перед тестом формулируем одну основную гипотезу и определяем, какое наблюдение подтвердит или опровергнет её.
Что готовим:
- Сценарий решения задачи.
- Два прототипа к A/B тесту.
- Метрики и критерии успеха.
Задача: быстро получить ответ на главный вопрос, а не пытаться охватить все смежные сценарии.
Готовим проработку прототипа в зависимости от цены ошибки и необходимых данных.
Уровни подготовки прототипа:
- Без лишних анимаций: проверяем логику сценария.
- Детальный: оцениваем опыт взаимодействия в целом.
Задача: собрать достаточный прототип, а не тратить время на избыточные детали.
Такой подход позволил адаптировать формат тестов под конкретную задачу и валидировать основные гипотезы без избыточных исследований.
Поскольку это был проект, который мы запускали по своей инициативе, я решил использовать возможность и попробовать новый для себя инструмент — ProtoPie. Мне было интересно разобраться, какие преимущества он может дать по сравнению с прототипированием в Figma.
Я собрал в ProtoPie несколько интерактивных прототипов и в процессе пришёл к довольно простому выводу: он действительно хорошо подходит для высокодетализированных интерактивных прототипов, особенно на мобилках. Но для desktop-интерфейсов преимущества уже не настолько очевидны. Во многих случаях Figma оказывается даже удобнее и быстрее — особенно благодаря состояниям компонентов.
В итоге ProtoPie не стал обязательной частью процесса, но помог лучше понять, в каких задачах инструмент действительно оправдан. Уже в следующем кейсе мобильного приложения Unisoul я применил этот опыт, создав прототип, максимально приближенный к реальному опыту использования продукта: с тактильным фидбеком, валидацией полей, сложными анимациями, уведомлениями, голосовым помощником и распознаванием речи прямо в прототипе.
07. ИЗМЕРЕНИЕ ЭФФЕКТА
Отслеживаем результаты
Поскольку это внутренний продукт, его ценность измеряется не привычными продуктовыми метриками, а эффективностью управленческих процессов и экономией ресурсов компании. Поэтому мы применили два направления оценки:
Скорость и эффективность процессов
Сравнили выполнение одних и тех же задач в новом дашборде и прежнем табличном сценарии, исключив техническое время подготовки данных и выгрузок. На очных UX-тестах с таймером замерили две метрики: Time-to-Data — время поиска нужного показателя, и Time-to-Insight — время от открытия экрана до выявления возможной проблемы и принятия решения.
Вовлечённость и автономность топов
Частоту использования до релиза оценили через опрос руководителей: фиксировали, как часто они системно работали с таблицами. После релиза сравнили с фактической частотой использования дашборда. Экономию времени аналитиков оценили по задачам из Jira: сравнили обращения от топов за прошлый квартал с аналогичными задачами текущего квартала.
Какие цифры получили
Чтобы оценить эффект от внедрения продукта, мы сопоставили показатели работы топ-менеджеров до и после запуска дашборда в течение квартала после его релиза.
Было
Таблицы и отчёты
57 сек — среднее время на обнаружение искомого показателя.
11 мин 48 сек — среднее время на обнаружение риска и принятие решения.
84 ч/мес — среднее время аналитиков на поддержку запросов топов.
6–8 дней/мес — использование таблиц для рабочих задач.
Стало
Дашборд руководителя
17 сек — среднее время на обнаружение искомого показателя.
4 мин 52 сек — среднее время на обнаружение риска и принятие решения.
47 ч/мес — среднее время аналитиков на поддержку запросов топов.
20–22 дней/мес — использование дашборда для рабочих задач.
08. ЗАКЛЮЧЕНИЕ
Финальные мысли
Проект получился невероятно драйвовым: редкий случай, когда инициатива снизу получила полную поддержку руководства. Доверие топов зарядило команду выложиться на максимум и создать продукт, который изменил работу с данными в компании.
Чему научился:
- Получил опыт работы с топ-менеджментом и понимание бизнес-управления, что позволило говорить с бизнесом на одном языке.
- Освоил создание высокодетализированных прототипов в ProtoPie и их применение в UX-тестах, чтобы валидировать гипотезы и оценивать пользовательский опыт до начала разработки.
- Усилил экспертизу в работе с большими объёмами данных — от приоритизации и категоризации до выстраивания понятной информационной структуры.
Что бы сделал иначе:
- Не ограничивал бы целевую аудиторию топ-менеджментом на первых этапах. Хотя первоначально команда целилась только в топ-менеджмент, но на практике высокий интерес к продукту проявили и руководители среднего звена, из-за чего пришлось пересматривать ролевую модель. Даже в узконаправленных продуктах целевую аудиторию важно проверять, а не определять только на основе гипотез команды.
