Дизайн таблиц данных в интерфейсе: паттерны и чек-лист

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

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

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

Когда интерфейсу нужна таблица, а когда — карточки или график?

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

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

Какие задачи пользователь решает с таблицей?

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

1. Найти запись по признакам. «Заказы клиента Иванова за октябрь», «обращения без ответа дольше суток». Нужны поиск, фильтры, сортировка и понятный ключевой столбец.
2. Сравнить значения. «Какой менеджер закрыл больше сделок», «у каких товаров упала маржа». Нужны правильное выравнивание чисел, единые единицы измерения, сортировка и итоги.
3. Посмотреть или изменить одну запись. Нужны быстрый переход к подробностям — боковая панель, раскрытие строки или отдельная страница — и редактирование без потери контекста.
4. Обработать много записей. «Назначить ответственного на 40 обращений», «выгрузить счета за квартал». Нужны выбор строк, панель массовых действий и защита от ошибок.

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

Как выбрать и упорядочить столбцы?

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

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

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

Как выравнивать текст, числа и даты?

Выравнивание — самое недооценённое решение в таблице. Взгляд сравнивает числа по разрядам, поэтому от того, где стоит цифра, зависит, увидит ли человек, что 12 480 больше 9 970.

Заголовок столбца выравнивают так же, как его содержимое: заголовок числового столбца — вправо. Для цифр в CSS используется font-variant-numeric: tabular-nums — у всех цифр одинаковая ширина, и разряды встают друг под другом. Если в шрифте интерфейса нет табличных цифр, это повод пересмотреть шрифт; как подбирать кегль и интерлиньяж для плотных интерфейсов, мы разбирали в статье о типографической шкале.

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

Какой должна быть плотность строк и визуальное разделение?

Плотность — компромисс между количеством строк на экране и удобством чтения. Операторам, которые весь день работают с очередью, нужна компактная таблица; редким пользователям кабинета — более просторная. Хорошая практика — 2–3 режима плотности с переключателем.

• Компактный — высота строки около 32–36 px, для опытных пользователей и широких мониторов.
• Стандартный — 44–48 px, режим по умолчанию в большинстве продуктов.
• Просторный — 56–64 px, для таблиц с двумя строками текста в ячейке или аватарами.

Отступы внутри ячеек берите из общей шкалы продукта — так таблица не выглядит чужеродной рядом с формами и карточками. Как построить такую шкалу, мы описали в материале о сетке и отступах 4/8 pt.

Разделять строки можно тонкими горизонтальными линиями, чередованием фона (зеброй) или только пространством. Зебра помогает в широких таблицах, где взгляд должен пройти по строке через десяток столбцов. В узких таблицах хватает линий и подсветки строки при наведении. Вертикальные линии между столбцами обычно лишние — выравнивание само формирует колонки. И не смешивайте зебру с цветовой разметкой статусов: фон не может означать одновременно «чётная строка» и «просрочено».

Как закрепить заголовки и ключевые столбцы?

Когда таблица длиннее экрана, пользователь прокручивает её и теряет понимание, какой столбец что означает. Закреплённая строка заголовков решает эту проблему и почти никогда не мешает. В CSS это position: sticky для заголовков; важно, чтобы закреплённая шапка не перекрывала строку с фокусом при навигации с клавиатуры.

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

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

Как спроектировать сортировку, фильтры и поиск?

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

• Сортировка по клику на заголовок. Сортируемые столбцы отличаются от остальных, текущий столбец и направление показаны стрелкой. По умолчанию таблица отсортирована осмысленно: по дате — новые сверху, по сроку — горящие сверху.
• Сортировка по всем данным. Если записи грузятся страницами, сортировать нужно на сервере, а не только текущие 20 строк. Это решение закладывается в API, а не в макет.
• Фильтры над таблицей. Самые частые — сразу видны, редкие — в раскрывающейся панели. Применённые фильтры показаны чипами с крестиком и кнопкой «Сбросить всё».
• Счётчик результатов. «Найдено 128 из 4 312» — пользователь сразу понимает, что фильтр сработал и сколько записей скрыто.
• Поиск с пояснением. Подсказка в поле говорит, по каким полям ищем: «номер заказа, клиент или телефон».
• Состояние в адресе. Фильтры, сортировка и страница сохраняются в URL — ссылкой можно поделиться, а после возврата из карточки записи человек оказывается там же.

Сохранённые представления — следующий уровень: если оператор каждое утро ставит одни и те же пять фильтров, дайте ему сохранить их как вкладку «Мои срочные».

Что выбрать: пагинацию, бесконечную прокрутку или виртуализацию?

Способ показа большого объёма строк влияет и на удобство, и на производительность. Универсального ответа нет, но есть понятные критерии.

Для пагинации дайте выбор размера страницы (25, 50, 100) и покажите общее число записей. Для виртуализации обязательно встройте собственный поиск — встроенный поиск браузера найдёт только отрисованные строки.

Как спроектировать выбор строк и массовые действия?

Массовые действия экономят часы, но и ошибаются с ними масштабно. Поэтому здесь важны и скорость, и защита.

1. Чекбокс в первом столбце. В шапке — общий чекбокс с тремя состояниями: ничего не выбрано, выбрано частично, выбрано всё.
2. Выбор диапазона. Shift+клик выделяет строки между двумя отмеченными — для опытных пользователей это главный ускоритель.
3. Понятный объём выбора. «Выбрано 25 на этой странице. Выбрать все 1 240?» — человек должен явно понимать, применяется действие к видимым строкам или ко всему результату фильтра.
4. Панель действий появляется при выборе. Она показывает число выбранных записей и доступные операции, не сдвигая таблицу.
5. Подтверждение и отмена. Необратимые действия — с подтверждением, где названо число затронутых записей. Обратимые — без диалога, но с кнопкой «Отменить» в уведомлении.
6. Отчёт о результате. Если часть операций не удалась, покажите, какие записи и почему, а не только «Ошибка».

Как редактировать данные в таблице?

Способ редактирования зависит от того, сколько полей меняют за раз и насколько дорогая ошибка.

• Редактирование в ячейке подходит для одного-двух простых полей: статус, ответственный, количество. Ячейка явно показывает, что её можно изменить, сохранение — по Enter или потере фокуса, отмена — по Esc.
• Раскрытие строки — для нескольких связанных полей, когда важно видеть соседние записи.
• Боковая панель — универсальный вариант для просмотра и правки записи с десятком полей: таблица остаётся на месте, переход к следующей записи — стрелками.
• Отдельная страница — для сложных сущностей с историей, вложенными списками и файлами.

Где бы ни шло редактирование, поля подчиняются тем же правилам, что и любые формы: подписи, подсказки формата, ошибки рядом с полем. Подробно эти правила разобраны в статье о формах, которые заполняют.

Какие состояния нужны таблице?

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

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

Как сделать таблицу доступной?

Таблица — один из немногих элементов, где у веба есть готовая и хорошо поддерживаемая семантика. Ей нужно просто пользоваться.

• Настоящая разметка. Табличные данные — в table, заголовки — в th с атрибутом scope, подпись — в caption. Сетка из div требует воссоздавать всё это через ARIA, и обычно это делают неполно.
• Сортировка вслух. Кнопка сортировки внутри заголовка, текущее направление — в aria-sort, чтобы скринридер сообщал «по убыванию».
• Понятные действия. Кнопка «Удалить» в строке для скринридера должна звучать как «Удалить заказ 10482», а не как десяток одинаковых «Удалить».
• Клавиатура. Все действия, чекбоксы и ссылки достижимы клавишей Tab в логичном порядке, фокус хорошо виден и не прячется под закреплённой шапкой.
• Контраст и цвет. Текст — не ниже 4,5:1, разделители и индикаторы — не ниже 3:1, статус не передаётся только цветом.

Если таблица сложная — с объединёнными заголовками или несколькими уровнями, — сверяйтесь с руководством W3C WAI по доступным таблицам. О порогах контраста и видимом фокусе подробнее — в разборе WCAG 2.2 на практике.

Как показать таблицу на телефоне?

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

1. Горизонтальная прокрутка с закреплённым первым столбцом. Сохраняет структуру и возможность сравнения. Подходит, если мобильные пользователи — те же специалисты, что и на компьютере.
2. Строки превращаются в карточки. Каждая запись — блок с парами «подпись — значение», главное поле — заголовком. Удобно читать и нажимать, но сравнивать записи сложнее.
3. Сокращённый список и переход к записи. В строке два-три ключевых поля, остальное — в карточке по нажатию. Лучший вариант для быстрых проверок «где мой заказ».

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

Пример: таблица заказов в B2B-кабинете

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

Столбцы. Номер заказа (ссылка, полужирный), клиент, дата, сумма в рублях по правому краю, статус с иконкой и текстом, срок отгрузки, ответственный. Способ доставки, комментарий и ИНН скрыты по умолчанию и включаются в настройке.

Поиск и фильтры. Поле поиска «номер, клиент или ИНН» и три видимых фильтра: статус, период, ответственный. Над таблицей — счётчик «Найдено 64 из 3 980» и чипы применённых фильтров. Сохранённое представление «Просроченные» — вкладкой рядом с «Все заказы».

Сортировка и объём. По умолчанию — по сроку отгрузки, горящие сверху. Пагинация по 50 строк с выбором размера страницы, сортировка и фильтры выполняются на сервере, состояние хранится в адресе.

Массовые действия. Чекбоксы, выбор диапазона по Shift, панель «Выбрано 12: сменить статус, назначить ответственного, выгрузить». Смена статуса — с кнопкой «Отменить» в уведомлении; отмена заказов — с подтверждением и числом затронутых записей.

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

Такую таблицу менеджер осваивает за день, а ежедневная работа с очередью сокращается с десятков кликов до нескольких.

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

Чек-лист перед передачей в разработку

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

1. Записана главная задача таблицы: найти, сравнить, изменить или обработать пачкой.
2. Первый столбец идентифицирует запись и ведёт к подробностям.
3. По умолчанию показано 5–8 столбцов, остальные включаются в настройке, настройка сохраняется.
4. Числа выровнены вправо, цифры табличные, единицы — в заголовках, формат дат единый.
5. Выбрана плотность по умолчанию, отступы из общей шкалы, статус не передаётся только цветом.
6. Заголовки закреплены, ключевой столбец закреплён при горизонтальной прокрутке.
7. Сортировка и фильтры работают по всем данным, есть счётчик результатов и сброс.
8. Состояние фильтров, сортировки и страницы сохраняется в адресе.
9. Выбран способ показа объёма: пагинация, «показать ещё» или виртуализация с собственным поиском.
10. Массовые действия показывают объём выбора, необратимые требуют подтверждения.
11. Нарисованы состояния загрузки, пустоты, пустого фильтра, ошибки и сохранения строки.
12. Разметка семантическая, сортировка озвучивается, всё доступно с клавиатуры.
13. Есть отдельный сценарий для телефона.

Финальная проверка — 3–5 сессий с реальными пользователями и заданием из их работы: «найдите все просроченные заказы клиента и назначьте их на себя». Как организовать такие сессии, мы разбирали в статье о юзабилити-тестировании на пяти пользователях. Хорошая внешняя опора по теме — разбор Nielsen Norman Group о таблицах данных, где четыре задачи пользователя описаны с примерами.