Дашборд ресурсов – data-driven интерфейс для управления проектными командами, спроектированный для работы с большими объёмами данных и быстрого ответа на ключевые управленческие вопросы.
Рынок
РФ
Домен
FinTech
Срок
12 недель
Роль
Product designer
Руководителям проектов важно в любой момент понимать, кто и в каком объёме работает над проектом: сколько людей задействовано сейчас, как распределены команды, где используются внешние специалисты и как меняется состав ресурсов со временем.
До начала проекта эта информация была разрозненной и плохо подходила для быстрого анализа. Поэтому появилась задача собрать данные в одном месте и спроектировать дашборд «Ресурсы» – интерфейс, который помогает быстро получить общую картину и при необходимости углубиться в детали по командам и отдельным сотрудникам.
Основная аудитория дашборда – руководители проектов и направлений, принимающие решения о развитии и масштабировании команд.
Информация о сотрудниках, командах, ролях и типах занятости находилась в разных системах и не давала целостной картины. Руководителям приходилось тратить время на сбор и сопоставление данных вручную, что замедляло принятие решений.
Не было прозрачного понимания, сколько именно людей работает над проектом, как распределяются команды по типам (бизнес / ИТ) и какие подтипы команд существуют внутри ИТ-направления.
Данные имели трёхуровневую структуру (проект → команда → сотрудник), но интерфейс должен был позволять быстро переключаться между общим обзором и деталями.
Решение должно было корректно работать при увеличении количества команд и сотрудников. Дашборд должен быть удобным как для проекта с 5 командами, так и для проекта с 50+ командами и сотнями участников.
/ 01 Определил цели и критерии успеха
В начале работы я зафиксировал ключевые цели дашборда и критерии, по которым можно оценить, что решение получилось успешным.
дашборд должен быстро отвечать на ключевые вопросы руководителя;
решение должно масштабироваться под реальные объёмы данных;
должна быть возможность анализировать ресурсы как на текущую дату, так и в динамике по месяцам.
/ 02 Интерпретировал управленческие вопросы
Я выписал все вопросы, которые руководитель задаёт себе при анализе ресурсов проекта, и структурировал их в отдельной таблице.
Формальные требования не всегда отражают реальные потребности пользователя. Мне было важно понять:
какие вопросы являются ключевыми,
какие вторичными,
какие требуют мгновенного ответа, а какие – более глубокого анализа.
/ 03 Описал потребности через Job Stories
Каждый вопрос я перевёл в формат Job Stories и дополнительно описал, зачем этот ответ нужен руководителю.
Это позволило:
глубже понять мотивацию пользователя,
посмотреть на задачу с точки зрения принятия решений,
избежать проектирования «ради данных», а сфокусироваться на пользе.
/ 04 Провёл эмпатическую проверку сценариев
Я посмотрел на все Job Stories целиком и попытался смоделировать, как руководитель будет двигаться внутри дашборда: с чего начнёт, куда пойдёт дальше, в какой момент захочет углубиться в детали.
/ 05 Отобрал подходящие типы визуализации
Я провёл ресерч подходящих типов визуализации для каждой Job Story, опираясь на лучшие практики аналитических дашбордов и решений из крупных data-driven продуктов.
На основе критериев скорости, масштабируемости и аналитичности я отсеял неподходящие варианты и оставил:
KPI-карточки для моментального понимания текущих значений;
линейные графики для анализа динамики;
спарклайны и бейджи для компактного отображения трендов;
древовидную таблицу для работы с иерархией «проект → команда → сотрудник».
На основе выбранных визуализаций и пользовательских сценариев я начал прорабатывать архитектуру дашборда.
Протестировал несколько вариантов компоновки блоков, сравнивая:
порядок расположения KPI;
уровень детализации на первом экране;
место динамики,
формат отображения иерархии «проект → команда → сотрудник».
После серии драфтов сформировал финальную структуру:
Сводный KPI-блок с быстрыми показателями;
Блок динамики по выбранному периоду;
Древовидная таблица с возможностью раскрытия до уровня сотрудников.
Я описал и протестировал сценарий движения руководителя внутри дашборда – от общего обзора к деталям.
Проработал:
глобальные фильтры (проект, роль, компетенция);
переключение отчётных периодов;
локальный анализ динамики;
механику раскрытия и сворачивания команд;
индикацию применённых фильтров.
Руководитель, попадая на дашборд, сразу видит ключевые показатели:
общее количество сотрудников,
распределение по типам занятости (штат / вендор),
количество вакансий,
число команд и их структуру.
KPI-карточки дополнены процентными соотношениями и компактными индикаторами тренда, что позволяет за несколько секунд оценить масштаб проекта и текущую динамику.
В дашборде реализована возможность анализа данных по выбранному отчётному периоду.
Руководитель может:
переключать период (месяц, квартал, произвольный диапазон);
анализировать изменение численности;
сравнивать категории между собой.
Это позволяет не только видеть текущую картину, но и отслеживать рост, сокращение или дисбаланс ресурсов.
Реализована древовидная структура:
проект → команда → сотрудник
Руководитель может:
раскрывать и сворачивать команды;
видеть FTE и численность;
просматривать состав участников;
быстро находить конкретного сотрудника.
