Очень часто когда дизайнер, работая в фигме, использует дизайн-систему — он невольно начинает мыслить компонентами. Ему становится тяжело учитывать дизайнерские правила и подходы в контексте задачи. Он просто перестаёт о них задумываться.
Работа над задачей начинает сводиться не к тому, как подумать об изящном дизайнерском решении, а к тому — какие свойства есть у компонентов.
Чаще всего страдают классические правила вёрстки, ритм смысловых блоков, теория близости (правила внутреннего и внешнего), системы отступов, расстояния между текстовыми элементами — заголовками и абзацами.
Почему так происходит? Потому что дизайнер в фигме начинает оперировать компонентами с заданными атрибутами. Например: высота компонента с текстовым заголовком не равно фактической высоте текстовой строки этого заголовка. И здесь дизайнер отмеряет отступы между элементами дизайна не от базовой линии текстовой строки, а от размера контейнера, в который завёрнут этот текст. И у этого контейнера совсем другие параметры для позиционирования на макете.
Включается «мышление программиста». Дизайнер не выравнивает текстовые строки оптически так, чтобы соблюдались правила грамотной верстки, а он выравнивает эти строки физически, используя параметры компонента.
Да, макет собран на дизайн-системе. Но нет, макет не выглядит классно, потому что дизайнер вогнал себя в компонентное мышление, и элементы расположены на макете невпопад.
Это мне очень сильно напоминает, когда дизайнер не только рисует сайт, но он же лично его дальше и верстает в html. Из-за того, что дизайнер, обладая знаниями css, предвидит ограничения работы с div-блоками, а эти ограничения связаны только с тем, что этот дизайнер не обладает полным и гибким знанием html-верстки, то на момент создания дизайна, дизайнер себя сразу ограничивает в дизайнерских решениях, потому что думает не о дизайне, а о технической вёртстке.
Я это знаю, потому что сам был таким же. Когда моя работа как веб-дизайнера когда-то давно включала создание сайтов под ключ. И эту проблему мы обсуждали ещё двадцать лет назад с другими ребятами. То есть, когда тебе технически нужно запрограммировать сайт, то ты как дизайнер начинаешь для себя в будущем упрощать работу, потому что ленишься и экономишь свое же время на классных выверенных дизайнерских подходах.
Именно поэтому фронт-разработчики часто не любят дизайнеров за то, что те приносят им «сложные решения», в которых нужно попотеть. На самом деле, большинство таких решений реализуемы — вопрос лишь в подходах и о том, что программистам придется немножечко включить мозг. А от этого они и бесятся.
Когда роли разграничены, то дизайнер делает свою работу хорошо, думая о дизайне. А разработчик думает о своей части работы, думая о коде.
Фигма и работа с компонентами размывает эту грань и заставляет переключаться дизайнера с исконных дизайнерских правил и подходов сборки дизайн-макета на технические возможности сборки макета в фигме. Просто помните это, каждый раз когда работаете с дизайн-системами и компонентами.
