Кто прав: дизайнеры или разработчики?

Извечный спор. Дизайнеры с их воздушными замками против разработчиков с их бездушным кодом и грамма фантазии. Кто тупее всех на свете?

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

Проблема заключается в том, что и разработчики и дизайнеры смотрят друг на друга как разъяренный родитель, которому проще отлупить ребенка или прожечь его взглядом ненависти насквозь, чем попытаться хоть что-то объяснить. Ведь в голове просто не укладывается: «Ну кааааааак?! Как можно не знать и не понимать этот базовый минимум? Он(а), что совсем тук-тук откройся?»

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

Не молча ненавидеть и устраивать истерику с разборками. А задавайте вопросы: почему в макете так, а не иначе? Как это устроено? А есть ли обходные пути?

Как и когда начинать дружить?

Не на этапе «я всё сделал, дальше сам как хочешь разбирайся», а в идеале — ещё на этапе user flow. Подключите разработчика до того, как вы нарисовали все макеты и собрали красивый кит. Ведь уже на этапе флоу разработчик может сказать: «Эту штуку сделать легко, а вот эта будет долго, дорого и больно». Так вы сэкономите время, деньги и нервы — себе, заказчику и разработчику.

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

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

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

Каждый разработчик — отдельная вселенная

Как и дизайнер. Я в дизайне 10 лет, из них 6 лет в веб-дизайне, и 3 — в продуктах. Работала с лендингами и с крупными платформами на 100+ страниц, маркетплейсами, интернет-магазинами и даже с госуслугами. Была в крупных компаниях, стартапах и маленьких ламповых командах. И вот что я скажу: каждый разработчик — мини-вселенная со своими правилами, взглядами и принципами.

Нет такого, что без кита «всё, пропало». Верстают и с frame+100500, и без библиотеки шрифтов, и без системы отступов. Вопрос только в том, согласен ли с этим работать разработчик.

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

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

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

Человек — существо ленивое

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

Существует множество исследований на тему того, как люди изучают информацию на разных носителях, в том числе и в диджитал среде. Например то, как люди сканируют информацию по F и Z-паттерну, и диаграмме Гутенберга. Это прям базовый минимум для всех, кто занимается разработкой дизайна, где тексты имеют значение.

Отсюда и «А почему здесь кнопка 50 px, когда у меня в макете 60?». Потому что разработчик тупо устал смотреть на ваш макет и искать отличия. Для него синий — это синий, и то, что вы в этом блоке сделали на тон темнее, для него не имеет значения.

Но когда вы создаёте чёткую систему: библиотеку компонентов, цветов, шрифтов, структуру и подписи так, что разработчик реально понимает, что вы сделали, — вы исключаете кучу ошибок при реализации.

А если ещё и перед передачей файла созвониться и провести за ручку, объяснить каждое решение? «Здесь так, потому что… А вот это важно реализовать так, потому что…» И если всё подкреплено фактами и исследованиями, а не «я так вижу, я художник» — донести мысль будет ещё проще.

Я также объясняю и показываю каждый экран, особенно это касается нестандартных решений. К ним делаю подробное описание, прикладываю ссылки на похожие реализации, обсуждаю: «А возможно ли это в нашем случае? Всё ли правильно подготовлено в макете или нужно изменить? Если нет, то что похожее можем сделать?»

Снимите высокомерную корону

Когда вы перестаёте быть «величайшим дизайнером» и просто пытаетесь вникнуть в работу другого человека и позаботиться о его комфорте — большинство людей это видят и ценят. И сами идут навстречу.

При таком человеческом отношении и дизайнеры, и разработчики многие мелкие правки делают бесплатно или за символическую плату, без «Я НЕ БУДУ ЭТО ДЕЛАТЬ, ПОКА ОН(А)…».

И со стороны разработчиков это работает так же. В начале пути я наткнулась на разработчика, который не послал меня, а просто по-человечески объяснил, почему так нельзя и как можно, и что важно сделать перед передачей макета. Я была на седьмом небе! Мне простым человеческим языком, без высокомерия, объяснили то, что начинающему дизайнеру не так просто найти без связей и знания правильных терминов.

Джуны есть везде

Мы любим говорить: «Ой, да что с него взять — дизайнер ещё маленький джун, ничего не знает». А про разработчиков почему-то считают, что они сразу вылупляются сеньорами.

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

Так кто же прав? Дизайнеры или разработчики?

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

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

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