Хабрахабр

Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™

Недавно я выпендрился в комментариях и пообещал подробно ответить на вопрос о том, как дизайн-система упрощает взаимоотношения и нейтрализует конфликты между дизайнерами и верстальщиками (разработчиками). Привет, Хабр. Вот и отвечаю. Плюс рассказать о некоторых вариантах стандартизации именования слоёв. Про сетки. Подробно. Про иконки. Про компоненты. Про БЭМ. Про язык. Про артборды и вьюпорты. Про «фигмин» слэш и её же плагины. Про стили и палитры. Про типографику. Про экспорт растра. Про эффекты. Про распределение обязанностей. Про «мультиплеер». Осторожно, трафик: внутри много картинок, есть gif-анимации. Ну и немножко «о жизни, вселенной и вообще». Я предупредил.
А ещё много, действительно много нудного текста.

Дисклеймер, ради возможной экономии вашего времени:

Всё описанное — сугубо личное мнение, не подкрепленное никакими научными изысканиями. Автор — абсолютный ноунейм и не имеет опыта работы в крупных претенциозных организациях. Я не готов нести ответственность за ваше потерянное время, возможные убытки или упущенную прибыль. Весь мой субъективный опыт получен при работе над сравнительно небольшими проектами с гуманоидным ресурсом до 10 человек, плюс от волонтёрства в паре зарубежных проектов из тех, которые community-driven. Поехали.
И не буду возвращать вам ваши лучшие годы в случае, если вы их на меня потратите 🙂 Что есть, тем и делюсь.

Дизайн-система как средство разрешения конфликтов

Некоторые дизайнеры думают, что дизайн-система — это библиотека стилей. Договоренность о том, что «кнопки делаем красненькими, плашки — синенькими, а текст пишем Гельветикой». Кое-кто считает, что это набор заготовок из которых собираются макеты. Мол, вот так должно выглядеть модальное окно, а вот так — карточка товара. Фронтендеры идут дальше и включают в понятие техническую реализацию. Скажем, библиотеку компонентов на React’е. Всё это по-своему верно. Но это частности. Если копнуть, основная функция дизайн-системы — это выработка стандартов взаимодействия людей, которые работают над проектом. Поэтому она изначально призвана устранять конфликты. По крайней мере, я в это верю и хочу обосновать, пройдясь по всем основным больным мозолям.

Конфликт первый. Расстояния, размеры и отступы

Суть. Дизайнер лепит размеры неточно, верстальщик постоянно натыкается на разнородные и дробные значения. Непонятно, какие из них правильные, а какие ошибочные. «Фигма» не даёт измерять расстояния «линейкой».

Результат: задёрганный злой диз тратит часы на то, чтобы подвинуть на 1-2 пикселя сотни блоков на сотне артбордов. Типичное «решение». Все пинают дизайнера, пытаются заставить его быть внимательнее и тщательнее выцеливать пиксели. Итог всё равно не идеален, верстальщик всё равно недоволен, сроки уезжают, клиент теряет деньги, все переругиваются и разбредаются жаловаться друг на друга по профильным форумам.

Продумать или постепенно наработать удобные сетки, унифицировать макеты (в техническом смысле), правильно использовать библиотеки стилей и компонентов. Реальное решение. Создать дизайн-систему и принять её. Кроме того, чем дальше, тем больше у обоих накапливается готовых компонентов и стилей/миксинов, которые просто копируются из проекта в проект. Результат: дизайнер Акела по-прежнему регулярно промахивается, но верстальщик может определить большинство расстояний даже на глаз, не глядя в свойства блока.

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

4px. Кратность — сестра таланта

Первый слой сетки всегда одинаковый: 4px grid. По сути, я работаю с «масштабными пикселями», которые состоят из 4x4 обычных. В результате любой элемент макета, кроме линий (обводок, бордюров, аутлайнов, hr и т.п.) всегда имеет размер, кратный четырём.

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

Случайности неизбежны, но наличие системы позволяет верстальщику отличать косяки от умышленных изменений. Это не значит, что можно расслабиться и лепить макеты левой пяткой мимо сетки.

Почему именно 4?

Потому что. В принципе, это может быть любое число: хоть 5, хоть 3, хоть 10. Единственный критерий: удобство использования. Чётные числа удобнее, поскольку размеры вьюпортов и носителей почти всегда выражены в чётных числах (и нередко кратны четырём). Кроме того, есть ещё интерполяция при масштабировании растра, но это не так уж важно.

Если взять больше, будет проблемно верстать мелкие элементы. Главное, что число 4 достаточно мелкое, чтобы быть универсальным, и достаточно крупное, чтобы существенно снизить разброс всевозможных значений в макете. Это излишне крупный шаг, хочется мельче. Например, при базе в 10px паддинги внутри полей ввода получились бы довольно конскими, а выбор интерлиньяжа для текста — скудным. Но решать вам. Эмпирически все давно распробовали 4px, и вряд ли вы изобретёте что-то более универсальное.

Вертикальный ритм

Базовый интерлиньяж

Теперь нужно определиться с базовым интерлиньяжем — высотой строки, которая создаст вертикальный ритм и в дальнейшем будет влияет на высоту большинства элементов. В результате мы «разлинеиваем» макеты по вертикали.

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

Но чаще всего я использую либо 16px, либо 24px. Интерлиньяж может отличаться в разных проектах. Вы можете придумать что-то своё, держа в уме, что числа должны быть кратны вашей базовой пиксельной сетке.

Так что формально мы используем интерлиньяж 32px. Обратите внимание, что при 16px текст фактически занимает не в одну строку, а в две. Просто разбиваем каждую строку пополам, чтобы было удобнее работать с мелкими элементами. Но с точки зрения ритма это одно и то же.

Стандартные значения высот

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

На случай проблем с загрузкой картинок и арифметикой:

Еще одна причина любить именно эти две разлиновки заключается в том, что они пропорциональны друг другу: три строки по 16px равны двум строкам по 24px (16 * 3 = 24 * 2). Это позволяет тягать некоторые компоненты между ними, не теряя общий ритм. Например, иконки размером 48x48 прекрасно ложатся на обе сетки. Как нетрудно догадаться, универсальными будут и все числа, кратные 48: 96, 144, 192 и т.д.

На практике после 2-3 проектов они порабощают ваш мозг и намертво впечатаются в подкорку. Не нужно бояться тьмы непривычных чисел.

Высота модуля и гаттера

Замечу, что стандартизация не означает тотальное однообразие. Мы регулируем базовые значения, да. Но никто не мешает варьировать пропорции модуля как угодно. Вот для сравнения два примера:

А справа модуль повыше, 5 строк. Слева мы сделали высоту модуля равной двум строкам и получили очень «плоскую» сетку, которая удобна для верстки форм, таблиц, списочных интерфейсов и прочих подобных вещей. Подойдет в тех макетах, где много галерей, горизонтальных карточек, баннерных блоков, картинок.

Gutter — «желоб», «канавка»] — это то, что обычно называют межмодульным расстоянием. Гаттер [англ. Чаще всего это будет 1 строка. Его высоту тоже всегда делаем кратной базовому интерлиньяжу. Но если, например, макет пафосный и состоит по большей части из из огромных картинок, можно разделять их высоким гаттером в несколько строк.

Как видите, мы по-прежнему создаём довольно разнообразные сетки, но все они сочетаются друг с другом и библиотеками компонентов, потому что у них общая ритмическая база.

Все числа по-прежнему кратны базовому интерлиньяжу (16px) и входят в наш «магический» стандарт. Важно, что с точки зрения верстки разницы практически нет. Так что модуль это просто визуальная пропорция, которая помогает быстрее набрасывать элементы на макет и вычислять их габариты на глазок.

Итак, есть 2 стандартные сетки с интерлиньяжем 16px. Давайте потестим на небольшом примере. Высота модуля в левом макете 2 строки, в правом — 5 строк. Высота гаттера — 1 строка (16px). Можем ли мы теперь определить правильные вертикальные размеры/отступы элементов, не глядя в их свойства?

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

Влияет ли это на работу верстальщика? Теперь давайте представим, что дизайнер ошибается где-то на пиксель или даже два. Верстальщик видит сетку, верстальщик собирает проект по ней. Нет, не влияет. И бог с ним, с тремором дизайнера. Точка. Нет проблемы, нет конфликта)

Горизонтальный ритм: гаттер, колонки, поля

Гаттер

Схожим образом, выбираем горизонтальный размер гаттера, кратный 4px. Чаще всего я делаю гаттер квадратным (16x16). Но если нужны более широкие отступы между колонками, можно взять любое другое значение: 20px, 24px, 28px, 32px… и т.д.

Если сделать его ширину равной 20px, то весь «магический стандарт» для горизонталей изменится на «10, 20, 30, 40...». При этом гаттер становится базой для горизонтальных расстояний по аналогии с интерлиньяжем. В целом, я бы рекомендовал не мудрить и делать гаттер либо квадратным, либо кратным интерлиньяжу. Но, честно говоря, это неудобные цифры, будет сильно не хватать мелких паддингов и всякого прочего. Проще работать с одним набором стандартных чисел, чем с двумя.

Колонки и их респонсивность

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

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

В настройках сетки это выглядит так: количество «auto», ширина — произвольное число, которое подбирается исходя из размеров артборда и гаттера. А можно руками задать ширину колонки, чтобы получить разное число колонок на разных вьюпортах (классика: 4 на мобильных, 8 на «таблетках», 12 на десктопах, 16 на широких экранах).

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

Кто решает, как ведёт себя сетка

В идеале — дизайнер. Если он UI/UX. Потому зачастую дизайн адаптивный, а не просто резиновый, и желательно, чтобы было какое-то единообразное поведение всего лейаута. Но важно, чтобы верстальщик заранее получал информацию о том, какую из схем вы решили применять в конкретном проекте, и мог при необходимости высказать своё мнение.

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

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

Брейкпоинты и размеры основных фреймов

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

В эпоху «Фотошопа», и даже всего год назад, это было проблемой для многих:

В просторечии «резиновый», тянется. С «Фигмой» стало на порядок проще, потому что холст респонсивный. Но часть вопросов всё равно осталась.

Кто-то подгоняет артборды под дефолтные значения «Бутстрапа», кто-то отталкивается от контента. Кто-то берёт стандартные разрешения экранов прямо из «Фигмы». Подгоняю размеры холстов так, чтобы они чётенько легли в сетку и всегда работали всё с теми же «магическими» числами. Я же в этом вопросе немного велосипедист.

Почему делаю артборды произвольных размеров

Во-первых, я уже не считаю правильным рисовать резиновый макет точно под вьюпорт. Пару лет назад прочёл отличную статью «The 100% correct way to do CSS breakpoints». Долго прожёвывал, но в итоге принял точку зрения автора. Вкратце: при обычном подходе в точках брейкпоинтов все элементы макетов оказываются в экстремальных состояниях (минимальная ширина или максимальная ширина), тогда как для популярных вьюпортов хотелось бы получить «нормальные» средние значения, более естественные. Поэтому брейкпоинты лучше располагать между популярными ширинами экранов, а не точно на них. Соответственно, минимальная ширина макета берется чуть меньше вьюпорта, а тянется она чуть дальше. Звучит заморочено, но смысл там есть.

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

То есть адаптировать макеты под вьюпорт они и сами умеют. В третьих, вопреки стереотипам, те верстальщики, с которыми я работаю, чаще просят пояснений для широких экранов, чем для узких. Их больше волнует, чем и как будем заполнять «лишнюю» площадь.

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

Расчёт оптимальной ширины макета

  1. Определяем приблизительно желаемую ширину под ближайший вьюпорт. Например, в качестве минимального экрана меня устраивает любая ширина в диапазоне 290-320 px, а для десктопа, скажем 1100—1300px. Интересует в основном нижняя планка, т.к. растянуть колонки в плюс или добавить «уши» не проблема.
  2. Прикидываем желаемое число колонок. Для мобильного обычно беру 3 или 4 (от контента, какого там больше: чётного или нечётного), а для десктопа — 12. (В статье про сетки уже рассказывал про интересный 24-колоночный вариант, но он специфичен, для простоты не берем его в расчёт).
  3. Вычитаем из желаемой ширины все гаттеры и поля (гаттеров получится на 1 меньше, чем колонок, а поля два — примечание Кэпа).
  4. Оставшееся число делим на число колонок, получаем примерную необходимую ширину колонки.
  5. Округляем примерную ширину колонки до ближейшего стандартного «магического» числа. Получаем удобную ширину колонки.
  6. Считаем оптимальную ширину макета: все удобные колонки + все гаттеры + поля.

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

В результате типовая ширина артбордов будет: 304px, 592px, 1168px, 1552px. Чаще всего, для веба я использую колонки шириной 80px. И квадратный гаттер 16px. Фоновые растровые картинки готовятся с запасом. Естественно, каждый макет без проблем тянется в большую сторону. Довольно удобно, претензий по этому поводу обычно нет.

Дополнительные слои сетки

Иногда поверх обычной сетки накладываются дополнительные направляющие, которые помогают более гибко управлять расстояниями или показывают какие-то ограничения. Например, в один из моих стандартных мобильных артбордов (304px) входят «рельсы» отступов 16px и 48px, чтобы удобнее ложились иконки и текст. А условно безопасная область «первого экрана» отмечена зеленой горизонтальной линией.

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

Иконки

Иконки хранятся на отдельной сетке с собираются через промежуточный компонент-обертку. Сами картинки иконок — масштабируются. Иногда это нужно, чтобы использовать некоторые из них в качестве иллюстрации, буллита и т.п. Но обертка всегда фиксирует их размер и обеспечивает поля безопасности. Когда компонент иконки (обертка) тянется, сама иконка остается нормальной, т.к. внутри обертки всё выравнивается по «center», a не «scale». Обертки могут быть нескольких размеров.

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

раздел про именование слоёв). (Как сгруппировать — см.

Кое-что незачем класть в сетку

Очевидно, что из всех «красивостей» существуют исключения. Например, нет никакого резона вымерять отступы между элементами инлайнового меню, если сама их длина варьируется («grow horizontally»). Эти расстояния вычисляются автоматически и на уровне «Фигмы» (когда вы используете «Arrange -> Ditribute horizontal spacing») и на уровне вёрстки (flex’ом, например). То есть никому их точные значения вообще не нужны. Единственное, что требуется — это как-то дать понять верстальщику, какого поведения вы ждёте от этих пунктов. Для этого есть комментарии. (Или метки в именах слоёв, или сопроводительные письма, или просто предварительные договоренности — главное, чтобы канал коммуникации был всеми принят).

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

Как использовать компоненты так, чтобы все были довольны

  • Надо назначать каждому слою правильное поведение (выравнивание и способ масштабирования). Проверять поведение, потягав туда-сюда не только сам компонент, но и весь артборд (бывают нюансы с группами). Это снимает большинство вопросов по респонсивности макета, плюс помогает найти проблемные места как в самом дизайне, так и в архитектуре компонентов.
  • Не надо пытаться загнать в компоненты абсолютно всё. В любом проекте есть специфические вещи, которые используются однократно или имеют риск погибнуть в боях с правками заказчиков — не завязывайте на них родительские библиотечные компоненты, чтобы не зависеть от ненадёжных и слишком нетипичных узлов.
  • В мастер-компонентах нужно особенно тщательно следить за всеми отступами и настройками Если вы случайно собъёте выравнивание иконки в экземпляре (копии) — это ерунда, которая не повлияет на вёрстку. Если же вы косякнёте в мастер-компоненте, ошибка может переползти в библиотеку и все зависящие компоненты.
  • Верстальщик должен работать только с мастер-компонентами. (Или некими их эталонными копиями, если вы боитесь за сохранность оригиналов). Лично я обычно делаю в проекте специальную страницу для верстальщика, и выношу туда все мастер-компоненты, а заодно и всякие комментарии к ним.
  • Если вы осознанно модифицируете компонент, то его нужно оборачивать в новый мастер-компонент. Либо создавать эталонную копию в какой-то специальной области (странице, фрейме, библиотечном проекте).

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

Конфликт второй. Именование (слоёв, артбордов, стилей, файлов)

Суть. Дизайнер не заморачивается именованием слоёв или именует их от балды. Верстальщику трудно находить нужные слои в списках вида «Rectangle1, Rectangle2, ...». Проекты не структурированы или плохо структурированы. Непонятно, где искать тот или иной экран или компонент.

Выбрать одну из готовых существующих систем именования (например, БЭМ). Решение. Договориться о самых общих принципах (язык, структура страниц). Собирать дизайн на компонентах. Использовать возможности «Фигмы» и плагинов для группировки, поиска и переименований.

Английский язык, латиница

Если у вас более-менее англоговорящая команда, сильно рекомендую именовать всё на английском языке и избегать кириллицы. Даже если вы в данный момент работаете только на внутренний рынок.

Во-первых, это позволяет приблизить макеты к верстке: синхронизировать имена компонентов с классами, а стилей — с миксинами.

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

Тут как в той шутке: «No one thinks a toilet paper is a perfect gift until they need one». Мне понятны контраргументы, но я к этому пришел на практике.

Именование. БЭМ-нотация

Соглашение по именованию БЭМ.

Почему именно оно?

  • Потому что именование разработано для вёрстки (CSS), а дизайн в «Фигме» это по сути не что иное, как вёрстка, упрощённая и урезанная ради возможности управления CSS-свойствами через GUI.
  • Потому что эта нотация довольно распространена. К синтаксису привык и я, и все верстальщики, с которыми я работаю. (Это не значит, что БЭМ должен всем нравиться; речь о том, что эта нотация большинству коллег понятна. Если у вас есть альтернатива — пользуйтесь, да и всё. Главное, чтобы удобно было всей команде, а не кому-то одному).
  • Потому что синтаксис не конфликтует с фишками самой «Фигмы» (группировкой слоёв и др., см. ниже).
  • Потому что это позволяет приблизить структуру проектов в «Фигме» к структуре проекта на фронтенде (общие имена компонентов, миксинов, модификаторов и т.д.).
  • Потому что принцип универсален и работает на любых строках: можно именовать хоть артборды, хоть файлы, хоть страницы.

Важно то, что мы ищем не идеальную систему, а универсальную. Такое именование слоёв не имеет практического смысла в плане экспорта CSS: мы всё равно не можем конвертировать их в готовую разметку. Но мы этого и не добиваемся.

Чтобы в меню не вываливалось по 10 слоёв или компонентов с одинаковым названием. Нам нужно, чтобы дизайнер(ы) и верстальщик(и) просто понимали друг друга и работали на одной волне. Чтобы людям не приходилось ломать голову, придумывая свои названия для одних и тех же вещей. Чтобы, увидев в переписке «nav-menu-item_active», верстальщик сразу понимал, о каком конкретно компоненте идёт речь. Короче, стандарт, а не идеал. Чтобы компоненты в библиотеке «Фигмы» совпадали с библиотекой компонентов в исходниках сборки, хотя бы по ключевым позициям.

Но скорее всего, в итоге всё равно придёте к чему-то подобному. Вы можете пытаться изобрести что-то другое, более «простое». Если у вас есть обкатанное альтернативное решение, форма комментария в вашем полном распоряжении 🙂 Хотя решать вам, безусловно.

Как примерно это выглядит на практике

Это не так сложно, как выглядит. Пусть вас не смущают слэши и прочие странные значки.

Связка «&__» означает, что слой является «Элементом» (в терминах БЭМ). Амперсанды (&) я заимствовал из синтаксиса Stylus (sass/less), где они эквивалентны родительскому селектору. Это совершенно не обязательный префикс, мне просто так удобнее и привычнее, потому что в Stylus структура блока выглядит аналогично:

.widget-heading &__title … &__icon-menu …

Каждый компонент в терминах БЭМ считается Блоком. Поэтому в названии используются только дефисы и латиница, если вы используете классический синтаксис.

Например, «block_hover» — это компонент «блок» в состоянии :hover, а «widget_collapsed» — это компонент «виджет» в свернутом состоянии. Одинарное нижнее подчеркивание («_») в том же классическом синтаксисе БЭМ используется для обозначения Модификатора.

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

См. Слэши — это зарезервированные «Фигмой» символы, которые позволяют группировать компоненты. Их я вставляю, чтобы было удобно переключать состояния элементов (ховер, фокус и т.д.). ниже.

Ну а квадратные скобки — просто техническая метка, которая говорит о том, что этот слой является визуальным костылём (типа скругления уголков у бэкграунда) и что его не надо добавлять в разметку.

Что и когда нужно именовать, а на что можно забить

Теоретики рекомендуют именовать каждый слой при создании. В реальности, это было бы бессмысленным куском работы. Слои в проектах постоянно добавляются и исчезают, склеиваются и переносятся туда-сюда. Поэтому у меня принципы проще.

Строго именуются:

  • Артборды (фреймы корневого уровня).
  • Мастер-компоненты.
  • Все слои, которые входят в мастер-компонент. (Лайфхак: это делается не на этапе творческого поиска, а в момент создания компонента, когда вы уже наигрались и более-менее окончательно определились со структурой).
  • Стили текста, эффекты, именованные цвета — то, что структурируется «Фигмой» или используется в препроцессорах в качестве переменных или миксинов.
  • Те слои, смысл которых важен, но не ясен из контекста. Например, если вы хотите положить на бэкграунд гигантскую буквицу или использовать «x» в качестве иконки (такое себе) — такой слой лучше осмысленно именовать, т.к. это специальный элемент разметки, а не просто текст из одной буквы.
  • Контент-содержащие слои, которые непосредственно используются для экспорта и вёрстки: растровые картинки, SVG и т.д.
  • Фреймы, которые при верстке должны войти в разметку (обертки флексов, логические части макетов, типа сайдбара, aside, section и т.п.).

Вообще не именуются:

  • Визуальные костыли, которые не входят в компоненты и реализуются стилями и CSS-свойствами без доп. разметки (всякие там размывающие заглушки, плашки).
  • Текстовые слои, которые не являются частью мастер-компонентов.
  • «Рыбные» и декоративные слои, которые не нуждаются в экспорте. Типа стоковых фоток в имитациях контентной страницы.
  • Всякие обёртки и артборды, которые нужны только для удобной организации пространства или демонстрации каких-то технических заметок.
  • Внутренние слои SVG-графики, фигуры в составных контурах (union) и фреймах, составные части иконок и т.д. Они не считаются независимыми слоями, поэтому именуются только родительские объекты. (Если планируется внедрять инлайном и, например, анимировать, то такую графику лучше готовить в отдельных артбордах).
  • Копии компонента в больших наборах (типа элементов в списке) — они наследуют общее название от мастер-компонента, а индивидуализировать их бессмысленно.

«Я не могу, у меня лапки»

Иногда дизайнерам лень вникать в техчасть.

БЭМ, помимо прочего, помогает научиться думать компонентами, системно. На мой личный взгляд, UX-дизайнер должен если не уметь в вёрстку, то хотя бы понимать основные принципы и процессы. Так что имеет смысл потратить время на изучение даже не ради каких-то там слоёв, а просто чтобы уметь делать технологичный живучий дизайн, который легко переносить из проекта в проект и «перепродавать» раз за разом.

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

Фишки «Фигмы» и плагинов

Предполагается, что вы знакомы с «Best practices: components, styles, and shared libraries». И что вы уже достаточно взрослый мальчик/девочка, чтобы на многие из них забить и кататься на двухколёсных велосипедах.

Группировка компонентов, стилей и эффектов

В любом случае, от «Фигмы» мы обязательно берём слэши. Слэши — наше всё:

In the Styles menu, you will see your Local Styles and any Styles shared via the Team Library. To make finding and selecting styles easier, you can also organize your styles into groups by naming them with a slash naming convention. (Источник) Styles will be ordered alphabetically by Team name, then File name.

Итак, слэш разделяет «группу» и собственно «имя».

[Исключение составляет Слэш Хадсон, который разделяет «Gun’s & Roses» на группу и собственное имя, но потом передумывает].

В принципе, ежели вы шибко умный, эту систему можно назвать таксономией, а группы — таксонами. Например, слои «buttons/ghost» и «buttons/cta» декларируют именованную группу «buttons», а «mobile/paragraph» и «mobile/h1» — группу «mobile». Тогда вы не будете путать всё это с обычной группировкой слоёв, которая делается простым «Ctrl/Cmd + G».

Группы, созданные за счёт именования, автоматически подтягиваются в интерфейс, превращаясь в выпадающие списки (для компонентов) или секции во всплывающих слоях-окошках (для стилей и эффектов).

Нейминг в плагинах

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

То есть берём десяток экземпляров компонента с десятком слоёв, именуем всё в соответствии с требованиями плагина, а он подтягивает последовательно в них значения из таблицы: тексты, числа и даже картинки. Яркий пример — мощный с виду плагин Google Sheets Sync, который позволяет подтягивать в разные слои компонентов (!) данные из открытых таблиц Google. Я пока не пользовался этим плагином, но выглядит очень круто и перспективно. Синтаксис простой: решетка (ладно, октоторп) + название слоя. В принципе, мою систему он не ломает, т.к. Сразу решает уйму проблем с ручным заполнением товарных карточек, пользовательских профайлов и прочей повторяющейся «рыбы». добавить решётку в начало строки нетрудно.

Я не осилю обозреть их здесь, да и не всеми пользовался вплотную пока. Есть плагины для работы с (пере)именованием слоёв: Rename it, Layer names transform, разные нумераторы и др. Больше скажу, всё, что я тут накатал про сетки и остальное, в принципе можно воплотить в виде одного-единственного плагина, который будет сам генерировать соответствующие фреймы и стили на основе десятка настроек.
Плагины появились совсем недавно, от силы пару месяцев, но там уже полно вещей, которые облегчают жизнь в разы. Но очевидно, что при открытом API мы очень скоро получим уйму инструментов для автоматизации. Поэтому сильно рекомендую время от времени поглядывать в этот раздел. При этом открытое API наверняка приведёт к появлению новых аспектов именования и др.

Страницы и фреймы

Иерархия компонентов

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

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

Префиксы страниц

Как уже говорилось, я использую квадратные скобки как метки — там, где нужно показать, что нечто не относится непосредственно к главному контексту и является каким-то техническим моментом. В том числе, это касается префиксов страниц. Они бывают разные: [figma], [draft], [components], [prototype] и др. Каждый из них что-то значит для верстальщика.

“[Prototype]” обычно содержит кучу однотипных фреймов, которые демонстрируют логику отдельно взятого узла (корзины, пользовательского кабинета, системы регистрации и т.п) с использованием встроенных инструментов «Фигмы» для прототипирования. Например, «[draft]» (черновик), означает, что страница не закончена — всё может в любой момент поменяться, а значит, её содержимое пока нужно игнорировать.

Обычно на первом месте у меня находится «обложка» проекта — страница под названием «[figma] cover». А «[Figma]» означает, что данная страница нужна исключительно в целях совместимости с какими-то фишками самой «Фигмы». Оттуда берётся превьюшка файла в общем списке + иногда там делается что-то пафосное для презентации клиенту.

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

Корневые фреймы

С фреймами примерно та же история. что с компонентами. В названиях используются «блок» + «модификатор». Например, на скрине выше «cart», «cart_empty», «cart_thanks» и т.п., потому что логически корзина у меня является блоком, а остальные экраны — её модифицированными состояниями. Фреймы вьюпортов называются без затей: mobile, tablet, desktop, desktop+ и обычно хранятся в пределах одной страницы. Исключения бывают, но это уже слишком глубокие частности.

Типографика (стили текста)

Опять же, слэш. Группирую в три основных набора:

  • desktop — собственно типографика для обычного контента на десктопе;
  • mobile — угадайте;
  • ui — это стили текстов, которые используются в специфических элементах интерфейса и не зависят от вьюпорта (ну, например, цифры секундомера или шрифт инпута).

Соответственно, имена выглядят как «desktop/paragraph», «mobile/h2», «ui/timer», «ui/basefont», «ui/widget-heading_active» и др.

Палитра цветов, стили эффектов

Палитры у меня встречаются следующие:

  • theme — стилеобразующие цвета, основная гамма;
  • neutral — оттенки условно-серого, которые используются для текста, плашек, границ;
  • functional — цвета, имеющие функциональный смысл («ошибка», «успех», состояния ссылок и кнопок);
  • additional — комплект по возможности разнообразных оттенков, более-менее сочетающихся с основной гаммой, который используется в интерфейсах для маркировки статусов, индикаторов, выделения всяких списочных элементов, баннеров и т.п.
  • gradients — иногда градиенты и фоны выделяются в отдельную группу, просто чтобы не путать их с обычной заливкой и удобнее выносить в переменные CSS.

Именование всё то же: группа + слэш + название + модификатор. Например, «theme/primary», «theme/page-background», «func/link_visited», «func/warning_light».

Я использую не так уж много, по большей части тени двух-трёх видов глубины «shadow/_depth_deep» (всплывающие окна), «shadow/_depth_minimal» (мелкие тени у кнопок и т.п.), «shadow/_depth_mid» (средние тени, у выпадающих списков, панелей). Эффекты группируются по типу. Для внутренних теней добавляется модификатор inset.

Но, в целом, такой порнографии лучше избегать. К слову, второй модификатор везде отделяю плюсом («block/_mod1+_mod2+_mod3»), чтобы не путался со стандартной конструкцией «_модификатор_значение». А ля «shadow/_active-button». Если в проекте подобного много, то можно заменить кучу модификаторов одним общим осмысленным названием.

Чего надо старательно избегать

  • Крайне не рекомендуется привязывать названия (идентификаторов) цветов к конкретным значениям цвета («красный», «телесный», «лазурный» и т.п.). Название должно отражать функцию или область применения, а не фактический оттенок. Значение цвета может измениться в любой момент: редизайн, ребрендинг, новый менеджер у клиента. Поэтому имена типа «button/red» или «bg/yellow» не катят в большинстве случаев.
  • Не надо использовать цвета из одной палитры в целях другой. Например, если у вас есть белый цвет в бренде и такой же белый цвет в нейтральной гамме — технически это должны быть два разных цвета (две переменные). Сейчас они совпадают, да. А через год? А в тёмной теме?
  • Желательно также не допускать совпадения брендовых цветов с функциональными. Не надо «брендировать» ссылки — оставляйте их классическими сине-голубыми, подгоняйте только оттенок. Если гамма бренда всё-таки с чем-то совпала (красный бренд и красное соощение об ошибке), желательно максимально отдалить их оттенки хотя бы по насыщенности и яркости.

Конфликт третий. «Неверстабельные» стили и эффекты

Суть. Дизайнер создаёт цвета и градиенты путём наложения эффектов или изменения прозрачности. В результате верстальщик запутывается, вынужден сам всё проверять, брать цвета пипеткой и т.п.

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

Как помогает здесь дизайн-система

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

Когда точно знаешь, что в вёрстку пойдут только зафиксированные стили, невольно становишься внимательнее. Но. Да, огрехи могут остаться где-то в копиях, на каких-то отдельных артбордах, но сам экспортируемый стиль обычно приводится в приемлемый вид. Число вариаций оттенков снижается до адекватного. Тогда перед сдачей макета в вёрстку дизайнер проходится по всему списку стилей и подправляет шероховатости. При необходимости проверку можно просто включить в чеклист.

Его не волнуют частности и аномалии, если только они не оговорены специально (но уж в этом-то случае вероятность ошибки минимальна). Верстальщик же, повторюсь, работает с готовой палитрой.

Стили «Фигмы» — это личинки переменных для сборки

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

// named colors $clr-aqua = #057f99
$clr-aqua-light = #3ebca6
$clr-aqua-dark = #006B81
$clr-violet = #89288f
$clr-violet-deep = #361946
$clr-white = #fff
$clr-white-alt = #f1f4f6
$clr-gray-lightest = #e0f1f1
$clr-gray-light = #dde9f0
$clr-indigo = #5f2d7b
$clr-purple-pink = #a93897
$clr-purple = #89288f // default theme palette $clr-primary = $clr-aqua
$clr-primary_light = $clr-aqua-light
$clr-primary_dark = $clr-aqua-dark
$clr-secondary = $clr-violet
$clr-secondary_dark = $clr-violet-deep $clr-bg-primary = $clr-white
$clr-bg-primary_interlaced = $clr-white-alt // typography $clr-basefont = #1b262d
$clr-basefont_mid = #465666
$clr-basefont_light = #607080
$clr-basefont_pale = #b9c0c0
$clr-basefont_invert = #f1f4f6
$clr-link = #1383B4
$clr-headings = $clr-violet-deep // gradients $grad-primary = linear-gradient( -45deg, $clr-primary-light 0%, $clr-primary 50%, $clr-primary-dark 100%
) // Transparent main gradient is used as an overlay
$grad-primary_overlay = linear-gradient( -45deg, rgba($clr-primary-light,.5) 0%, rgba($clr-primary,.5) 50%, rgba($clr-primary-dark,.5) 100%
) // shadows $shadow-glow_mid = 0px 8px 16px rgba($clr-primary-dark, 0.3)
//...

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

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

О несовершенстве и перфекционизме

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

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

Конфликт четвертый. Экспорт графики

Суть. Дизайнер отдаёт макет, но у верстальщика не получается выковырять оттуда нужные графический материалы (растровые иллюстрации, фоны, иконки). Фигма не даёт забрать исходники, только обработанный экспорт, чего иногда недостаточно.

Верстальщик открывает папочку, находит необходимые материалы по названиям и генерит из них всё, что ему нужно: размерные вариации, спрайты и т.д. Решение. Дизайнер открывает папочку с исходниками и заливает полноразмерные оригиналы картинок (без компрессии) в директорию проекта на рабочем сервере (или в облаке) команды.

Иногда они нужны. К этому я пришел относительно недавно, когда выяснилось, что фигма никак не отдаёт исходники jpeg/png файлов, которые я заливаю туда с винта.

Откуда дизайнер берёт «папочку с исходниками»

Дизайнер достаёт её из того места, в котором готовил графику. Растровые картинки из растрового редактора. Векторную — из векторного. Не важно из какого конкретно, это дело дизайнера. Важно другое: полноразмерные файлы должны быть. Даже если что-то сделано в той же «Фигме» с помощью тюнинга изображения, надо экспортнуть оттуда и сохранить файлом. Векторную тоже, просто на всякий случай — пусть в облаке лежит. Это несложно.

А с чего это вдруг экспортом занимается дизайнер?

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

А с чего это вдруг верстальщик должен сам сжимать картинки?

Потому что этого компетенция, он в ней сильнее. Ну да, сейчас это уже скорее вопрос риторический, для симметрии. Кто у нас на сборке, алё. Кто, как не верстальщик, знает требования всех платформ и может автоматизировать своим могучим «Галпом» всё на свете? Конечно, это его вопросы. Дизайнеру туда не нужно лезть без необходимости.

Как немного упростить себе жизнь и тут

  • Хорошо спроектировать структуру проектов в облаке, чтобы всем всё было понятно.
  • Настроить синхронизацию. Дизайнер сейвит всё в свою папочку для экспорта, она автоматом летит в облако, а оттуда верстальщик тянет её себе в assets или ещё куда-то там. Это реализуется при желании даже на Гугл.Драйве.
  • [Спорно] Использовать версионность в именах файлов — тот же semver вполне применим и для графики. Грубо говоря, косметическая правка — это патч, смена содержимого — это минор, а изменение размеров и пропорций — это мажор. При необходимости такие файлы можно подтягивать в билды условной логикой и т.п. Но это уже сильно пахнет переинжинирингом.

Конфликт пятый. «Мультиплеер»: доступ к макетам, эффект наблюдателя

Суть. Дизайнер не даёт верстальщику прямого доступа к макету из опасания за сохранность дизайна. «Фигма» хочете денег за каждого нового дизайнера («редактора»). Дизайнеру не нравится работать, когда кто-то в мультиплеере наблюдает за его работой и елозит своим немытым курсором по священным артбордам.

Ну, либо «как всегда»: отдавать ссылку, чтобы верстальщик копировал файл себе в черновики кнопкой «Duplicate to drafts», что бесплатно и снимает вопросы по добавлению «редактора». Решение. Изолировать мастер-компоненты (вынести на отдельную глухую и забытую богом страницу и залочить «замками»), а для верстальщика приготовить вместо них «эталонные копии» — проверенные по чеклистам экземпляры, которые он сможет спокойно препарировать. Обладатели командных pro-аккаунтов «Фигмы» (насколько я слышал об этих олигархах 🙂 имеют возможность пользоваться библиотеками компонентов по всем проектам и настраивать доступ к каждому, так что там проблема снимается. Стеснительный дизайнер по такому же принципу спокойно работает в своих локальных файлах, а по готовности вываливает изменения в общедоступный файл.

И несмотря на все разговоры о былах временах и жалобы на времена и нравы, верстать макет, собранный на компонентах по дизайн-системе, в любом случае удобнее, чем 99% того хаоса, который приходил раньше в .psd-шках. Естественно, все эти подходы не лишены недостатков, но если вы используете систему сеток и прочее описанное выше, то работа верстальщика в «Фигме» становится намного проще.

От души рекомендую: изучите её горячие клавиши, особенно те, что предназначены для навигации по слоям и компонентам. Да, к слову, ещё момент для верстальщиков, мигрирующих из «Фотошопа», которые не распробовали «Фигму» и испытывают проблемы с производительностью труда. Я хорошо помню, что в первые дни знакомства с «Фигмой» сильнее всего раздражала именно необходимость «прокликиваться вглубь» компонентов ради выделения конкретного вложенного слоя. Это не блажь в данном случае. Но позже, когда освоился с «Ctrl/Cmd + Click», «Enter», «Shift + Enter» и прочим, всё стало намного комфортнее и удобнее. Прямо на стену лез. Здесь хоткеи это абсолютный must have.

Конфликт шестой. Кто должен делать то или это

Суть. Дизайнер пытается сваливать работу на верстальщика, в надежде, что тот будет чистить хвосты и устранять огрехи. А верстальщик навязывает свои потребности и живёт в надежде, что дизайнер «переучится» и начнёт жить и думать как технарь.

Разделить сферы ответственности, но объединить интересы. Решение. (Помимо всего, что выше).

То есть оба постоянно стремятся влезть в процессы друг друга и футболить задачи туда-сюда, но при этом не брать ответственность за эти самые процессы, потому что «это не моя работа». Изначально всё зачастую наоборот: люди пересекают свои сферы ответственности, но выделяют личные интересы. Это можно изменить, если придерживаться пары принципов и понять, что:

Дружба дизайнера и верстальщика неизбежна

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

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

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

Задачу выполняет не тот, кто «должен» или «виноват», а тот, кому удобнее и проще добиться нужного результата

Если нужно визуально переколбасить структуру документа, двигая блоки туда-сюда, меняя их местами и т.д. — это делает дизайнер в своем редакторе, потому что это проще, чем переверстывать лейаут. Если нужно пошаманить с числовыми значениями, сжать большую пачку jpeg’ов или, скажем, поэкспериментировать с таймингом анимации, это делает верстальщик, потому что средствами CSS/JS это удобнее.

Это типичнейший расклад. Классическая надуманная проблема из серии «кто должен экспортировать иконки» у полноценных специалистов сама по себе превращается в «Так, давай я щас всё сам экспортну быстренько, а ты пока допили вон ту хрень, чтобы мы к выходным смогли всё сдать». Я уже забыл, когда в последний раз ругался с верстальщиками, хотя на клиентов ору регулярно (шутка с долей шутки 🙂

Компетентность проактивна

Никто не любит, когда кто-то вмешивается в его дела. Это само по себе отличная мотивация. Если ты не хочешь, чтобы верстальщик «портил» твой гениальный дизайн, сделай так, чтобы ему пришлось как можно меньше с ним взаимодействовать. И наоборот, если ты действительно прошаренный верстальщик, не дури дизайнеру голову своими заморочками — ты из любого куска торфа конфетку сделаешь быстрее, чем диз поймёт, что ты от него хотел) Так в чём тут повод для конфликтов?

Как работает эта логика

Пример № 1

Я решил делать проект в ней. Предположим, «Фигма» — мой инструмент. И именно я должен буду найти для него решение. Если у верстальщика что-то с ней не склеится, то он вправе спросить у меня, как выйти из ситуации. Почему так? При необходимости пролистывая соответствующие мануалы, загугливая и даже тестируя. Предполагается, что из нас двоих именно я в ней царь-боженька. Да потому, что это моя «епархия». А значит и ответственность за эту сторону коммуникации на мне.

Это мой творческий процесс. И обратная сторона медали: верстальщика вообще не должно волновать, как я рисую макеты: в «Фигме», в «Люстре», в «Пэинте» или какашками на стенах. Но при этом я должен обеспечить соответствие между моим процессом и каким-то универсальным стандартом, который его устроит.

Сферы разделены, интересы общие — нет конфликта.

Пример № 2

Однажды я решил стать образцово-показательным пионером и пошел к одному хорошему верстальщику с вопросом: как мне лучше структурировать для него макеты. Тру стори. Проси, что хочешь. Мол, чего тебе надобно, старче. Я хоть с пээнгэшки заверстаю. Ответ цитирую дословно (извините): «Да пох*й. И восхитился я тогда мудростью святого старца и ушёл, просветлённый. Ты, главное, нарисуй».

Сферы разделены, интересы общие — нет конфликта.

Или наоборот: нытьё дизайнеров о том, что злой верстак заставил их переименовать «Rectangle 1» в «Button». Думаю, примеры пояснят, почему мне диковато слышать жалобы верстальщиков на то, что их дизайнер где-то там пару пикселей не вымерил микрометром.

Итого

Принципы дизайн-системы для решения конфликтов:

  • Используем «магические» стандарты для числовых значений.
  • Именуем всё правильно.
  • Фиксируем стили и палитры.
  • Храним исходники картинок.
  • Изолируем мастер-компоненты (если нужно).
  • Разделяем компетенции.

(Да, я раскатал это на несколько десятков экранов. Но иначе не получалось).

Надеюсь, вы сумеете извлечь из этого какую-то пользу для себя. Спасибо всем, кто осилил хотя бы часть.

Рекламировать мне нечего, но если вам непременно хочется пройти по ссылке в описании, то сходите, например, к этим людям:
kamushken — статьи про дизайн-системы и «Фигму»;
mkoloskov — статьи про БЭМ;
vasyay — статьи про управление студией.

S. P. Если статья была для вас полезной, не стесняйтесь сказать об этом в комментариях — они помогут понять, есть ли какой-то смысл писать для Хабра подобные талмуды.

Успехов!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть