Недавно в нашем канале Грядка мы попросили фронтов поделиться, что их больше всего бесит в работе с дизайнерами. Они рассказали так много, у нас вышла целая серия постов. А в этой статье я хочу кратко поделиться основными выводами.
Как готовить макеты
Если изначально вы аккуратно и внимательно создали макет, он не потребует какой-то особой подготовки к передаче в разработку. Но как понять, что вы всё сделали правильно? Придерживайтесь этих правил, чтобы снизить пинг-понг при согласовании.
Заранее обсудите задачу с разработчиком
Есть большой соблазн сделать свою часть работы, скинуть макет разработчику, а дальше — это уже не ваши проблемы. Вероятность, что при этом получится качественный продукт, крайне мала.
Идеальный план — передать макет на ревью фронту до его согласования и передачи в разработку. Так можно заранее проверить, не нарушает ли решение целостность архитектуры, насколько оно соответствует UI-киту и вообще реализуемо. Работайте с фидбеком, фронты могут посоветовать, как упростить интерфейс и сократить количество шагов.
А ещё тет-а-тет звонок поможет понять, где можно сэкономить ресурсы. Если функционал горит, обсудить, что критично, а что можно временно опустить.
Проверьте консистентность
Перед тем как передавать макеты в разработку, проверьте отступы на странице. Они должны быть одинаковыми для каждого блока или компонента. Например, если у вас между заголовком и блоком отступ 24px, используйте это правило во всех блоках.
Убедитесь, что одинаковые повторяющиеся компоненты на странице работают и выглядят идентично. Например, кнопки должны быть одного размера, следовать одним цветовым правилам и логике работы. Если элементы выполняют похожую функцию, но выглядят по-разному, смело применяйте принцип бритвы Оккама, избавляясь от лишних сущностей и приводя их к единому виду.
Также стоит проверить размеры элементов на странице и выстроены ли они по сетке.
Продумайте все возможные сценарии
Как будет выглядеть макет, если значений будет слишком много? А если их не будет вовсе? Позаботьтесь о том, чтобы учесть каждое состояние: отрисуйте эдж-кейсы, лоадеры и скелетоны. Иногда это может поменять основной сценарий реализации.
Подумайте, сколько разрешений понадобится для адаптивной версии. Этот момент лучше заранее обсудить с разработчиком. Чтобы сценарии лучше читались, постройте понятный сторителлинг в фигме. Используйте стрелки и подписывайте действия пользователя — так команде будет намного легче понять логику и последовательность сценария. А ещё это сэкономит время на звонки и синки, ведь вам не придётся голосом объяснять команде, куда нужно тыкать.
Понятно подпишите слои
Одни аккуратно подписывают каждый слой в фигме, а другие используют Frame123457, приводя в бешенство коллег. Мы советуем использовать в макетах семантическое (смысловое) именование.
В чём суть: вы присваиваете всем элементам дизайна значимые и описательные названия в зависимости от функций. Этот подход помогает быстро идентифицировать элементы дизайна и эффективно использовать их с меньшим количеством ошибок.
Да, в процессе работы придётся потратить немного времени, чтобы навести порядок. Но чёткая иерархическая структура поможет разработчикам легко ориентироваться в вашем макете и не называть вас словами на «б», «п» и «х».
Используйте компоненты
Присвоение имён слоям не только помогает поддерживать порядок в файле, но помогает создать согласованную и масштабируемую дизайн-систему.
Круто, когда у команд дизайна и фронта есть общий набор компонентов и иконок — на каждый новый мокап есть готовые сеты. При этом дизайнеры должны использовать только те размеры, шрифты и цвета, которые синхронизированы между двумя командами.
Отступления от дизайн-системы — штука, которую нужно постоянно контролировать. Выносите на обсуждение с командой новые элементы, иначе через год-два ваша дизайн-система превратится в кашу.
Основные ошибки дизайнеров
- Уход от дизайн-системы: элементы интерфейса с одной функцией выглядит по-разному.
- Элемент неконсистентны. Некорректный экспорт картинок или иконок из фигмы. Вместо макетов — скриншоты.
- Макеты без учёта специфики целевых устройств или платформы.
- Не отрисованы возможные сценарии: уведомления, сообщения об ошибках, валидация полей. Нет лоадера или скелетона.
- Непродуманный UX с учётом специфики ЦА.
- Затратные по времени реализации украшательства UI, которые не решают бизнес-задачу.
- Попытка согласовать весь проект сразу вместо итераций.
- Игнорирование полученных ранее комментариев.
- Внесение изменений в макеты во время разработки без предупреждения.
Какие выводы
Понимание особенностей платформы дизайнером и знание UX-нюансов разрабами поможет решить большинство вопросов ещё на этапе создания макетов. Главное — коммуникация и готовность к изменениям.
А чтобы процессы строились легче, составил для вас чек-лист, как взаимодействовать с разработчиками, в своём тг-канале Грядка.
