Всем привет!
Я, Колядова Алиса, Senior дизайнер, работающая над B2B-системами внутри «одной из списка компаний, которые нельзя назвать».
В этой статье — мой путь через проектирование таблиц: от первых факапов до системных решений. Не будет чеклистов. Зато будут кейсы, выводы и немного боли. Некоторые мысли и инсайты в статье могут показаться для кого-то банальными. Ну тормоз я значит)
Открытие №1. Любую повторяющуюся структуру можно превратить в таблицу. Но не всегда нужно.
Когда ты впервые сталкиваешься с таблицей, тебе кажется, что она — просто способ визуализировать данные. Но с опытом приходит понимание:
таблица — это формат мышления.
Список активностей, история заказов, карточки клиентов — всё это потенциальные таблицы.
Но если контекст не требует табличного взаимодействия — не превращай всё подряд в строчки и колонки.
В какой-то момент всю команду разработки очень сильно увлекло таблицами: у нас появился понятный табличный шаблон, который просто разрабатывать. Скорость разработки табличного формата был в разы быстрее, чем компоненты и, когда к нам прибегал менеджер с глазами ASAP, команда выбирала таблицу.
Дошло до сюра, когда менеджер был согласен историю комментариев сделать в формате таблицы, потому что «ну надо срочна», а то что это будет неработоспособно и неудобно, никто не слушал.
У таблицы есть паттерн: пользователь сравнивает строки между собой, работает массово, применяет фильтры, ищет по структуре.
Если этого нет — таблица превращается в тормоз.
✅ Когда таблица - это решение.
Идет обработка большого объема данных. Это может быть таблица crm системы, админ-панель ( и другое).
- Нужно сравнивать строки между собой
- Пользователь работает с множеством строк
- Важна структурность и плотность
- Данные обновляются, редактируются
- Есть фильтры, сортировка, массовые действия
Необходимо учитывать бэкграунд пользователей. Иногда пользователи просто привыкли работать с таблицей. Им этот паттерн проще для восприятия.
Как понять какой бэкграунд пользователей:
- есть определенные сферы деятельности. К примеру, трейдеры - вот там у ребят вообще своя движуха. Там достаточно много сложившихся паттернов (особенно вокруг таблиц), которые ломать нельзя НИ В КОЕМ случае. Иначе гореть в аду будете еще при жизни, перекладывая пиксели из одного места в другое.
- финансово бухгалтерские штуки, особенно сотрудники бэк-офиса (сотрудники внутренних отделов компании, которые не взаимодействуют с клиентами
- Есть исследования пользователей о их специфике работы, как правило это хорошо работает для внутренних сервисов, когда у вас есть свободный доступ к внутренним сотрудникам и вы знаете как они работают чуть ли не по сценариям.
Можно ли превратить листинг товаров в интернет магазине в таблице в таблицу? Конечно. Но будет ли это удобно? Нет.
Да, у нас есть повторяющаяся структура:
фото,
цена,
название,
рейтинг,
кнопка “в корзину”.
Если бы этот интерфейс представить в таблице — мы бы получили что-то вроде Excel с фотографиями.
Работать с этим никто бы не стал. Таблица — это про обработку данных, а не про первичный выбор или визуальную привлекательность.
___
Открытие №2. Если таблица длинная — она не обязана быть одна
У нас была таблица с 16 колонками. Всё в одной строке. Интуиция и практика говорит, что нереально обрабатывать одновременно 16 параметров, они даже не везде в длину двух экранов не помещаются (стандартное разрешение 1280 у пользователей)
Hot fix: Прокрутка по горизонтали, но о ней в открытиях дальше.
Решение, к которому я пришла немного позже:
• Если у таблицы два сценария — сделай две таблицы.
• Если нельзя — выделяй группы, делай двухуровневые шапки, закрепляй нужное.
Сейчас максимально стараюсь разбивать таблицы по сценариям. Это помогает не только сделать таблицу более удобной, но и убрать / добавить колонки необходимые для конкретной ситуации.
У нас была таблица заявок. В ней указывалось все: которые надо принять, распределить, которые долго висят, еще какие-то. Чтобы понять что это за строка надо либо каждый день в ней работать, чтобы знать все эти значки и индикаторы, либо активно пользоваться фильтрами.
Нельзя одним взглядом на таблицу определить текущую ситуацию.
Сколько заявок надо принять в работу?
А сколько заявок сейчас в работе?
А примерно, сколько заявок долго в работе?
А есть то, что надо распределить?
В итоге одна таблица превратилась в 4 таблиц для разного типа работы, с дополнительными наборами данных.
Я не буду останавливаться на всех таблицах, расскажу про две взаимосвязанные. Первая - это входящие. По всем данным можно определить берем в раб��ту или нет.
Для этого не надо проваливаться внутрь карточки и там уже принимать решение => увеличиваем скорость работы.
Так же в идеальном формате эта таблица должна быть всегда пустой. Поэтому по дефолту она свернута, а рядом есть счетчик строк. Если 0 - все ок, работаем в стандартном режиме с активными заявками, число больше 0 - раскрываем и сортируем.
Из интересного, в этой таблице нет фильтров в колонке, а так же нет возможности выбрать сколько строк отображать на странице. И у каждого решения есть обоснование.
У второй таблицы не нужны действия, зато нужна цветовая индикация, чтобы на определенные колонки надо было обратить внимание. Строка вся заполнена - все хорошо, работаем. Есть прочерки - где-то чего-то не хватает, надо распределить или назначить (назначение из таблицы - это не целевое действие, несет больше контролирующую функцию), цветом выделяем то, на что надо обратить внимание. А уж если есть пустые строки и она желтая - ну все, трында)
Универсальная таблица — это миф. Пользователь работает с конкретным куском данных, а не всем массивом сразу.
___
Открытие №3. Объединение связанных данных может быть ловушкой
Достаточно много платформ предлагают в гайдах объединять данные.
Объединять ФИО и должность, номер и статус — звучит логично. И иногда это помогает. Но не всегда.
Если пользователь работает с большим объёмом строк, такая сборка ломает визуальный ритм и мешает искать нужное. Особенно если он не смотрит, а сканирует.
Решение зависит от сценария: в компактных таблицах — да. В рабочих таблицах на 200 строк — нет. Я в телеграмме уже рассказывала подобную ситуацию. Как-то раз пробовала объединять связанные данные и заодно, чтобы избавиться от горизонтального скролла, сделать механику разворота деталей.
Визуально выглядело лучше, чем было. Но на деле вообще не юзабельно.
1. Данные невозможно сравнивать. Да, моя ошибка была сгруппировать даже числа и какие-то даты. Но иногда необходимо даже сравнивать давность обновления информации. Поэтому, посмотрев критически на таблицу, стало понятно, что от объединения мы больше проигрываем, чем выигрываем.
2. Плотность информации ≈ ноль. В объединенном формате у нас помещалось условно 10 карточек на экран, в табачном формате при тех же исходных помещалось 21 строка.
___
Открытие №4. Горизонтальный скролл — не зло, но требует уважения
Если таблица уходит вбок, у тебя есть выход:
1. Определить, какие колонки “даёт контекст” (что это за колонки), и оставить их слева, чтобы было видно сразу же
2. Зафиксировать нужное:
• первую колонку — если скролл длинный
• действия и важные показатели — справа
Скролл сам по себе — не проблема. Проблема — отсутствие ориентира. А еще стоит учитывать любые нюансы.
Когда пользуешься маком, некоторые вещи кажутся само собой разумеющиеся, поэтому я просто прописала, что горизонтальный скролл должен быть, как только таблица выходит за пределы экрана.
Разработчик сделал по-своему усмотрению: скролл появляется только когда пользователь доскроллил до конца таблицы по вертикали.
А у нас...
В этот момент — бесконечная подгрузка. То есть горизонтального скролла ты можешь увидеть только на пару секунд, пока контент не прогрузится дальше. Неуловимый скролл.
Поэтому любую особенность необходимо прописывать его правила явно:
• когда он должен появляться
• как взаимодействует с виртуализацией или бесконечной подгрузкой
• фиксировать ли колонки
• на каком слое он должен быть
• виден ли он всегда или по ховеру
Иначе разработка может решить за тебя. А пользователь может пострадать.
___________
Я давно хотела поделиться своими знаниями по таблицам, но видать у меня пока что пост-травматический синдром. Оказалось, у меня накопился не список best practices, а жирный список факапов, из которых я наконец-то начала выруливать.
Да, где-то можно было бы покрасивее. Где-то — покороче. Где-то — не называть строку «трындец». Но это всё реальный опыт. С чужими ожиданиями, нашими компромиссами, болью разработчиков и постоянными «а можно срочно?».
Я не делаю вид, что знаю все ответы. Но теперь хотя бы знаю, какие вопросы точно стоит задать, пока не поздно:
- это точно таблица?
- это одна таблица или три?
- это для чтения или для работы?
- что будет, если человек попробует это на винде без тачпада и скроллбаров?
Если тебе знакомо это ощущение — когда ты открываешь таблицу в своём же продукте и не понимаешь, что происходит, — надеюсь, ты нашёл здесь пару полезных крючков.
Я продолжаю разбирать подобные кейсы в Telegram — Алиса, где макет?. Без рекламы, просто практика
