Всем привет, меня зовут Зеленых Денис, я продуктовый дизайнер, арт-директор, директор департамента дизайна в DLS, преподаватель-ревьюер в Яндекс Практикуме, а также автор в блоге Практикума на Хабре. В этой статье я хочу поделиться своим методом организации библиотек и файлов в продуктовых дизайн-проектах.
Организация библиотек и файлов проекта важная и непростая задача. Особенно если приложение состоит из множества разделов, модулей, фичей и их сценариев.
Для сложных и неоднородных проектов я рекомендую использовать принцип «Атомарной матрёшки» при организации файлов дизайн-системы в Фигме или схожих приложениях. Этот принцип подразумевает особый порядок группировки библиотек и дизайн макетов, построенный на методологии «Атомарного дизайна» Бреда Фроста.
Атомарный дизайн — методология Брэда Фроста, которая представляет собой разбивку композиции сайта на простейшие компоненты. Они используются в проектировании всего сайта. Идея в том, что вы начинаете создавать дизайн не с макетов страниц, а с атомов — шрифтов, отступов, полей ввода, анимации и других мелких деталей. Атомы объединяются и образуют молекулы, организмы т.е. более сложные конструкции.
Изложенный принцип описывает общую концепцию построения макета. Я же описываю практический принцип организации дизайн-макетов в сложных проектах, позволяющий комфортно масштабировать макеты и проект.
Атомарная матрёшка — принцип построения макетов, согласно которому в основе каждого сложного макета со сценариями лежит набор более простых библиотек, подключенных друг к друг последовательно, образовывая нечто похожее на матрёшку. Что позволяет свойствам элементов «перетекать» из одной одной «матрёшки» в другую.
В основе сложной системы макетов следует расположить библиотеку примитивных составляющих системы: базовая единица, отступы и скругления, типографика, палитра и стили, иконки. Такую библиотеку можно использовать как для одного, так и нескольких схожих продуктов и даже коммуникационных материалов.
Далее на основе библиотеки примитивов следует построить библиотеку базовых компонентов: кнопки, поля, бейджи и т.д. Такие элементы следует представить вариантами, в вариантах можно сразу отобразить микроанимации и поведение таких компонентов. Следует поместить в базовую библиотеку наиболее используемые компоненты, которые будут встречаться практически во всех частях интерфейса.
Использование небольших и нетяжелых библиотек делает работу с ними более комфортной по ряду причин:
— Просто физически удобнее изучать или что-то искать в небольшом каталоге
— Если в команде несколько дизайнеров и их работа слабо пересекается — им будет комфортнее работать с набором компонентов, которые относятся к их части продукта
— У Фигмы есть ограничение на использование WASM-памяти. В одной вкладке Фигма не может потреблять более 2ГБ, превышение лимита приведёт к поломке файла, он просто не будет открываться. Вот что в Фигме говорят о памяти и особенностях её использования приложением
Так выглядят оповещения о том, что ваши файлы слишком тяжелые и в скором времени вы потеряете над ними контроль.
Так выглядит оповещение о том, что песенка спета и теперь нужно решать вопрос с запуском вашего файла через техподдержку. В общем, не нужно делать одну библиотеку или один файл и пытаться в него поместить все элементы проекта. Как говорится «Разделяй и властвуй».
Со слишком тяжелой библиотекой или любым другим файлов, в принципе, некомфортно работать. Файлы будет тормозить сам и другие макеты. Даже увеличение объёмов памяти на рабочих машинах не решит эту неприятную ситуацию.
В других редакторах графики, вроде Pixo, есть ограничение на размер файлов, лимит в два раза меньше чем в Фигме. Соответственно, там также не стоит перегружать файлы.
Организовав «базовые» файлы системы, следует приступить к организации файлов разделов или отдельных продуктов.
Для разделов или продуктов создавайте отдельные библиотеки шаблонов и паттернов, построенные на базовых библиотеках.
Так свойственные для раздела компоненты будут храниться в небольшой и удобной библиотечке, что позволит разгрузить основную библиотеку, а также исключить вероятность неожиданного внесения изменений в компоненты смежными командами.
Если в ходе работы выясняется, что компонент используемый одной командой в определённом разделе критически необходим всем дизайнерам — можно договориться о том, чтобы такой компонент переместился в библиотеку базовых компонентов.
В библиотеках шаблонов можно разместить готовые сложные лейауты, шаблоны экранов интерфейсов и паттерны.
Для реализации сценариев следует используйте набор вышеизложенных библиотек, так работа над макетами станет более эффективной, а масштабирование продукта или продуктов более комфортным.
Пара практических рекомендаций в развернутом формате
1 Организуйте систему библиотек
Определите где у вас будут находиться стили цветов и типографики, токены отступов и размеров, иконки и другие базовые сущности. Это может быть отдельная небольшая библиотечка (файл) или часть основного UI-kit.
Если принято решение сохранить стили в отдельную библиотеку – при создании библиотеки с UI-kit (с кнопками, формами и т.д.) просто подключите библиотеку со стилями и создавайте компоненты с использованием ранее созданных стилей. Такая структура библиотек может быть полезна если стили используются в разных UI-kit, при этом их можно разом обновить глобально через один файл.
Обязательно опирайтесь на принципы атомарного дизайна при построении компонентов в базовом UI-kit. Так структура элементов будет понятной и логичной.
При построении систем библиотек одна библиотека будет донором для последующей надстройки, получится некая «Атомарная матрёшка».
Например, вы создали библиотеку со стилями, которая поддерживает два UI-kit с базовыми элементами: кнопками, формами, бейджами и другими элементами. Далее вам необходимо сделать три раздела приложения с формами и кнопками, опираясь на набор базовых элементов UI-kit. А после чего, нужно сделать очень самостоятельный раздел приложения, условный интерфейс видеозвонков, с очень специфическими компонентами, которые будут использоваться только там.
Для такого раздела приложения следует создать локальную библиотечку, с набором шаблонов и паттернов собранных из компонентов базового UI-kit. И использовать такую библиотеку локально.
При описанном подходе ваша система библиотек будет выглядеть следующим образом:
«Библиотека стилей –> Базовый UI-kit –> Локальная библиотека шаблонов и паттернов»
Образовывается систему вложенностей, схожая с матрёшкой. Эти три библиотеки необходимо подключить к файлу в котором будет вестись работа над макетами.
2 Используйте абстрактные обозначения для свойств элементов
Для цветов следует использовать абстрактные обозначения, чтобы не было привязки к цвету. Можно называть токены цветов рандомными названиями, названиями с привязкой к элементу интерфейса. Так в тёмной или любой другой теме названия элементов не будут сбивать с толку пользователей.
Например, цвет фона «white» в тёмной теме будет уже не белым, а условный «blue» может оказаться светло-серым. Можно использовать для цвета фона название «surface» – такое название будет универсальным для любой темы.
Для выбора названий цветов можно опираться на принципы системы Метериал.
Также следует поступить с размерами заголовков, отступов, скруглений. Тут можно использовать систему маек. Для обозначения размеров используются условные значения: 4 – xxs, 8 – xs, 12 – s, 16 – m, 20 – l, 24 – xl, 28 – xxl и т.д.
Такие значения являются единым стандартом для всех сущностей дизайн системы имеющих разные размеры. Также это удобно при изменении фактических значений сущности – размеры изменились, а в документации указано условное обозначение размера, не нужно вносить много изменений в документацию.
3 Не засовывайте все возможные вариации компонентов в один вариант
Не нужно делать слишком сложные варианты компонентов. Все скрытие в них компоненты подтягиваются в ваши макеты при использовании варианта. Так макет становится тяжелее и Фигма начинает лагать. В силу того, что это веб-приложение и оно не может использовать более 2ГБ WASM памяти в одной вкладке. Даже если в вас 1tb оперативки. Это описано в руководстве к Фигме.
Соответственно, делая слишком сложные варианты вы утяжеляете их, и при подключении их к макетам, даже если часть компонентов из варианта совсем не используется в макете – скрытые варианты перетягиваются на себя часть памяти. Вместо этого создайте группы вариантов.
4 Используйте несколько библиотек для неоднородных интерфейсов
Если ваш продукт неоднороден и в нём встречаются макеты, которые собираются из совершенно несвязанных шаблонов компонентов – делайте для таких интерфейсов отдельные небольшие библиотеки и подключайте их локально.
Т.е. локальная библиотека компонентов должна собираться из элементов базового UI-kit и далее локальные шаблоны хранятся в локальной библиотеке и используются в локальных макетах. Так ваша основная библиотека будет легче, а итоговые макеты не будут лагать.
Например, интерфейсы звонков логически не связаны. Соответственно, есть смысл поддерживать эти интерфейсы разными библиотеками.
5 Избавляйтесь от лишних группировок и ненужных скрытых слоёв
Лишние группировки и ненужные скрытые слои делают документы Фигмы более тяжелыми и неповортливыми, съедают ценные ресурсы компьютеров дизайнеров. Слишком тяжелые макеты могут вовсе перестать открываться. Ну, зачем оно вам надо.
6 Подписывайте компоненты в единой стилистике, используйте группировки вариантов
Определите в каком формате вы будет подписывать элементы макетов: c большой буквы, с маленькой буквы, формат сокращения названий и т.д.
Используйте для схожих элементов макета одинаковые названия и прописывайте через «/» название модификации. Что-то вроде принципов БЭМ.
Например, в библиотеке используется два типа схожих элементов, они представлены вариантами компонентов. Назовите варианты одинаковым названием, а через «/» название модификации: user card / chat member и user card / chat admin.
Так проще искать схожие компоненты, переключаться между ними, при этом все возможные вариации компонента не помещены в один вариант, что делает компоненты легче и удобнее для эксплуатации.
7 Подписывайте все элементы макетов
Все, даже самые малые части макетов следует подписывать понятными названиями, заголовки можно подписать наименованием стиля, группировки внутри кнопки содержимым такой группировки: «icon & title». Чем информативнее названия, тем проще осуществлять навигацию в слоях. Это важно.
В вариантах компонентов также подписывайте все состояния понятными названиями, вместо «Property 1» и «Variant 1».
Название должно раскрывать суть состояния или тип элемента. Например, «state=default, state=hover, state=focus, state=selection, state=pressed, state=loading, state=disabled» — для состояний элементов. И «type=2 buttons, type=3 buttons, type=no buttons», — для вариантов разного формата.
На сегодня у меня всё, используйте «Атомарную матрёшку», делайте хорошо, а нехорошо не делайте.
Интересуетесь дизайном привычных вещей — подписывайтесь на мой канал в Телеграме: Lorrrem | Дизайн привычных вещей