Дизайнер и разработчик, society6

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

5 «правил» для дизайнеров

Фото сделано William Iven, взято с Upslash

Избегайте кастомных стилей

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

Втягивайте разработчиков в работу как можно раньше

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

Прислушивайтесь к мнению* разработчиков

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

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

Изучите базовый HTML/CSS/JS

Самый лучший дизайнер из всех, с которыми я сотрудничал, когда был разработчиком программного обеспечения в SalesforceIQ, садился рядом со мной, заходил прямиком в веб инспектор и делал прототипы прямо в консоли при помощи HTML или CSS. Разработчиков очень ободряет, когда дизайнеры понимают технологии и работают, исходя из установленных ограничений. Конечно, не обязательно иметь полный набор умений из сферы фронтэнда, чтобы быть хорошим продуктовым дизайнером. Но даже самые базовые навыки сыграют большую роль. Заработайте уважение ближайших коллег, выучите немножко кода.

Соберите в кучу все мелкие правки

«Поток» — это состояние, в котором разработчики наиболее продуктивны, «в ударе». Им нужны большие отрезки времени, без перерывов, чтобы войти в «поток». Поэтому обсуждения лучше назначать на начало или конец дня, и перестать постоянно отрывать разработчика от процесса, потому что это отравляет само его существование. Да, это означает, что вашей неожиданной идее сделать синие кнопки темнее придется подождать. Процесс работы над дизайном цикличен, и изменения в нем будут всегда. Дайте маленьким изменениям скопиться, и только потом отправляйтесь с ними к разработчику. Поставьте себе порог в 5 мелких правок, и идите с ними к коллеге только когда они накопятся. Нет большей боли для разработчика, чем постоянные отвлечения от «Потока» только ради смены цвета кнопки. 7 раз.

«Дружба с разработчиком действительно может доставить много удовольствия! Если вместо споров о том „как можно, и как нельзя“ сделать в конкретном месте, поинтересоваться: „мне нужно достичь здесь вот такого эффекта, что ты можешь предложить?“, можно услышать вполне разумные и подходящие варианты :) Главное — уметь задать вектор и пояснить его наиболее логично!

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

— Елена Кудаева, старший дизайнер digital-агенства Red Collar.

5 «правил» для разработчиков

Фото William Iven, взято с Unsplash

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

Вникните в сценарий использования

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

UX сначала, остальное — потом

В изменчивом климате дизайн постоянно проходит одни и те же циклы, основываясь на пользовательских тестах и отзывах. Синяя кнопка со скругленными углами в 5 пикселей и box shadow-тень, которую вы кропотливо добавляли только вчера, сегодня уже стали зеленой кнопкой с плоским дизайном и острыми углами. Атас. Но не расстраивайтесь, просто примите это как данное, как часть процесса разработки. Сначала создайте UX-путь, функциональность, и набросайте общую дизайн-схему. Можно немного взгрустнуть, но пока не вылизывайте все до пикселя. После всех тестов и окончательного утверждения дизайна можно начинать постепенно вводить визуальные элементы в код.

Возражайте (и двигайте свои идеи)

Иногда дизайнеры просят сделать какой-то особенный элемент, который меняет цвета и подпрыгивает раз в пару минут. Не слушайте. Дизайн — двустороннее взаимодействие. Не бойтесь возразить и высказать свое мнение насчет ограничений и технической стороны вопроса. Даже у самого лучшего дизайнера нет вашей технической хватки или понимания процессов. Но простого возражения и фразы «Так сделать не получится» недостаточно, предлагайте свои варианты. Попробуйте так: «Сделать так будет очень дорого, давай попробуем...». Не забывайте, что благодаря современным инструментам большинство вещей воплотить в жизнь реально, но это не значит, что нужно делать все, что технически возможно. Задача инженера — помочь дизайнеру прийти к самому лучшему и выгодному решению проблемы.

Почаще говорите с дизайнерами

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

Заполняйте пробелы**

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

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

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

— фронтенд-разработчик digital-агенства Red Collar, Владимир Лукашов.

Ну вот и все! 5 советов, которые я собрал как для дизайнеров, так и для разработчиков, чтобы помочь улучшить рабочие процессы. Все эти советы крайне субъективны и основаны на моем былом опыте работы специалистом программного обеспечения и текущем опыте работы продуктовым дизайнером. Дайте знать, насколько вы согласны (или не согласны) с моим мнением в комментариях.