.svg)
Пользователь открывает аналитический экран и через три секунды закрывает его. Не потому что данных мало - а потому что их слишком много, они расположены хаотично, и непонятно, на что смотреть. Это типичная проблема data-heavy UI: информация есть, а прочитать её невозможно.
Хорошо спроектированная таблица или дашборд не просто выглядят аккуратно. Они направляют взгляд: показывают, что важно прямо сейчас, что можно игнорировать, где искать детали. Это не эстетика - это функция интерфейса.
В этой статье разберём конкретные решения: как строить иерархию в числовых экранах, где чаще всего ломается читаемость, какие паттерны работают в таблицах и составных дашбордах, и что проверить перед тем, как передавать макет в разработку.
Коротко:
- Первая задача - определить, что пользователь ищет на экране: одно ключевое число, сравнение строк или аномалию в данных. Структура строится под этот сценарий.
- Числа выравниваются по правому краю, текст - по левому. Это не стилистика, а условие для быстрого сравнения.
- Цвет в таблицах и дашбордах работает как сигнал, а не как украшение. Если цвет есть везде - он не работает нигде.
- Самая частая ошибка - показывать все данные сразу. Прогрессивное раскрытие и фильтрация нужны именно здесь.
- Пустые состояния, состояния загрузки и ошибок - часть компонента, а не отдельная задача на потом.
- Прежде чем добавлять новый виджет или колонку, стоит проверить: пользователь когда-нибудь действительно на это смотрит?
Что делает экран с данными читаемым
Читаемость числового экрана определяется не количеством информации, а тем, насколько быстро пользователь находит ответ на свой вопрос. Этот вопрос нужно сформулировать до того, как начинать раскладывать элементы на макете.
Спросите себя: зачем пользователь открывает этот экран? Варианты разные. Один хочет увидеть одно ключевое число - выручку за сегодня. Другой сравнивает несколько строк - кто из менеджеров выполнил план. Третий ищет аномалию - где в воронке резко упала конверсия. Каждый из этих сценариев требует другой визуальной структуры.
Если ответа на этот вопрос нет - экран будет перегружен по умолчанию. Дизайнер добавит всё, что может понадобиться, и получит информационный шум.
Иерархия: что видно первым
В data-heavy UI дизайне иерархия строится через размер, вес и расположение. Самое важное число должно быть заметным без усилий. Всё остальное - на втором и третьем уровне.
Типичная структура дашборда выглядит так: вверху - сводные метрики (KPI-карточки), ниже - детальные графики или таблицы, в самом низу или в боковой панели - фильтры и настройки. Это не единственно верный вариант, но он работает, потому что совпадает с тем, как большинство аналитических задач решаются сверху вниз: сначала оцени общую картину, потом копай в детали.
Проблема возникает, когда все уровни получают одинаковый визуальный вес. Одинаковый размер шрифта, одинаковые карточки, одинаковые цвета - и взгляд не знает, куда идти. Контраст между уровнями иерархии - не пожелание, а требование.
Таблицы: правила, которые реально влияют на читаемость
Выравнивание
Числа всегда выравниваются по правому краю - это позволяет мозгу быстро сравнивать значения по разрядам. Текстовые поля - по левому. Заголовки колонок выравниваются в сторону содержимого: заголовок числовой колонки - вправо, текстовой - влево.
Нарушение этого правила выглядит незначительным на макете, но в браузере - сразу видно. Таблица с числами по центру читается хуже, чем с числами по правому краю, даже если пользователь не может объяснить почему.
Типографика чисел
Для числовых колонок используйте моноширинные или tabular-цифры - шрифты с одинаковой шириной каждого знака. В обычных пропорциональных шрифтах «1» уже «8», и колонка с числами будет выглядеть зубчатой. В Figma это настраивается через параметр Tabular Numbers в настройках шрифта - большинство современных гарнитур его поддерживают.
Разрядный разделитель (пробел или запятая) обязателен для чисел от 1000 и выше. Без него число 1234567 читается медленнее, чем 1 234 567.
Плотность строк
Высота строки в таблице должна давать глазу место для «посадки». Слишком плотные строки сливаются, слишком разреженные - разрывают связь между данными одной строки. Оптимальный диапазон для аналитических таблиц - 40-56px высоты строки при шрифте 14px.
Зебра (alternating rows) помогает, когда колонок много и взгляд может «соскользнуть» на соседнюю строку. Но она не нужна в коротких таблицах до 5-7 строк - там достаточно разделителей.
Фиксированные колонки и заголовки
Если таблица шире экрана или длиннее видимой области - первая колонка (обычно название или идентификатор) и строка заголовков должны быть зафиксированы. Без этого пользователь теряет контекст при скролле и не понимает, к чему относится число в дальней правой колонке.
Цвет как функциональный инструмент
В числовых экранах цвет несёт смысловую нагрузку: зелёный - рост или успех, красный - падение или ошибка, жёлтый - предупреждение. Эти значения укоренились настолько, что нарушать их не стоит без весомой причины.
Главная ловушка - использовать цвет декоративно. Когда каждая строка или каждый виджет окрашены в разные оттенки, цветовая кодировка теряет смысл. Пользователь перестаёт воспринимать её как сигнал.
Практическое правило: цвет должен появляться только там, где есть отклонение от нормы или где нужно привлечь внимание. Нейтральные данные - нейтральные цвета. Это особенно важно при проектировании дашбордов с семафорной логикой (RAG: red-amber-green), где смысл держится именно на контрасте между состояниями.
Отдельная история - дальтонизм. Около 8% мужчин не различают красный и зелёный. Если семантика цвета критична, дублируйте её иконкой или текстовым лейблом рядом.
Антипаттерны: где чаще всего ломается восприятие
| Антипаттерн | Что происходит с пользователем | Как исправить |
|---|---|---|
| Слишком много колонок без приоритета | Не понимает, куда смотреть, скроллит вправо и теряет контекст | Вынести 3-5 ключевых колонок, остальные скрыть за настройкой |
| Числа без единиц измерения | Тратит время на интерпретацию: это рубли, штуки или проценты? | Добавить единицу в заголовок колонки или рядом с числом |
| Все метрики одного визуального веса | Не видит, что важно прямо сейчас | Выделить 1-3 ключевых KPI крупнее, остальные - поддерживающие |
| Цвет без легенды или пояснения | Не понимает, что означает оранжевая строка | Добавить tooltip или легенду рядом с цветовым индикатором |
| Отсутствие пустого состояния | Видит пустую таблицу и думает, что что-то сломалось | Спроектировать empty state с объяснением и действием |
Группировка и структура дашборда
Хороший дашборд - это не набор виджетов, а повествование. Он должен отвечать на вопрос за вопросом: сначала «всё хорошо или нет», потом «где именно проблема», потом «что с этим делать».
Группируйте виджеты по смысловым блокам, а не по типу визуализации. Плохо: все графики в одном ряду, все таблицы в другом. Хорошо: блок «продажи» с метрикой, графиком динамики и таблицей по менеджерам - всё рядом, потому что это один контекст.
Между блоками нужен явный визуальный разрыв - отступ, разделитель или фоновый контейнер. Без него пользователь не понимает, где заканчивается одна тема и начинается другая.
Размещение по сетке обязательно. Виджеты произвольного размера, расположенные без выравнивания, создают ощущение хаоса даже если каждый из них спроектирован хорошо. В Figma удобно использовать auto layout с фиксированными зазорами между карточками - это даёт консистентный ритм при любом наполнении.
Сортировка, фильтрация и пагинация
Интерактивность таблицы - это не бонус, а ожидание. Пользователь аналитического продукта по умолчанию хочет уметь сортировать колонки, фильтровать строки и управлять объёмом данных на экране.
Несколько конкретных решений:
Вакансии для дизайнеров
- Сортировка по умолчанию должна быть осмысленной - не по алфавиту, а по самой важной метрике. Если пользователь видит список заказов, логичная сортировка - по дате, а не по ID.
- Активная сортировка должна быть видна: стрелка в заголовке, изменение цвета или жирности. Пользователь должен понимать, по какому столбцу и в каком направлении отсортированы данные.
- Фильтры лучше размещать над таблицей или в боковой панели, а не внутри каждой ячейки заголовка. Это разделяет управление и содержимое.
- Пагинация vs бесконечный скролл: для аналитических таблиц пагинация работает лучше, потому что пользователь работает с конкретным «срезом» данных и возвращается к нему. Бесконечный скролл подходит для лент контента, но не для таблиц с числами.
- Количество строк на странице стоит сделать настраиваемым: 25, 50, 100. Разные пользователи работают с разными объёмами данных.
Прогрессивное раскрытие в сложных таблицах
Когда таблица содержит десятки колонок или иерархические данные (группы, подгруппы, дочерние строки), нужно прогрессивное раскрытие. Это значит: по умолчанию показывается сжатый вид, детали открываются по действию пользователя.
Конкретные паттерны:
- Раскрывающиеся строки (expandable rows) для иерархических данных - например, заказ и его позиции.
- Боковая панель с деталями по клику на строку - вместо отдельной страницы, если детализация не требует много места.
- Скрытые колонки с настройкой видимости - пользователь сам выбирает, что ему нужно видеть.
- Свёрнутые группы строк с агрегированной метрикой - пользователь видит итог, а детали раскрывает при необходимости.
Прогрессивное раскрытие снижает когнитивную нагрузку и делает сложные данные управляемыми. Главное правило: состояние по умолчанию должно отвечать на 80% задач без дополнительных действий.
Состояния компонента: что нужно спроектировать заранее
Таблица или виджет дашборда - это не один статичный вид. Каждый компонент нужно довести до полного набора состояний ещё на этапе макета.
Частая ошибка: дизайнер рисует только «счастливый путь» - таблицу с данными. Разработчик получает макет без состояния загрузки, без пустого состояния, без состояния ошибки. В результате три из четырёх реальных сценариев оказываются непроработанными.
Минимальный набор для таблицы или виджета:
- Загрузка - скелетон или спиннер, в зависимости от времени ожидания
- Данные есть - основной вид
- Данных нет (empty state) - с объяснением причины и действием
- Ошибка загрузки - с возможностью повторить запрос
- Частичные данные - например, некоторые метрики недоступны
Визуализация данных: когда таблица, а когда график
Не всё, что можно показать числом, стоит показывать в строке таблицы. И наоборот - не всё, что можно нарисовать как график, нужно превращать в визуализацию.
| Сценарий | Подходящий формат | Почему |
|---|---|---|
| Сравнение точных значений между объектами | Таблица | Числа удобнее сравнивать, чем высоту столбцов |
| Динамика показателя во времени | Линейный график | Тренд виден моментально, точные значения - по наведению |
| Доля от целого | Горизонтальная столбчатая диаграмма | Проще читать, чем круговую; подписи помещаются |
| Одно ключевое число с контекстом | KPI-карточка с дельтой | Мгновенное считывание без необходимости анализировать |
| Распределение по категориям с деталями | Таблица с inline-барами или спарклайнами | Сочетает точность и визуальный паттерн в одном месте |
Inline-визуализация внутри таблицы - отдельный полезный паттерн. Маленький бар рядом с числом или спарклайн (миниатюрный график тренда в ячейке) дают пользователю контекст без переключения на отдельный экран. Google Sheets и Airtable активно используют этот подход в своих нативных компонентах.
Работа с числами: форматирование и контекст
Числа без контекста почти бесполезны. «537 248» ничего не говорит само по себе. «537 248 руб. (+12% к прошлой неделе)» - уже картина.
Что стоит добавить рядом с ключевыми метриками:
- Единица измерения (руб., шт., %, мин.)
- Дельта к предыдущему периоду - абсолютная или процентная, со знаком и цветом
- Временной период, за который посчитано число
- Сравнение с целевым значением или нормой, если оно есть
Округление - отдельный вопрос. Для оперативного мониторинга обычно достаточно округлить до тысяч или миллионов с суффиксом (1.2M, 45K). Для финансовой отчётности нужна полная точность до копейки. Выбор зависит от задачи пользователя, а не от технических возможностей.
Работа в Figma: как организовать компоненты для data-heavy экранов
При проектировании аналитических экранов в Figma несколько вещей сэкономят время и снизят число ошибок при хендофе.
Используйте компоненты с вариантами для строк таблицы: дефолтная строка, строка при hover, выбранная строка, строка с предупреждением. Все четыре варианта должны быть в одном компоненте, а не в четырёх отдельных файлах.
Для числовых значений в ячейках стоит завести отдельные стили текста с tabular numbers. Если команда использует дизайн-токены, числовые значения должны тянуться из той же системы, что и остальная типографика.
Auto layout в карточках метрик позволяет корректно обрабатывать длинные числа - компонент растягивается, а не обрезает значение. Это критично, потому что в реальных данных числа бывают разной длины.
Отдельно стоит завести страницу с состояниями: все варианты таблицы и виджетов в одном месте. Это упрощает проверку перед хендофом и помогает разработчику понять, что нужно реализовать.
Чеклист перед хендофом
- Определён основной сценарий: что пользователь ищет на этом экране
- Числа выровнены по правому краю, используются tabular numbers
- Все метрики снабжены единицами измерения и периодом
- Иерархия данных читается без объяснений: ясно, что важное, что вспомогательное
- Цвет используется как сигнал, а не декорация; для цветовой семантики есть дублирующий лейбл или иконка
- Спроектированы все состояния: загрузка, данные есть, пусто, ошибка
- Первая колонка и заголовки таблицы фиксируются при скролле
- Фильтры, сортировка и управление видимостью колонок - в макете, не «добавим потом»
- Пагинация с выбором количества строк включена в спецификацию
- Компоненты собраны с вариантами состояний в одном месте в Figma
- Мобильная версия или адаптив проработаны: таблицы на малом экране требуют отдельного решения
FAQ
Чем отличается дашборд от аналитического отчёта в интерфейсе?
Дашборд показывает текущее состояние в реальном времени или близко к нему - это оперативный инструмент. Отчёт - это срез за период, обычно статичный или генерируемый по запросу. С точки зрения дизайна: дашборд требует акцента на скорости считывания, отчёт - на полноте и точности данных.
Сколько колонок допустимо в таблице?
Нет жёсткого лимита, но практика показывает: если колонок больше 7-8, большинство пользователей игнорируют правую часть таблицы. Оптимальный подход - вынести 4-6 ключевых колонок по умолчанию и дать возможность добавить остальные через настройку видимости.
Когда использовать спарклайны внутри ячеек таблицы?
Спарклайны полезны, когда пользователю нужно оценить тренд без перехода на отдельный экран. Например, в таблице магазинов показывать не только выручку за период, но и динамику продаж в виде маленького графика. Не стоит добавлять их в каждую числовую колонку - только туда, где тренд действительно важен для решения.
Как правильно показывать отрицательные значения и падения?
Красный цвет плюс знак минус - стандарт. Но важно учитывать контекст: в некоторых метриках падение - это хорошо (например, снижение числа ошибок). Поэтому цвет должен кодировать «хорошо/плохо» относительно цели, а не просто направление изменения. Это нужно прописать в логике компонента при хендофе.
Нужна ли адаптивная версия аналитических таблиц для мобильного?
Зависит от реальных сценариев использования. Если аналитику смотрят с телефона - нужна. Стандартная таблица с горизонтальным скроллом на мобильном работает плохо. Альтернативы: карточный вид вместо строк, приоритизация двух-трёх ключевых колонок, переход к детальному виду по тапу на карточку.
Как избежать перегруза на дашборде, если заказчик хочет добавить всё?
Полезный приём - попросить заказчика назвать три вопроса, на которые он отвечает с помощью этого экрана каждый день. Всё, что не отвечает ни на один из этих вопросов - кандидат на удаление или перенос в детальный раздел. Это переводит разговор из «нравится/не нравится» в плоскость задачи.
Итог
Хорошо спроектированный числовой экран - это не тот, где данных много, а тот, где пользователь находит нужное быстро. Иерархия, выравнивание, цветовые сигналы и прогрессивное раскрытие - не детали отделки, а основа читаемости.
Большинство проблем в data-heavy UI возникают не из-за технических ограничений, а из-за того, что сценарий пользователя не был сформулирован до начала работы. Начните с вопроса «что человек ищет на этом экране» - и структура сложится сама.