Зачем фронтендеру разбираться в дизайне

Дизайнеры и разработчики решают одну задачу, но смотрят на неё с разных сторон. Чтобы научиться взаимопониманию, нужно погрузиться в предметную область друг друга: дизайнерам нужно понимать HTML и CSS, а разработчикам — знать основы дизайна.

Умение видеть ошибки и отличать от задумки

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

Пример: разные отступы внутри кнопки с левой и правой стороны.

На иллюстрации ниже две кнопки с разными отступами, но в одной это задумка дизайнера, а в другой — ошибка.

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

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

Выровнять отступы можно только у кнопки справа. Для кнопки с иконкой это ухудшит отображение.

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

Восполнение пробелов

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

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

Пример: в дизайне не прорисовано состояние ошибки при загрузке компонента с данными.

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

Как с этим справиться: зайти на ресурс со сборником типовых компонентов и найти компонент Alert. На странице компонента вы найдёте множество примеров его реализации из разных библиотек: выбирайте подходящий и используйте как образец. Для этого не нужны глубокие знания дизайна, а вот базовое понимание композиции поможет сделать компонент понятным, аккуратным и красивым.

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

Общение с дизайнером

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

В вашей команде может оказаться неопытный дизайнер, который ещё не знаком с некоторыми нюансами разработки веб-интерфейсов. Объясняясь с ним на его языке, вам будет проще донести информацию.

Пример: дизайнер увидел в готовой вёрстке состояние фокуса и попросил убрать «странные прямоугольники».

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

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

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

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

Работа с макетом

Графические редакторы

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

Пример: разработчику нужно получить цвета из макета в Figma. Он находит цвет в режиме просмотра и постепенно переносит цвета по переменным.

Такой способ долгий и неудобный. Если бы разработчик знал возможности редактора, то воспользовался бы плагином, например Color Import/Export, и выгрузил все цвета разом. А ещё он мог бы договориться с дизайн-командой использовать Figma Tokens.

Или другой пример: когда дизайнер создаёт коллаж с интерактивными элементами, он не может предугадать, как именно разработчик станет его собирать. Намного проще настроить группировки и экспорт графики самому, чем объяснять всё это дизайнеру. А для этого нужны минимальные навыки работы с макетом.

Если вы планируете изучить редакторы, начинайте с Figma — де-факто это стандарт индустрии.

Сетки

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

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

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

Типографика

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

Пример: разработчику нужно создать карточку товара на сайте, а дизайнера нет или он занят. Придётся делать самому.

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

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

Цвет

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

Пример: дизайнер не проработал состояния элементов, и разработчику необходимо их доработать самому.

Большинство операций с состояниями делаются при помощи цвета. Например, при наведении элемент осветляется или затемняется, а для фокуса выбирается более контрастный цвет.

Если разработчик умеет правильно менять тональность и пользуется такими инструментами, как Huetone, то сможет проделать хорошую работу. А если не умеет — при изменении цвета может потеряться тон.

Анимации

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

Пример: разработчика попросили добавить плавности в готовом проекте.

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

Базовый UX

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

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

Адаптивность

Назвать адаптивность отдельным навыком сложно. Здесь потребуется и понимание композиции в целом, и умение работать с сетками, и знание типографики, а также хорошее понимание UX, так как понадобится менять элементы управления и структуру информации.

Так нужно ли разработчику разбираться в дизайне

Понимание дизайна — не основной навык разработчика, но он точно будет полезен.

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

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

Дополнительные материалы:

• Основы дизайна для верстальщика
• Как подготовить вёрстку к Retina-экранам
• Как сверстать макет. Пошаговый план

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.