Главный по фронтенду в Меркури задает острые вопросы главному по дизайну. Собрали самые важные поинты из почти полуторачасового видео и получили список советов, которые помогут находить общий язык в спорных вопросах.
Почему надо всегда делать дизайн-систему, но на практике получается не всегда
Никто не спорит, что компонентный подход — это важно. Но на практике создание дизайн-системы занимает дополнительное время дизайнера, за которое заказчики не всегда готовы платить.
Чтобы создавать библиотеку компонентов, нужно добавлять дизайн-элементы по ходу работы над экранами, иначе получится эффект снежного кома. Не будет такого, что в один прекрасный день дизайнер соберет библиотеку из всего, что он рисовал до этого полгода.
Как только понимаете, что дизайн очередного экрана утвержден, добавляйте повторяющиеся элементы в компоненты. Чем больше компонентов соберет дизайнер, тем меньше времени будет занимать создание каждого следующего экрана. А разработчики будут знать, какой элемент можно переиспользовать, а какой придется верстать с нуля.
По возможности сразу создавайте библиотеку с темплейтами — со временем ее можно будет превратить в полноценную дизайн-систему. К счастью и Фигма, и Скетч позволяют легко настраивать зависимости и поведение лейаутов.
Как дизайнерам аргументировать свои решения
Нет, так не надо
К счастью, дизайнерам не обязательно рассказывать разработчикам всю теорию UX, чтобы объяснить свою логику. Как минимум можно аргументировать с помощью принятых паттернов.
Дизайнер продумывает состояния экранов заранее
Даже если нужно нарисовать только базовое состояние экрана, грамотный дизайнер всегда мыслит на пару шагов вперед: что будет, если пользователь нажмет не на ту кнопку или введет в форму что-нибудь не то. Тут как в арифметике — один экран рисуем, два в уме.
Например, дизайнер нарисовал форму регистрации и забыл заранее продумать экран, когда пользователь введет невалидные данные. В итоге где-то под формой дорисовал ошибку, и при заполнении начинается Layout Shift.
Как дизайнеру и разработчику понимать друг друга
Мало просто кинуть в разработчика макетами в надежде, что он прочтет ваши мысли. Оставляйте комменты и объясняйте коллегам свои решения.
Например, нарисовали форму с тусклой кнопкой. По задумке дизайнера она только выглядит задизейбленной, но остается кликабельной. Без комментариев разработчик вряд ли угадает это решение.
Неочевидные закономерности в дизайне, которые помогут разработчикам понять, что баг, а что фича
Размеры кратны четным числам
Все размеры должны быть кратны четным числам: двум, четырем, а лучше восьми. Это общее правило, но есть исключения на разных платформах.
Все по сетке
Интерфейс должен быть нарисован по сетке. Если это не так, скорее всего это ошибка, и дизайнеру следует подогнать макет.
Дизайнеры стремятся все универсализировать. Если разработчик видит, что в макете что-то выбивается, скорее всего, так быть не должно. А чтобы узнать наверняка, лучше всего спросить.
Два мнения об инклюзивном интерфейсе
Интерфейс нужно делать доступным сразу для максимального количества пользователей. Можно провести аналогию с городским благоустройством. Возможность двигаться по городу с детской коляской никак не ущемляет права обычных пешеходов. Никто не будет делать отдельный парк для колясочников — это глупость. Так зачем нам отдельная версия сайта?
Иногда нужно сделать отдельную опцию, например, для людей с ограниченными возможностями. Для них это полезно: крупный шрифт, контрастные кнопки и т.д.
Но для большинства пользователей это может казаться непривычным и неудобным. Ради эксперимента попробуйте взять в руки бабушкин телефон. Наверняка у нее установлен увеличенный шрифт, все разъезжается. Пользоваться таким интерфейсом то еще удовольствие.
Именно поэтому интерфейс для слабовидящих должен оставаться опцией, а не быть по умолчанию для всех.
Пара советов для дизайнеров напоследок
1. Всегда доносите свои идеи до разработчиков, а не бросайтесь в них макетами. Оставляйте коменты в Фигме с описанием, как все должно работать: то, что очевидно вам, может быть не так очевидно другому человеку.
2. Времени на сбор компонентов не будет никогда, поэтому старайтесь собирать компоненты или символы сразу по ходу работы. Затем постепенно превращайте их в библиотеки компонентов, а потом в дизайн-системы.
Мы собираемся записать обратный ролик с вопросами дизайнеров к разработчикам. Вы тоже можете поучаствовать и накидать свои вопросы. Если напишите в комментах, какие у вас есть боли и претензии — наш артдир Денис с удовольствием «предъявит» их ведущему фронтендеру 🙂
Мне кажется сидеть весь день и обсуждать с разработчиком пол дня почему сделали так, как в примере например, почему скролл горизонтальный, не ок. Если так обсуждать каждую фичу, то когда макеты рисовать? 😅 а еще и бывают разрабы которые на любой макет любят отвечать "мы так не сможем" 😬
Согласен с вами.
"Я — художник, я так вижу" - обычно такие люди получают ногой под жопу и оказываются на улице. Те кто пытаются себя обозначить как UI/UX Designer, в большинстве своем неучи.
Любой подход к решению вопросов или головной боли заказчика это 99% аналитика и только 1% - дизайн.
Если у вас в команде такие "разговоры" то дизайнера на улицу с вещами, девелопера - с вещами на выход, и руководителей с лидом на мороз.
Согласен, но 1% если переносить в единицу времени не совсем реален, в будущем точно так и будет, когда можно будет генерировать дизайн написав или надиктовав голосом ТЗ =)
Как отвечать на претензии разработчиков, "что мы так не можем"? Как понять или выяснить, что это не банальная Лень, а реальные ограничения проекта. ?
А спрашивать у разработки "почему" не пробовали? Серьёзно, я столько слышал нытья от дизайнеров про это "мы так не можем", которое на деле выливалось в ответ фронта " Вы, уебы, шестой вид кнопки на странице впендюрили и 635ый на проекте, мы уже так не можем, у нас css из-за ваших джунов до 35мб вырос, а ваш горшочек всё ещё не останавливается". И только 1 раз была реально техническая невозможность из-за использования либы фронтовой, и там просто выбор был по сути - уложить проект в 2 раза по времени, но воткнуть еще 1 либу, или всё же подрисовать под либу без особого потеряторства качества и смысла. Ещё бывает, конечно, ваша задумка использовать реактивные элементы на проекте за 15000 рублей в шаблоне вордпресса, но это уже другая история, там не так не могут, там вообще ничего не могут)
А так оборачиваюсь назад на работу в студии или в проектах - и да, мне везло с фронтами адекватными, а вот с дизайнерами только в инхаусе впервые рад работать, ну и был опытный сильный фрилансер один. Всё остальные дизы как на подбор просто - 50 оттенков серого, никакого ритма, пробел в графе "типографика" и всё такое) Но какие бюджеты были, видимо, такие и дизы, че на зеркало пенять.
думаю что можно поискать либы готовые для реализации визуала, если это фронтенд, или задать много вопросов "почему?" и найти решение, но бэкграунд должен позволять общаться с разработчиками на одном языке.
Какие плюсы и минусы атомарной системы дизайна?
Комментарий недоступен
в поисковике забанили?
слишком много информации общей в поисковиках, хотелось услышать ответ от коллег напрямую, а так-же поддержать беседу и пост
Это довольно абсурдная ситуация на мой взгляд. Задача дизайнера спроектировать понятный/удобный сайт/интерфейс, задача верстальщика собрать его так как задумано. Это как учить доктора как лечить. Сомневаюсь, что дизайнер подходит к верстальщику и рассказывает как ему верстать, в каком порядке грузить плагины и ТД и ТП. Оценивать правильность решений должен арт.дир или старший дизайнер если такие вопросы возникают. Надеюсь понятно мысль изложил)