Передаём макет в разработку: как не допустить ошибку

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

Если изначально вы аккуратно и внимательно создали макет, он не потребует какой-то особой подготовки к передаче в разработку. Но как понять, что вы всё сделали правильно? Придерживайтесь этих правил, чтобы снизить пинг-понг при согласовании.

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

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

А ещё тет-а-тет звонок поможет понять, где можно сэкономить ресурсы. Если функционал горит, обсудить, что критично, а что можно временно опустить.

Перед тем как передавать макеты в разработку, проверьте отступы на странице. Они должны быть одинаковыми для каждого блока или компонента. Например, если у вас между заголовком и блоком отступ 24px, используйте это правило во всех блоках.

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

Также стоит проверить размеры элементов на странице и выстроены ли они по сетке.

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

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

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

В чём суть: вы присваиваете всем элементам дизайна значимые и описательные названия в зависимости от функций. Этот подход помогает быстро идентифицировать элементы дизайна и эффективно использовать их с меньшим количеством ошибок.

Да, в процессе работы придётся потратить немного времени, чтобы навести порядок. Но чёткая иерархическая структура поможет разработчикам легко ориентироваться в вашем макете и не называть вас словами на «б», «п» и «х».

Присвоение имён слоям помогает не только поддерживать порядок в файле, но создавать согласованную масштабируемую дизайн-систему.

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

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

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

А чтобы процессы строились легче, составил для вас чек-лист, как взаимодействовать с разработчиками, в своём тг-канале Грядка.