«Я — художник, я так вижу». Дизайнер отвечает на вопросы фронтенд-разработчика
Главный по фронтенду в Меркури задает острые вопросы главному по дизайну. Собрали самые важные поинты из почти полуторачасового видео и получили список советов, которые помогут находить общий язык в спорных вопросах.
Почему надо всегда делать дизайн-систему, но на практике получается не всегда
Никто не спорит, что компонентный подход — это важно. Но на практике создание дизайн-системы занимает дополнительное время дизайнера, за которое заказчики не всегда готовы платить.
Чтобы создавать библиотеку компонентов, нужно добавлять дизайн-элементы по ходу работы над экранами, иначе получится эффект снежного кома. Не будет такого, что в один прекрасный день дизайнер соберет библиотеку из всего, что он рисовал до этого полгода.
Как только понимаете, что дизайн очередного экрана утвержден, добавляйте повторяющиеся элементы в компоненты. Чем больше компонентов соберет дизайнер, тем меньше времени будет занимать создание каждого следующего экрана. А разработчики будут знать, какой элемент можно переиспользовать, а какой придется верстать с нуля.
По возможности сразу создавайте библиотеку с темплейтами — со временем ее можно будет превратить в полноценную дизайн-систему. К счастью и Фигма, и Скетч позволяют легко настраивать зависимости и поведение лейаутов.
Как дизайнерам аргументировать свои решения
Нет, так не надо
К счастью, дизайнерам не обязательно рассказывать разработчикам всю теорию UX, чтобы объяснить свою логику. Как минимум можно аргументировать с помощью принятых паттернов.
Дизайнер продумывает состояния экранов заранее
Даже если нужно нарисовать только базовое состояние экрана, грамотный дизайнер всегда мыслит на пару шагов вперед: что будет, если пользователь нажмет не на ту кнопку или введет в форму что-нибудь не то. Тут как в арифметике — один экран рисуем, два в уме.
Например, дизайнер нарисовал форму регистрации и забыл заранее продумать экран, когда пользователь введет невалидные данные. В итоге где-то под формой дорисовал ошибку, и при заполнении начинается Layout Shift.
Как дизайнеру и разработчику понимать друг друга
Мало просто кинуть в разработчика макетами в надежде, что он прочтет ваши мысли. Оставляйте комменты и объясняйте коллегам свои решения.
Например, нарисовали форму с тусклой кнопкой. По задумке дизайнера она только выглядит задизейбленной, но остается кликабельной. Без комментариев разработчик вряд ли угадает это решение.
Неочевидные закономерности в дизайне, которые помогут разработчикам понять, что баг, а что фича
Размеры кратны четным числам
Все размеры должны быть кратны четным числам: двум, четырем, а лучше восьми. Это общее правило, но есть исключения на разных платформах.
Все по сетке
Интерфейс должен быть нарисован по сетке. Если это не так, скорее всего это ошибка, и дизайнеру следует подогнать макет.
Дизайнеры стремятся все универсализировать. Если разработчик видит, что в макете что-то выбивается, скорее всего, так быть не должно. А чтобы узнать наверняка, лучше всего спросить.
Два мнения об инклюзивном интерфейсе
Интерфейс нужно делать доступным сразу для максимального количества пользователей. Можно провести аналогию с городским благоустройством. Возможность двигаться по городу с детской коляской никак не ущемляет права обычных пешеходов. Никто не будет делать отдельный парк для колясочников — это глупость. Так зачем нам отдельная версия сайта?
Иногда нужно сделать отдельную опцию, например, для людей с ограниченными возможностями. Для них это полезно: крупный шрифт, контрастные кнопки и т.д.
Но для большинства пользователей это может казаться непривычным и неудобным. Ради эксперимента попробуйте взять в руки бабушкин телефон. Наверняка у нее установлен увеличенный шрифт, все разъезжается. Пользоваться таким интерфейсом то еще удовольствие.
Именно поэтому интерфейс для слабовидящих должен оставаться опцией, а не быть по умолчанию для всех.
Пара советов для дизайнеров напоследок
1. Всегда доносите свои идеи до разработчиков, а не бросайтесь в них макетами. Оставляйте коменты в Фигме с описанием, как все должно работать: то, что очевидно вам, может быть не так очевидно другому человеку.
2. Времени на сбор компонентов не будет никогда, поэтому старайтесь собирать компоненты или символы сразу по ходу работы. Затем постепенно превращайте их в библиотеки компонентов, а потом в дизайн-системы.
Мы собираемся записать обратный ролик с вопросами дизайнеров к разработчикам. Вы тоже можете поучаствовать и накидать свои вопросы. Если напишите в комментах, какие у вас есть боли и претензии — наш артдир Денис с удовольствием «предъявит» их ведущему фронтендеру 🙂