Чтобы придуманный вами дизайн сайта или приложения качественно и быстро воплотили в жизнь, важно грамотно провести передачу созданного макета разработчику или заказчику. В этой статье я постарался описать ключевые моменты — как проверить, что ваш макет готов к реализации.
Скажу сразу: здесь описана идеальная картина мира. В реальности не всегда получается идти по такому плану. Но попробовать стоит.
Пообщайтесь с заказчиком и разработчиком для понимания, что собой в целом представляет проект. Это важно по многим причинам. Те же технические ограничения могут потребовать от вас нарисовать что-то определенным образом. Например, у сервера интернет-магазина обработка запроса на покупку товара занимает 30 секунд. В таком случае нужно нарисовать модальное окно с сообщением, что заявка обрабатывается и менеджер скоро свяжется с покупателем.
Выясните, что вам нужно нарисовать в первую очередь. Если на разработку чекаута с обработкой запроса, показом почтовых отделений, подгрузкой способов оплаты товара и прочего уйдет на две недели больше, то логичнее начать с этого, чем с создания обычной главной страницы.
Предварительное общение с разработчиком также поможет вам понять, в каком виде он хочет получить макет, с какой сопроводительной документацией.
Обсудив все это заранее, вы не только сэкономите время обеим сторонам, но и покажете свой профессиональный подход к процессу разработки.
А когда приступите к дизайну, делитесь со второй стороной промежуточными результатами, спрашивайте у клиента и разработчика, что добавить и в каком виде, а что — убрать.
Ведь вы все вместе создаете продукт, с которым пользователю должно быть удобно взаимодействовать.
Пройдемся по чек-листу:
В идеальном мире макет прежде всего нужно выкачать. Это позволяют сделать все инструменты: Figma, Sketch, Adobe XD, Photoshop. Все-таки лучше иметь проект в исходном формате на всегда доступном физическом носителе. Это удобно и для заказчика, который будет иметь заказанный дизайн, что называется, у себя на руках.
В макете все должно быть четко структурировано, без лишних деталей.
То же самое касается и moodboards с забракованными концепциями. Последние могут демонстрировать проработку дизайна и общий объем работы.
Также в макете стоит учесть и разные размеры экрана. Если дизайн был нарисован под десктоп, например, шириной 1440 пикселей, надо подумать, как макет будет выглядеть уже на дисплее с разрешением 1920.
А проблемы могут быть самыми разными: фотография может некрасиво растянуться, иллюстрация может прижиматься к краю экрана и при увеличении этого самого экрана «съезжать» со своего места. С одной стороны, можно ее не привязывать к краю, но тогда между ней и границей дисплея образуется ненужная пустота. С другой же — при привязке к краю пустота появится уже посередине дизайна, что тоже вряд ли будет хорошо смотреться. Лучше всего в таком случае использовать масштабирование. Но тогда уже нужно выбирать фотографии такого качества, чтобы они могли растягиваться без ущерба для дизайна.
Конечно, подобная проблема встречается далеко не часто. Но продумывать поведение разных элементов интерфейса на разных экранах и подбирать файлы с учетом таких ситуаций нужно всегда.
Нужно показать и различные состояния для всех изменяющихся элементов и страниц. Например, что делать, когда форма не заполнена/заполнена и возникла ошибка? А что показывать, если человек зашел в «Корзину», а там нет товаров? Все это надо прорисовать на случай, если у пользователя что-то пойдет не так.
Спецификации — это те источники данных, которые интересуют разработчика в первую очередь. Им стоит уделить особое внимание.
Выгрузить спецификации для разработчика можно разными способами. Самый простой — отправка ссылки из Figma. При открытии проекта разработчик сможет перейти во вкладку прототипирования и пункт Inspect. Кроме текстовых и цветовых стилей, там можно выбирать отдельные элементы дизайна (например, кнопки) с названиями, размерами и прочими параметрами. При этом можно менять единицы измерения под CSS, iOS и Android. Обычно спецификаций из Figma для работы разработчика более чем достаточно.
Существуют и другие решения. Например, Zeplin. Он предназначен исключительно для спецификаций — рисовать в нем невозможно.
Zeplin — это, по сути, плагин под Figma, Sketch, Adobe XD и Photoshop. Для его использования надо регистрироваться, а ключевая логика — синхронизация всех фреймов в макете.
После их выгрузки в сервис остается только расшарить весь проект для разработчика. А он уже сможет смотреть макеты в целом и отдельные элементы, их свойства, стили, код.
У Zeplin в разы больше доступного и важного функционала для разработчика, чем в Figma. В нем можно найти сборник всех стилей, фактически Style Guide. Зачастую, конечно, можно обойтись и базовыми спецификациями в Figma или обратиться к Avocode со схожим функционалом. А правильнее всего будет узнать у самого разработчика, что ему больше подойдет.
Документация обычно создается на отдельной странице в макете и содержит все элементы: кнопки, инпуты, иконки — все это сделает работу другого дизайнера при знакомстве с проектом намного проще. Сопроводительную документацию можно создать в виде ссылки (даже на ту же Figma).
В зависимости от сложности и размера проекта документация может вмещать разный объем информации, что отражается и на ее формате. Есть три таких формата:
В идеале лучше называть стили и компоненты как в языке разметки HTML/CSS и использовать английский. Если надо подписать, например, иконки, то я беру для названия то, что на них изображено или где они используются. Единственное из верстки — это navigation, header, footer, input. Также можно работать с сокращениями: как btn для button или btn secondary и btn primary (второстепенная и первичная кнопки).
Читайте также: Прислушиваясь к советам от Google: как оформлять кнопки в интерфейсе
Когда дизайнер нарисовал один фрейм, за ним еще один, следующую страницу и далее, в какой-то момент их количество может превысить несколько десятков. Разработчик, заказчик или другой дизайнер при знакомстве с проектом может попросту не разобраться в их взаимосвязи. А с картой экранов, где будут стрелки и комментарии, легко понять связь всех страниц между собой. Пригодится она прежде всего для больших проектов (мобильные приложения или мобильные версии сайтов).
Оформлять карту вы можете подписями в духе «Если нажать на эту кнопку или пункт меню, произойдет переход на вот этот экран».
Причем в особо сложных проектах из такого описания может следовать даже две стрелки, с переходами на разные страницы — для ситуаций, когда пользователь залогинен и не залогинен.
Кликабельный прототип требуется разработчику по тем же соображениям, что и карта экранов. Он помогает понять, как работают разные элементы. Создавать кликабельные прототипы можно в Figma, Adobe XD, Invision, Axure. Последний раньше считался стандартом среди инструментов прототипирования из-за своего богатого функционала.
Например, многим нравилась возможность делать поля ввода именно полями ввода: кликаешь на них и можешь что-то написать. В Figma поле ввода — это обычный прямоугольник с рамкой. В ней максимум, что можно — показать его состояния, но без интерактива. А вот Axure — достаточно сложный. Сегодня его чаще используют бизнес-аналитики для создания вайрфреймов
В идеале их все нужно выкачать и отдать разработчику одним архивом. В Figma и Adobe XD можно экспортировать каждую иконку, но если их будет очень много, то разработчику придется обходить по очереди все экраны, находить и кликать на каждую иконку. Поэтому лучше упростить ему задачу и позаботиться о соратнике по команде.
Что касается фотографий, то всегда следует передавать исходники. Почему только так? Во-первых, иллюстрации позже могут выводиться на большие мониторы, и качество картинки может ухудшиться. Во-вторых, оригинал пригодится, когда иллюстрации были вырезаны какой-то маской. Разработчик сможет сам подрезать снимок или кадрировать его. Ведь эта же фотография может использоваться и в других проектах.
Отдельно стоит сказать о названиях графических элементов:
Например, название иконки можно формировать по четкому принципу: ic, затем нижнее подчеркивание, место нахождения, нижнее подчеркивание и, собственно, что это за иконка. Получится вот такое: ic_main_catalog.
Шрифты стоит складывать в отдельную папку, чтобы разработчик не искал их подолгу в интернете. Особенно это критично, когда выбран нестандартный или платный шрифт. В таких ситуациях девелопер тратит лишнее время и деньги, и может найти не ту версию шрифта. Кроме архива, также можете давать ссылку на использованный шрифт (например, из Google Fonts).
Поделитесь с разработчиком анимацией в формате видео или ссылкой на анимированный прототип в Figma, линк на CodePen либо же сайт, где уже реализована схожая анимация.
Про CodePen скажу отдельно. Этот сервис предлагает огромный открытый архив с различными анимациями. Они называются пинами и — что самое важное — могут содержать код: HTML, CSS и JS (иногда все сразу, иногда только часть из них). Чтобы воспользоваться сервисом, достаточно ввести в поиске, например, «button», чтобы получить сотни вариантов анимации перехода от одного состояния кнопки к другому — и все со столь желанной разработчиками «кодовой» реализацией. Остается выбрать подходящий пин, скопировать ссылку на него и передать линк разработчику.
Сейчас мне удается следовать перечисленным выше шагам, но я не выполняю их за раз. Мой подход выглядит так: нарисовал функционал — передал разработчику, нарисовал иконки — отдал их и так далее.
Не всегда и не у всех получается делать так же, и это нормально. В любом случае вам нужно обязательно выяснить все нюансы о конкретном проекте. Надеюсь, описанная мною инструкция поможет вам организовать эффективное взаимодействие в паре разработчик-дизайнер.
Читайте также: Как оформить навигацию по сайту, чтобы на нем захотелось остаться: советы и чек-лист от дизайнера
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…