Как свести таблицы продукта к общим правилам: сводка, поведение по умолчанию и проверка экранов

Правила начинаются не с чистого листа, а с того, что уже есть. Все таблицы продукта выписывают рядом и сравнивают по одним и тем же вопросам.

Оператор с утра работает в заказах, после обеда — в возвратах.

В заказах нажатие по строке открывает карточку, в возвратах — ничего не делает. В заказах редкие действия лежат в меню «⋯», в клиентах — иконками прямо в строке, и корзина стоит рядом с карандашом.

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

В каждой колонке этой сводки — от трёх до пяти разных ответов на один вопрос.

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

Такой разбор — частный случай инвентаризации интерфейса, о которой писал Брэд Фрост: собрать все варианты одного элемента в одно место, чтобы увидеть разнобой. Про сами состояния и паттерны — урок «Паттерны и состояния, Senior».

У любой рабочей таблицы одни и те же части. Правила удобно писать по ним: тогда у каждого вопроса одно место в документе.

Как это описывают большие системы

Большие дизайн-системы описывают таблицу по тем же частям. Например:

• IBM Carbon — над таблицей панель с главной кнопкой, поиском, фильтрами и настройками вида. Когда выбрана строка, сверху появляется панель групповых действий.
• Atlassian — своя таблица с сортировкой и разбивкой на страницы.
• Material Design 3 — таблицы данных нет вовсе: она описана только во второй версии системы.

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

Даже в хороших системах правила расходятся. У Carbon у каждой строки меню «⋯», а если действий меньше трёх, их выносят иконками прямо в строку: критерий — число действий. В админке «Лесной обжарки» критерий — частота: кнопкой стоит то, что делают с каждой строкой.

У Ozon панель групповых действий встаёт на место переключателя страниц внизу, у Carbon — сверху. Работают оба варианта, если в продукте выбран один.

Порядок строк, число строк на странице, плотность — это то, что человек видит, пока ничего не нажал. Многие так ничего и не нажмут, поэтому умолчания решают больше, чем настройки.

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

Правило пишется по типу таблицы, а тип определяет задача человека.

Проверьте себя

Восемь таблиц админки. Какой порядок у каждой по умолчанию?

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

Остальные умолчания — одной строкой на всю админку:

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

Таблица хороша, когда:

• записей много;
• у них одни и те же поля;
• строки сравнивают между собой или делают с ними что-то пачкой.

Если хоть одного из этих условий нет, обычно есть способ лучше.

Проверьте себя

Восемь экранов админки. Таблица или другой способ?

В Контур.Гайдах правило ещё короче: таблица нужна, когда значения сравнивают или ищут внутри одного столбца, а если нет — хватит списка или карточек.

У GOV.UK для пар «поле — значение» есть отдельный компонент, список сведений, а таблица — чтобы сравнивать строки и колонки. В Nielsen Norman Group объясняют, почему карточки плохи для сравнения: взгляд от карточки к карточке каждый раз заново ищет нужное поле.

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

С поставщиками работают двое. Закупщик ищет поставщика по названию, когда пришла накладная. Бухгалтер раз в неделю закрывает долги сразу нескольким.

Нажимайте на куски таблицы, которые не совпадают с правилами из раздела 2. Там, где всё по правилам, разбор тоже покажется.

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

У «Лесной обжарки» появились оптовые клиенты: кофейня заказывает 40 килограммов, и заказ уходит тремя поставками в разные дни.

В правилах «одна строка — одна запись», а оператору нужно видеть и заказ целиком, и каждую поставку. Есть три пути, и выбирают между ними не по вкусу.

Когда решение принято, документ правил меняется так, чтобы через год было понятно, что и почему поменялось:

ВЕРСИЯ 1.3 · 14.10.2026

ЧТО ИЗМЕНИЛОСЬ
Правило 3 «Строка»: добавлены вложенные строки. Строка заказа с
несколькими поставками раскрывается, у каждой поставки свой статус
и своя кнопка. Групповые действия — только на уровне заказа.

ПОЧЕМУ
Оптовые заказы кофеен уходят несколькими поставками. Такие же
записи ожидаются в возвратах и закупках.

ЧТО ПРИВЕСТИ К ПРАВИЛУ
Заказы — сейчас поставки отдельными строками без связи с заказом.
Возвраты — будет нужно, когда появятся оптовые возвраты.

КТО РЕШИЛ
Дизайнер админки, руководитель склада, разработка

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

Часть 1 · Сводка, 40 минут

1. Соберите все таблицы продукта в один файл: снимки экранов, по одному на таблицу.
2. Сведите их в таблицу-сводку по вопросам из раздела 1: порядок, фильтры, нажатие по строке, действия, выбор, много строк.
3. Отметьте различия и у каждого — есть ли причина.

Часть 2 · Правила, 60 минут

1. Заполните шаблон ниже: по каждой части таблицы — правило и одна строка «почему».
2. Запишите исключения с причиной и таблицей, где они действуют.
3. Напишите раздел «когда не таблица» с примерами из своего продукта.

ПРАВИЛА ТАБЛИЦ · ______________        Версия ___ от __.__.____

0. КОГДА ТАБЛИЦА
таблица — если: записей много, поля одинаковые, строки сравнивают или обрабатывают пачкой
не таблица: одна запись → ______   события → ______   вложенность → ______

1. ПАНЕЛЬ НАД ТАБЛИЦЕЙ
поиск: где ______  по каким полям ______
фильтры: ______   счётчик «N из M»: где ______   сброс: ______
кнопка создания: где ______
почему: ______________________

2. ЗАГОЛОВОК И СОРТИРОВКА
порядок по умолчанию: очередь → ______  журнал → ______  справочник → ______  отчёт → ______
сортируемые колонки: ______________   первое нажатие: ______________
почему: ______________________

3. СТРОКА
нажатие по строке: ______________
частое действие: ______   редкие: ______   необратимые: ______
почему: ______________________

4. ВЫБОР СТРОК
когда есть: ______   панель: где ______   «все на странице» → ______
почему: ______________________

5. ПОДВАЛ
строк на странице: ______   выбор: ______   счётчик: ______
возврат из карточки: ______
почему: ______________________

ВЕЗДЕ
длинные значения: ______   узкий экран: ______
загрузка: ______   пусто: ______   ошибка: ______

ИСКЛЮЧЕНИЯ
таблица ______  что ______  почему ______

ЖУРНАЛ ИЗМЕНЕНИЙ
версия · дата · что изменилось · почему · что привести к правилу

Часть 3 · Привести два экрана, 60 минут

1. Выберите две таблицы с самым большим числом отличий в сводке.
2. Переделайте их по правилам и выпишите каждое изменение со ссылкой на номер правила.
3. Отметьте, где правило пришлось поправить, и запишите это в журнал изменений.

Часть 4 · Проверка другим дизайнером

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

Что должно получиться

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

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

Частые сложности

• «Каждая команда считает свою таблицу правильной». Не выбирайте между таблицами — выбирайте по причинам. Вариант, у которого есть причина, становится правилом. Вариант без причины уходит, чей бы он ни был.
• «Правила уже есть в дизайн-системе». Проверьте, отвечают ли они на вопросы сводки. Обычно в системе описан компонент — как выглядит строка и флажок, — а поведение по умолчанию и то, когда таблица не нужна, не описаны. А в некоторых системах таблицы нет вовсе.
• «Разработка не успеет переделать все таблицы». И не нужно сразу. Новые таблицы — по правилам, старые — в раздел «что привести к правилу» с порядком по частоте использования. В Nielsen Norman Group советуют раз в год проверять согласованность всех экранов и чинить худшие расхождения, а с мелкими жить до переделки экрана.
• «Правила слишком общие». Проверьте их заданием для коллеги. Каждое место, где он спросил «а как здесь?», — недописанное правило.

Правила готовы, если

• Написаны по сводке всех таблиц продукта, а не по одной любимой
• Разделены по частям таблицы: панель, заголовок, строка, выбор, подвал
• У каждого правила есть строка «почему»
• Порядок по умолчанию задан по типу таблицы, а не один на всех
• Есть раздел «когда не таблица» с примерами
• Исключения записаны с причиной и местом действия
• Есть журнал изменений с разделом «что привести к правилу»
• Новая таблица коллеги по этим правилам совпала с остальными

Что мешает

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

На этой ступени таблица перестаёт быть отдельным экраном и становится общим поведением продукта.

• Data tableIBM Carbon Design System · на английском · бесплатноПравила таблицы данных IBM Carbon по частям: панель с поиском и кнопками, заголовки и сортировка, выбор строк и групповые действия, меню строки, страницы и высота строк. Действия строки там выносят иконками, если их меньше трёх.
• The Atomic WorkflowAtomic Design, Брэд Фрост, глава 4 · книга на английском · полный текст открыт на сайте книгиКак провести инвентаризацию интерфейса: по одному примеру каждого непохожего решения, по категориям, и показать разнобой всей команде — с этого начинается сводка таблиц. Это около трети главы; остальное — как продать дизайн-систему.
• Summary listGOV.UK Design System · на английском · бесплатноКогда вместо таблицы нужен список «поле — значение»: для ключевых фактов одной записи, а не для табличных данных. Там же — действия у строк, пропущенные значения и карточки для нескольких записей одного типа.
• Alphabetical Sorting Must (Mostly) DieNielsen Norman Group, Якоб Нильсен · на английском · бесплатноКороткая заметка Якоба Нильсена 2010 года: алфавит хорош, когда человек точно знает название, а для размеров, времени, важности и частоты нужен порядок по смыслу. Написана про списки и фильтры, правило то же и для таблиц.
• Maintain Consistency and Adhere to StandardsNielsen Norman Group, Рейчел Краузе · на английском · бесплатноЭвристика № 4: чем внутренняя согласованность отличается от внешней и как её удерживать — ревью с разными командами, проверка всех экранов раз в год, осознанный отказ от привычного. О таблицах в статье ничего.
• Дизайн-долг платежом красен: улучшаем таблицы в большом продуктеХабр, блог Ozon Tech, Александра Савельева, 2022 · на русском · бесплатноКейс Ozon Tech: как дизайнер добилась переделки старых таблиц — презентация руководству, компоненты, пилот на одном разделе — и что изменилось. Это история процесса, а не свод правил; панель выбора у Ozon стоит внизу.