Проектируем дашборд: от вопросов пользователя к экрану

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

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

Один дашборд «для всех» обычно не отвечает никому. Руководитель думает неделями и каналами, менеджер — конкретными заявками сегодня. Поэтому работа начинается с ролей. Возьмём учебный пример — компанию, которая принимает заявки с сайта и ведёт их в CRM. Вопросы ниже — заготовка: в реальном проекте их собирают на интервью и наблюдении за работой, как описано в уроке об UX-исследованиях.

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

Вторая ловушка — неоднозначные определения. «Заявка» — это любая отправленная форма или только та, где есть телефон? Считаются ли дубли и спам? Неделя начинается с понедельника, и в каком часовом поясе? Пока это не записано, у руководителя и менеджера будут разные «47», и дашбордом перестанут пользоваться.

Форма выбирается от вопроса. NN/g опирается на предвнимательные признаки — то, что глаз замечает до осознанного чтения. Для количественного сравнения лучше всего работают длина и положение на плоскости: люди хорошо сравнивают длины, а вот площадь и угол замечают, но плохо оценивают, во сколько раз одно больше другого. Цвет не передаёт порядок, поэтому не должен кодировать величину — он подходит для категорий и только как дополнительный признак.

Таблица — полноценная форма дашборда, а не признание поражения. NN/g выделяет четыре задачи, ради которых открывают таблицы: найти записи по условиям, сравнить данные, посмотреть или изменить одну запись и выполнить действие над одной или несколькими записями. Для списка заявок без ответа это ровно то, что нужно менеджеру. Заголовки больших таблиц закрепляйте, фильтры делайте заметными, а включённые фильтры — явно видимыми.

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

Адаптацию удобно планировать по брейкпоинтам Material Design 3: компактный — до 600 dp (телефон в портретной ориентации), средний — 600–839, расширенный — 840–1199, большой — 1200–1599, очень большой — от 1600. Material советует проектировать под брейкпоинты, а не под конкретные устройства, и при переходе между ними решать, что раскрыть, как разделить экран, что увеличить, переставить или заменить. Для компактного и среднего размера рекомендуется одна панель, для расширенного и большого — две.

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

Пустое состояние, по NN/g, должно сообщать статус системы, подсказывать, как работает функция, и вести к шагам, которые заполнят экран. Полностью пустой виджет заставляет гадать, сломалось ли что-то или данных правда нет. Именно поэтому «ноль» и «нет данных» — разные состояния: первое — ответ на вопрос, второе — повод для действия.

Доступность графиков — тоже часть состояний. Критерий WCAG 1.4.1 запрещает передавать информацию только цветом: рост и падение в KPI дублируйте знаком и словом, линии на графике — подписями. Для графиков W3C WAI рекомендует двухчастную текстовую альтернативу: короткую подпись, что изображено, и полное описание — текстом или таблицей данных рядом с графиком.

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