Как наладить работу между дизайнерами и разработчиками?

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

Оригинал статьи

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

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

Вот некоторые части процесса, которые мы часто упускаем из виду:

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

Около 21% от размера любого сайта приходится на изображения. Из этого следует, что стоит уделять время для сжатий изображений перед отправкой их разработчикам.

Для этого можно использовать бесплатный инструмент под названием ImageOptim.

С помощью этого инструмента вы можете уменьшить размер файла на 20–80%. Но прежде всего убедитесь, что все ваши изображения организованы в папки и названы соответствующим образом.

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

Прежде всего: убедитесь, что у вас есть соответствующие лицензии.

Если вы не можете себе позволить обзавестись лицензионным оборудованием, ни в коем случае не пытайтесь украсть его. Последствия пиратства могут быть критичными. Просто используйте Google Font.

Откройте Font Book, выберите шрифты, которые вы хотите экспортировать, нажмите на File > Export Fonts и выберите место, куда вы хотите сохранить их на своём компьютере. Затем отправьте эти файлы вашей команде разработчиков.

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

Вот как это делается в Figma. Это слегка отличается от такого же процесса в Sketch, InVision или Adobe, но отличия не так велики.

Если вы не знакомы с тем, как работает определение размера шрифта для веб- и мобильных приложений, вот парочка ресурсов для начала:

Apple’s Human Interface Type Guidelines

Material Design Type Guidelines

Когда я собираю систему типографии, мне нравится визуализировать стили шрифтов, размеры, интервалы и другие детали, например:

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

Затем вам нужно задать правила, чтобы обозначить, как типография будет работать в адаптивном режиме. Масштабируется ли она динамически? Убедитесь, что вы продумали, как должен вести себя шрифт, прежде чем передать файлы разработчикам.

После того, как вы задали все свои условия, убедитесь, что дизайн ссылается на эти глобальные стили.

Ну а вот почему об этом не стоит забывать:

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

- Изменения выполняются намного быстрее: представьте, что у вас есть приложение с 120 экранами и вдруг заинтересованные стороны на полпути решают, что хотят изменить какой-то из шрифтов. Если используются стили шрифтов, изменение займёт всего 5 минут, в противном случае это может занимать и несколько часов работы.

Вот пример файла Figma с применёнными стилями. На правой панели вы можете видеть все стили. Когда я нажимаю на любой текстовый слой, он ссылается на конкретный стиль.

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

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

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

Последовательное использование цвета так же является важным пунктом при передаче проекта в dev. Если в вашем файле будут присутствовать 30 разных оттенков серого, разработчики, мягко выражаясь, будут раздражены.

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

В решении с цветом не помешает немного самодисциплины. Клиент вдруг решает, что все синие элементы должны быть фиолетовым? С цветными стилями это только пара щелчков мышью.

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

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

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

- Чётко сформулируйте контрольные точки в вашем дизайне

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

- Посмотрите, какой экран будет получать наибольшее количество трафика, и начните с него

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

- Будьте максимально последовательны при переключении между точками останова

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

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

Визуальный справочник: Dribbble, Muzli, Behance

Это то, что я считаю наименее полезным. Почему? Потому что разработчику часто бывает трудно что-то перестроить, когда всё, на что он может ссылаться, — это визуал. Я рекомендую использовать этот подход только с высококвалифицированными разработчиками.

CodePen

Если вы дизайнер и не знаете, что такое CodePen, скорее бросьте всё остальное и ознакомьтесь с ним. Это удивительный ресурс для дизайнеров и разработчиков. Вместо того, чтобы перестраивать компоненты с нуля на основе ссылок, CodePen предоставляет доступ к HTML, CSS и Javascript, что позволяет эффективнее взаимодействовать внутри проекта.

DIY: After Effects, Principle, Protopie

И последнее, но не менее важное — это DIY-маршрут. Если у вас есть опыт в анимации, вы сможете изменить правила игры. Для создания анимаций приложений, вы можете использовать After Effects и Lottie для экспорта анимации JSON.

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

Вы сделали работу. Дизайн правильно документирован, все ваши стили на месте. Всё до малейшего пикселя идеально подходит к вашему проекту. Что делать дальше?

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

- Я хотел предоставить справочную информацию о проекте

- Пройдитесь по системе проектирования и прототипу

- Кратко поясните конструкторскую документацию

- Пройдитесь по основным моментам проекта

- Уточните сроки и установите основные этапы / цели проекта

- Ответьте на вопросы

- Вдохновите команду

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

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

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

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

Используйте программное обеспечение, такое как Jira или Asana для проведения визуального контроля качества. Будьте максимально точны, описывая и документируя не только проблемы, которые вы нашли, но и предлагаемые решения. Также можете начислять себе бонусные баллы, если вы будете прикреплять фотографии к такого рода отзывам.

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

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

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

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

Больше интересных и актуальных статей ищите в нашем блоге и телеграм-канале.