Дизайн дашборда: правила, графики и чек-лист

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

Большинство разборов в сети сводятся к советам «оставляйте воздух» и «не используйте 3D». Это правильно, но мало. Панель, которой реально пользуются, держится на сценарии, иерархии, честных графиках, продуманных состояниях загрузки и ошибок и на данных, которые приходят вовремя. Последнее — уже задача разработки: от того, как бэкенд агрегирует события, зависят скорость, свежесть и набор фильтров. Поэтому если панель — часть клиентского кабинета или SaaS-сервиса, а не отчёт в BI-системе, разумно заказать разработку веб-приложения вместе с аналитическими панелями у одной команды, где дизайнер и инженер обсуждают метрики с первого дня.

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

Что такое дашборд и какие они бывают

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

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

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

С чего начать проектирование дашборда

Начинать стоит не с Figma, а с разговора с теми, кто будет смотреть на экран. Задача этапа — собрать сценарии: в какой момент человек открывает панель, что ищет и что делает, когда находит отклонение.

1. Определите аудиторию и контекст. Кто открывает панель, на каком устройстве, сколько у него времени. Диспетчер смотрит на большой экран на стене, руководитель — на телефон между встречами.
2. Сформулируйте вопросы. Запишите 3–7 вопросов, на которые экран должен отвечать: «выполняем ли план продаж месяца», «какой канал дал больше заявок», «сколько обращений висит дольше суток».
3. Свяжите вопросы с действиями. Для каждого вопроса — что человек сделает, если ответ плохой. Если действия нет, вопрос, скорее всего, лишний.
4. Проверьте данные. Вместе с разработкой выясните, откуда берётся каждая цифра, как часто обновляется и насколько ей можно доверять. Метрика, которая считается раз в сутки, не может жить на операционной панели.
5. Нарисуйте низкодетальный прототип. Серые блоки с подписями «KPI», «тренд», «топ-5» — и сразу покажите их пользователям. Как собрать такой прототип, мы разбирали в статье о прототипировании от вайрфрейма до кликабельного прототипа.

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

Как выбрать метрики и не перегрузить экран?

Главный враг дашборда — желание показать всё, что можно посчитать. Человек способен одновременно удерживать в рабочей памяти лишь несколько объектов, поэтому экран с двадцатью равнозначными карточками не читается: взгляд скачет, а вывод не складывается.

Практическое правило — 5–9 ключевых показателей на первом экране. Остальное — ниже по странице или в детализации. Чтобы отобрать эти показатели, пропустите каждый кандидат через три фильтра:

• Влияет на решение. Если значение изменится вдвое, кто-то что-то сделает. Если нет — это справочная информация.
• Понятен без пояснений. «Конверсия заявки в оплату, %» понятна, «индекс вовлечённости v2» — нет, пока рядом нет расшифровки.
• Имеет контекст. Голая цифра «1 284» ничего не говорит. Ей нужно сравнение: с планом, с прошлым периодом, с нормой.

Контекст — то, что отличает дашборд от табло. Каждая ключевая карточка показывает значение, направление и масштаб изменения и опорную точку: «1 284 заявки, +12% к прошлой неделе, план 1 400». Если показатель продуктовый, полезно заранее договориться о его определении — подход к выбору UX-метрик подробно описан в статье про SUS, HEART и успешность задач.

Как выстроить иерархию и сетку?

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

1. Итоги. Ряд KPI-карточек сверху: главные цифры с изменением и сравнением.
2. Динамика и разрезы. Ниже — 2–4 основных графика, которые объясняют итоги: тренд во времени, распределение по каналам, воронка.
3. Детали. Внизу — таблицы, списки, топы, из которых можно перейти к конкретной записи.

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

Сетка держит всё это в порядке. Двенадцать колонок дают достаточно вариантов раскладки: карточки по 3 колонки, основной график на 8, боковой список на 4. Отступы между карточками берите из той же шкалы, что и во всём продукте; как выстроить такую шкалу, мы описали в статье о сетке и отступах 4/8 pt.

Отдельно продумайте заголовки. Подпись «График 3» бесполезна, «Заявки по каналам» — лучше, «Заявки по каналам: контекст обогнал SEO» — ещё лучше, если панель рассчитана на чтение выводов, а не на самостоятельный анализ.

Какой график выбрать под задачу?

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

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

Принцип data-ink ratio, предложенный Эдвардом Тафти, полезен как фильтр: всё, что не несёт данных — плотная сетка, тени, градиенты, рамки, — уменьшайте или убирайте. Цель не минимализм ради стиля, а то, чтобы взгляд сразу попадал на данные.

Как работать с цветом и доступностью?

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

• Базовая палитра — нейтральная. Большинство графиков рисуют спокойными тонами, а яркий цвет оставляют для того, что требует внимания.
• Семантика постоянна. Красный — плохо, зелёный — хорошо, жёлтый — внимание. Если в одном месте красный означает «категорию Б», сигнал «тревога» перестаёт работать.
• Последовательные данные — одним тоном. Для шкалы «мало — много» используйте градацию светлоты одного цвета, а не радугу.
• Не больше 6–8 категориальных цветов. Больше глаз не различает уверенно.

Доступность здесь не формальность. По данным исследований, нарушения цветового зрения есть примерно у 8% мужчин, и пара «красный — зелёный» для них неразличима. Требования WCAG 2.2 напрямую касаются панелей: информация не должна передаваться только цветом (критерий 1.4.1), а графические объекты, которые нужны для понимания, — линии, столбцы, границы — должны иметь контраст не ниже 3:1 с фоном (критерий 1.4.11). Текст подписей — 4,5:1. Подробнее о порогах контраста и фокусе — в нашем разборе WCAG 2.2 на практике.

На практике это значит: дублируйте цвет формой или текстом (стрелка вверх и «+12%», а не только зелёная цифра), используйте разные маркеры и типы линий для серий, давайте графикам текстовую альтернативу — краткий вывод в подписи или доступную таблицу с теми же данными.

Как не исказить данные графиком?

Дашборд принимает решения вместе с человеком, поэтому визуальное искажение — не стилистическая ошибка, а риск. Чаще всего данные искажают не намеренно, а по невнимательности.

1. Обрезанная ось Y у столбцов. Если ось начинается не с нуля, разница в 3% выглядит как двукратная. Для столбцов ось всегда от нуля; для линейных графиков, где важна форма тренда, обрезка допустима, но её нужно явно показать.
2. Разные масштабы на соседних графиках. Две панели рядом с разными шкалами читаются как сравнимые. Либо общая шкала, либо явная подпись.
3. Неполный последний период. Текущий месяц на графике по месяцам всегда «проваливается». Отмечайте неполный период пунктиром или подписью.
4. Пропуски в хронологии. Если данных за неделю нет, линия не должна молча соединять соседние точки — покажите разрыв.
5. Скрытая агрегация. Среднее время ответа может выглядеть нормально, пока медиана и 95-й процентиль показывают проблему. Подписывайте, что именно посчитано.

Хорошая проверка — показать график коллеге без подписей и спросить, какой вывод он делает. Если вывод не совпадает с данными, график надо менять, а не объяснять.

Какие состояния нужны дашборду?

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

Особенно важна свежесть. Если менеджер видит вчерашние цифры и думает, что они сегодняшние, панель вредит больше, чем её отсутствие. Подпись «обновлено 5 минут назад» — один из самых недооценённых элементов дашборда. Полный список состояний интерфейсных элементов собран в нашем чек-листе состояний компонента.

Фильтры, детализация и интерактивность

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

• Глобальные фильтры — сверху и на виду. Период, регион, продукт. Текущие значения всегда видны, а не спрятаны в выпадающем меню.
• Разумные значения по умолчанию. Панель открывается в самом частом виде: например, «последние 30 дней», а не «всё время».
• Детализация по клику. Клик по столбцу или строке ведёт на уровень ниже: от канала — к кампаниям, от кампании — к заявкам. Путь назад очевиден, хлебные крошки показывают, где ты.
• Подсказки при наведении — дополнение, а не единственный источник. На сенсорных экранах наведения нет, а с клавиатуры подсказку нужно уметь вызвать фокусом.
• Состояние в адресе. Выбранные фильтры сохраняются в URL, чтобы ссылкой можно было поделиться и вернуться к тому же виду.

Отдельный принцип — «пусть считает машина, а не пользователь». Если человек открывает два графика, чтобы вычесть одно из другого, разницу надо показать сразу. Если он каждый раз ставит одни и те же фильтры — сохраните их как представление. Это уже не вопрос визуала, а функциональность продукта, которую закладывают вместе с разработчиками.

Как адаптировать дашборд под телефон?

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

• Оставьте сверху 3–5 главных KPI, остальное — по запросу.
• Раскладывайте карточки в одну колонку в порядке важности, а не в порядке десктопной сетки.
• Упрощайте графики: меньше серий, меньше подписей на оси, крупные цели касания не меньше 24 на 24 пикселя.
• Широкие таблицы превращайте в карточки или давайте горизонтальную прокрутку с закреплённой первой колонкой.
• Фильтры прячьте в отдельную панель, но выбранные значения показывайте над контентом.

Если сценарии на телефоне и на компьютере сильно различаются, честнее сделать отдельное мобильное представление, чем растягивать один макет на все ширины.

Пример: дашборд заявок для отдела продаж

Соберём всё вместе на типичной задаче. Руководитель отдела продаж хочет каждое утро понимать, хватает ли заявок для выполнения плана и где они теряются. Аудитория одна, главный вопрос — «выполним ли план месяца», тип панели — аналитический с ежедневным обновлением.

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

Первый уровень. Четыре KPI-карточки: заявки за месяц с прогнозом к концу периода и планом; конверсия в оплату с изменением к прошлому месяцу; средняя скорость первого ответа; число заявок без ответа дольше двух часов. Последняя карточка подсвечивается, только если значение больше нуля, — это единственный яркий сигнал на экране.

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

Третий уровень. Таблица заявок без ответа с менеджером, каналом и временем ожидания; клик по строке открывает карточку сделки в CRM. Над всем экраном — фильтр периода, выбор менеджера и подпись «обновлено в 08:00».

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

Частые ошибки

Чек-лист перед запуском

Пройдите по списку перед тем, как отдавать макет в разработку, и ещё раз — на реальных данных перед релизом.

1. У панели одна аудитория и записаны вопросы, на которые она отвечает.
2. На первом экране не больше 5–9 ключевых показателей, у каждого есть сравнение.
3. Порядок блоков идёт от итогов к деталям, связанные элементы сгруппированы.
4. Тип каждого графика соответствует задаче, столбцы отсортированы, ось столбцов от нуля.
5. Цвет несёт смысл и не единственный носитель информации, контраст графики не ниже 3:1, текста — 4,5:1.
6. Есть состояния загрузки, пустоты, ошибки, частичных и устаревших данных.
7. Видно время последнего обновления.
8. Фильтры видны, имеют разумные значения по умолчанию и сохраняются в адресе.
9. Мобильная версия показывает главное в одну колонку.
10. Панель проверена на 3–5 реальных пользователях по их сценариям.

Последний пункт обычно пропускают, хотя он самый дешёвый. Дайте пользователю задание — «найдите, какой канал просел на этой неделе» — и молча наблюдайте. Даже несколько сессий показывают, где взгляд теряется и какие подписи не понимают. Как организовать такие сессии и когда пяти участников достаточно, мы разбирали в статье о юзабилити-тестировании на пяти пользователях. Полезная внешняя опора — материалы Nielsen Norman Group о дашбордах и предвнимательной обработке: там подробно разобрано, какие визуальные свойства мозг считывает до осознанного внимания.