Как стать автором
Обновить

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

Время на прочтение 31 мин
Количество просмотров 75K
Всего голосов 43: ↑42 и ↓1 +41
Комментарии 36

Комментарии 36

Спасибо за статью. По собственному опыту бывают ситуации когда 4px сетка не спасает, тогда нужна дублирующая сетка, особенно когда элементов и конструкций много.
Я это прочел. фух. Как маркетолог, не дизайнер и не фронтендер, могу сказать, что абсолютно не понимаю требований пиксель перфект?! 90% сайтов резиновые и даже имея фикс ширину основного блока, все равно остальной контент играет в зависимости от ширины экрана.
Я это осилить не смог, но по собственному опыту скажу, что такая вот «клетчатая дачная скатерть» совершенно точно будет мешать построению лейаута. Придётся постоянно отключать гриды, чтобы оценить «как смотрится» и потом снова включать, чтобы тестировать констрейны. Я бы рекомендовал просто сконцентрироваться на алгоритмичном вертикальном ритме, который был бы кратен 8. В 99% случаев этого достаточно, чтобы строить ровные и консистентные лейауты.
НЛО прилетело и опубликовало эту надпись здесь
Да нунафиг… Пока в этот Ctrl-Shift-4 прицелишься.
А если еще и многократно, пока тестируешь…
Причем тут вообще «4», непонятно…
НЛО прилетело и опубликовало эту надпись здесь
Думаю, четвёрку выбрали потому, что из всех клавиш-цифр она ближе всего к указательному пальцу при зажатых «Ctrl+Shift». Фотошоповский «Ctrl+;» плох тем, что правую руку нужно отрывать от мыши. Субъективно, подход «Фигмы» всё-таки удобнее после адаптации, хотя в первые недели я тоже вешался)

Про «дачную скатерть» сказано метко, но особой проблемы нет. Во-первых, сетка многослойная. Лишнюю разлиновку можно держать по умолчанию скрытой, если мешает. Во-вторых, «магнитная» привязка работает даже если сетка едва видимая или прозрачная. На скринах она ярче раз в 5, чем нужно — для иллюстрации.
Я, например делаю сетку чуть темнее основного фона, тогда совсем не мешает, в основном светло серую)
Как UI разработчик могу сказать что сам по себе «пиксель перфект» профита не принесет, да это не так важно для продукта. НО если стоит задача в стилистическом объединении продуктов, что бы пользователь их воспринимал цельно, важно что бы ничего не прыгало при переходя со страницы не страницу, что бы блоки и компоненты между собой соединялись. И так важно соблюдение дизайн системы. Условно если логотип уехал на 1 пиксель, то он во всех местах должен быть сдвинут на этот злосчастны пиксель. Но это не всегда даже про про пискели, а про любую измеримую величину: величину красного канала в rgb, размер шрифта в пунктах, прозрачность, а в ближайшем будущем и параметров вариативного шрифта.
Система вводится не ради «пиксель пёрфекта» (визуального), а ради стандартизации рабочего процесса. Со всеми её плюсами и минусами.

Представьте себе open source проект, в который могут коммитить совершенно посторонние люди. Там максимальный профит от стандартизации, потому что без неё каждый лепит по-своему. Кому-то нравится паддинг 5 пикселей, кому-то 3; кто-то считает с учетом border-box, кто-то нет и т.п. Никаких ресурсов не хватит делать ревью визуально для каждого такого коммита. А при наличии системы можно и людей обучить, и ревью частично автоматизировать.

В студии профит не так очевиден, но принцип тот же.
продуманный ui-kit / гайдлайн от этого куда эффективнее спасает, не?
Когда в дизайнах всё красивенько и кратно 4 или 8, а в реале получаем margin-top: 17px, то как-то печально получается.

Спасибо, хорошая статья. Мне как верстальщику приятно осознавать что где-то есть такие дизайнеры как автор:) Низкий поклон! Насчёт "магических чисел" всегда чувствовал некий дисбаланс, т.к. зачастую дизайнеры ставят размеры шрифтов и типографические значения, к которым очень хорошо назначить базовый размер 16px, но при этом паддинги и гаттеры идут бутстраповские, типа 15, 20px. Ещё один момент заметил в статье. Я не гуру в БЭМ, хотя очень его люблю. И мне всё-таки кажется, что Модификатор — это то что обычно ставят после "_", а то что идёт после имени Блока (после "") — это Элемент. По крайней мере я так делаю, на истинность не претендую. В любом случае спасибо, читать было интересно! Во многих конфликтах узнал себя и команду :)

Вроде всё так. Может, я опечатался где-то в тексте?

Классический синтаксис БЭМ:

// Модифицированный элемент блока:
.block__element_modifier

// Модифицированный блок:
.block_modifier


Если где-то текст не соответствует, тыкайте меня носом, подправлю :)
Спасибо за комментарий!
ну вот тут же:
Связка «&__» означает, что слой является «Элементом» (в терминах БЭМ).

должно же быть "&_" если это про Элемент.
А вот тут:
Например, «block_hover» — это компонент «блок» в состоянии :hover, а «widget_collapsed» — это компонент «виджет» в свернутом состоянии.

Я немного иначе понимаю. Опять же, я не профи в БЭМ, возможно я его неправильно использую, но я делал бы так: если есть блок widget, у него элемент title и нам нужно например его состояние collapsed. То я бы скорее отнес collapsed к Модификатору, соответственно получился бы widget_title__collapsed.

Да и я сам хорош — в своем комментарии получилась путаница, у меня там в скобках неправильно нижние подчеркивания получились:) Впрочем, как раз штука в том, что с этим я не совсем согласен:

// Модифицированный элемент блока:
.block__element_modifier

// Модифицированный блок:
.block_modifier


Я привык наоборот: block_element__modifier.
Наверное потому и глазала намозолило =)
Не :) В стандартном синтаксисе всё наоборот: двойное нижнее подчеркивание отделяет элемент, а одинарное — модификатор.

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

В принципе, если ваши коллеги не возражают, то можно и так, наверное. Но при смене коллектива та же путаница будет постоянно возникать. Возможно, есть смысл вернуться к классике :)
А вот за эту наводку отдельное спасибо — действительно я все напутал… С ужасом подумал о своих законченных проектах, в которых я вот так неправильно использовал БЭМ. =\ Впрочем, это были всего лишь мои попытки пробовать БЭМ моим коллегам было абсолютно все равно что я там использую. И если кто-то потом заходил править верстку/стили, то парочкой вложенностей тут же все ломал. «Какой такой БЭМ? Щас мы застилим в духе „div.row>a>span i. А зачем вообще в CSS придумали вложенность, чтоб ты потом свои километровые имена классов городил?“ =)

По-большей части все верно, спасибо. И отдельное спасибо за фразу со словами "немытым курсором", она зарядила меня с утра :)))

Илья, привет! Нам очень нужны такие люди как ты :) Не знаю где ты и над чем работаешь, но мы бы с удовольствием взяли тебя к нам в СМЕНу в частности работать над цифровой дизайн системой государства и на другие большие и интересные проекты :) Если интересно напиши мне плз ag@lab.ag

Спасибо за Ваш труд по написанию статьи. Для меня она оказалась той соломинкой, которая поможет не утонуть в океане информации. Перечитала и посмотрела бешеное количество информации по построению сеток. В итоге, была полная каша в голове. В статье дано чёткое объяснение: зачем, как и почему именно так для конкретных случаев. Кроме этого стало понятно, как верстать с макета на Фигме, на который я смотрела больше месяца, не зная с какого бока подступиться. Удачи Вам во всех делах.

Сеткодрочерам привет! :)

А всего лишь нужно научить дизайнера верстать, уволить верстальщика и Фигма не будет нужна. :)

Люди не уловили юмор, видимо)
К слову, если брать именно UI, то при жестком выборе из набора «дизайнер, верстальщик, „Фигма“» я бы оставил все-таки верстальщика :)

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

Интересно, минусуют дизайнеры, которые считают, что им не нужно уметь верстать или верстальщики, которые боятся остаться не у дел? :)

Спасибо за статью, осилила всю. Я дизайнер, было мало понятно с именованием. Придётся прочесть второй, а может и третий раз, чтобы понять и применять)

Хороший материал!
Вам не кажется, что понятие «дизайн система», должна исключать ситуации, когда дизайнер, может создать уникальный специфичный элемент, который никогда и нигде не будет переиспользован и будет жить сам по себе вне дизайн системы, брошенный и неучтенный?
Если уникальных специфичных элементов будет много, то где будет та системность, ради которой все создавали и создают «Дизайн Систему»?

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

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

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

Грубо говоря, например. Делаем на потоке промо-сайты, у каждого первый экран главной страницы представляет собой обложку с ярким коллажем с анимированными элементами. Логически такая обложка — компонент. Она есть на каждом сайте, имеет стандартное место в лейауте, стандартный размер, поведение брейкпоинтов и т.п. Но поскольку начинка обложки всегда разная (и в этом, собственно, её функция) унифицировать её толком мы не можем, да и выносить в библиотеку нет практического смысла, т.к. переиспользуется только голый фрейм.

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

Словом, дизайн-система и её техническая реализация дадут некоторую разбежку по-любому. Поэтому я сторонник того, чтобы стандарт вычленялся из кейсов. То есть стандартизировалось только то, что на практике повторяется и переиспользуется.
Спасибо за статью, все предельно ясно и понятно расписано. Работаю в основном в адоби XD, но все те же принципы работают и там.
В мире, где существует zeplin.io (и его аналоги), вообще непонятно зачем мучать фронтендеров работой с дизайн тулзами напрямую. Я уже 4 года как не трогал ничего кроме зеплина, мысли о работе с каким-нибудь фотошопом или фигмой вселяют в меня страх.
В принципе, что пнём о сову, что совой об пень :) Большая часть вопросов, упомянутых тут, не очень зависит от инструментария фронтендера и остается актуальной хоть с «Зеплином» хоть без него. Всё равно ведь компоненты надо как-то именовать, стандарты отступов и сеток согласовывать и т.д. «Зеплин» с «Фигмой» неплохо интегрированы. Глобальные стили из Ф уже импортируются, импорт компонентов тоже на подходе, вроде как. Но «Зеплин» не отменяет необходимость договариваться об именовании и приводить базу компонентов в какой-то единообразный вид.

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

Про именование вещей — вообще не понятно причем тут дизайнеры. Что творится в кодобазе это дело разработчиков. Фронтендеры сами должны принимать все решения на эту тему.
Полезная статья, крутой изложение, только моменты с расчётам несколько раз перечитывал :D
Спасибо за труд!
Спасибо за статью. И за ссылку на статью про гриды и брейкпоинты тоже.
Спасибо за то, что поделились Вашим опытом, все доступно объяснено.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории