Таблицы в Figma. Дизайн Data Grid одной ячейкой

Строительство таблицы из компонентов — задача, которая рано или поздно возникает перед каждым разработчиком дизайн-систем в Figma.

Существует три подхода к дизайну таблиц, чтобы создать data grid с гибкой архитектурой. В каждом из случаев используется либо row-компонент, либо column-компонент, либо cell-компонент. Каждый из случаев подробно рассмотрим ниже.

Зачем всё это?

Зачем вообще всё запихивать в одну ячейку? Действительно ли среднему по размеру проекту требуется такая гибкость? Нужна ли компонентная архитектура для обычной таблицы?

Внутри большого командного проекта это единственный верный путь создавать новые data grid — через компонент. Это помогает генерировать больше вариантов и быстрее валидировать новые идеи.

Мои наблюдения показывают, что не все Figma-дизайнеры приучают себя работать с компонентами с самых ранних стадий нового проекта. Согласно недавнему опросу в Figma-чате чуть менее половины дизайнеров используют компоненты. Большая часть используют просто фреймы и copy-paste.

Но те, кому удалось переключить свой workflow на компонентный, скорее всего уже никогда не сделают шаг назад, потому что этот подход даёт больше гибкости и востребован среди организаций с собственным штатом дизайнеров. Хотите сохранить интерес к своей вакансии, если метите в крутую организацию, где уже работают в Figma — работайте с компонентами.

Тем не менее дизайнерам-фрилансерам я бы тоже рекомендовал использовать собственную библиотеку. Можно делать дубликат под нового клиента и через мастер-компоненты быстро стилизовать под конкретные задачи.

Стили таблицы

Когда я создавал свои уже не первые дизайн-системы в Figma, я пересмотрел сотни таблиц и мне удалось категоризировать наиболее часто используемые стили.

Классика

Горизонтальные и вертикальные разделители хорошо заметны, заголовки выделены bold’ом и отделены фоном от ячеек с контентом. Эдакий Excel-style

Контрастный заголовок

Разделители могут отсутствовать, либо могут быть только горизонтальными. Благодаря интенсивным заголовкам, такие data grid быстро разделяются взглядом, если их много на одном дашборде

Материальная таблица

Data-first подход. Такие таблицы можно встретить в material design. Более интенсивный верхний разделитель и однопиксельные внутренние качественно разделяют данные

Черезполосица

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

Минимализм

Ничего, кроме данных! Это вполне обосновано на плотных десктопных интерфейсах, где на счету каждый пиксель

Использование компонентов для создания таблицы

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

Row-компонент

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

С бордерами внутри каждой ячейки тоже предстоит поработать, различия присутствуют

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

Pros: высоту Row удобно регулировать. Идеально подходит для dashboard-проектов, в которых часто меняются горизонтальные состояния в проекте: onHover, onSelected, onFocus и так далее и специфика разработки требует частого переключения между ними:

Column-компонент

Впервые эта идея пришла мне в голову чуть более года назад и я реализовал её в поздних версиях Material Design System. Таблицу удобно было бы собирать из компонентов-колонок, внутри которой заранее предопределено и размножено N-количество рядов, а все лишние срезались бы за границей фрейма через опцию Clip Content. Тогда было бы достаточно потянуть фрейм вниз за нижнюю границу, чтобы показать больше дополнительных ячеек в колонке:

Cons: внутри компонента не удастся регулировать высоту каждой ячейки (горизонтальный шаг), так как иначе не получится реализовать «срезание лишнего».

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

Совет: можно держать три таких компонента с разным шагом: S-32px / M-48px / XL-64px , например, и в какой-то степени решить проблему плотности ячеек. Особенно полезно в случае создания и мобильных и десктопных темплейтов внутри одного проекта / team library.

Cell-компонент

Использование ячейки-компонента даёт максимальную гибкость в стилизации таблицы. Редко какой проект требует использования и Material-стиля, и классического для data grid. Но если вы фрилансер, который регулярно создает новые дашборды своим клиентам из собственной или коммерческой базы компонентов, то вам лучше начинать с ячейки, из которой вы вы будете кирпичик-за-кирпичиком создавать таблицы. Потом будет достаточно вложить четыре линии, прижать их по бокам ячейки, расставить constraints и генерировать новые стили.

Убер-фича: в своем iOS design kit for Figma, я могу все перевернуть с ног на голову через компонент :) Кстати, именно на основе templates из этого продукта и были сделаны материалы к данной статье

Cons: практически нет, разве что этот подход требует больше времени и навыков

Pros: максимальная гибкость, возможность управлять сеткой с помощью одного компонента, регулировать разделители, background, вложенные иконки и многое другое.

Подробный состав такой супер-ячейки я рассмотрю в следующем выпуске. Подписывайтесь на мой канал, там будут все анонсы!

Исходник с компонентами доступен тут.

В этой статье описан подход, который используется для секции таблиц в двух дизайн-системах: для iOS12 и для веба. За последние полтора года я сделал несколько качественных UI библиотек для Фигмы, которые значительно ускоряют дизайн-рутину.

0
15 комментариев
Написать комментарий...
Ферма Киви

Люблю статьи про Figma, побольше бы таких! Спасибо за материал

Ответить
Развернуть ветку
Artem

Люблю такие статьи. Высосать из пальца базовые вещи и такие «офигеть мы крутые». Жду статьи как держать отвертку в руках

Ответить
Развернуть ветку
Roman Kamushken
Автор

Привет скетчистам! Но холиваров не будет...

Ответить
Развернуть ветку
Кондрат Кондратенко

Я тоже на фигме. Но я тоже считаю, что эта статья — как держать отвёртку. Однако, это не умаляет её ценности для новичков, которые не знают, как работают компоненты.
Здорово ещё саму таблицу делать компонентой с колонками (сеткой) к которым можно привязывать объекты.
Ещё неплохо делать cell, из них собирать row, потом уже объединять в table, если нужно много более-менее типовых решений, у которых меняется только количество колонн, строк и их размеры и при этом чтобы можно было просто поменять стиль всех ячеек.

Ответить
Развернуть ветку
Artem

Эх, жаль, только я на фигме больше года :)

Ответить
Развернуть ветку
Андрей Курицын

А что, перевести нормально религия не позволяет?

Ответить
Развернуть ветку
Roman Kamushken
Автор

Перевести кому и сколько?

Ответить
Развернуть ветку
Майский жук

Андрею переведи. Сколько? Нормально!

Ответить
Развернуть ветку
Андрей Курицын

Текст читается как сухой перевод. Вот я и подумал, что перевести можно было и получше.

А оказалось это слог такой у вас. Был не прав.

Ответить
Развернуть ветку
Дмитрий Ковалев

за фигму автолайк

Ответить
Развернуть ветку
Lai Psov

А вот где в Фигме такая штука типа Anima, чтобы при изменении высоты компоненты или группы сами разъезжались?
PS лайк статье - без вопросов :)

Ответить
Развернуть ветку
Кинофестиваль Золотой-Феникс

Ага. Или paddle. Всем хороши компоненты, но гибкости не хватает категорически.

Ответить
Развернуть ветку
Roman Kamushken
Автор

Всё только начинается. Допилят и никуда не денутся.

Ответить
Развернуть ветку
Al Yu

ага, не волнуйтесь. Успеете еще такие фичи увидеть до пенсии

Ответить
Развернуть ветку
Roman Kamushken
Автор

Дел

Ответить
Развернуть ветку
12 комментариев
Раскрывать всегда