Designer vs Front-end Developer. Как перестать ссориться и начать жить | by Илона Саркисова | Aug, 2020

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

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

Разные способы мышления

В психологии труда выделяют следующие образы мышления:

• Наглядно-действенное мышление (ВЗАИМОДЕЙСТВИЕ) — наиболее элементарное. Восприятие происходит в процессе взаимодействия. Присущ детям.
• Наглядно-образное мышление (ГЕНЕРАЦИЯ) — основано на представлениях и образах. Позволяет объединить набор разнородных вещей в целостную картину. Отвлеченные мысли, обобщения человек воплощает в конкретные образы. Типичный результат такого мышления — картина Демон или книга Война и Мир.
• Словесно-логическое мышление (АНАЛИЗ) — основано на логических операциях с поня­тиями (позволяет познавать закономерности и нена­блюдаемые взаимосвязи реальности). Продуктами такого мышления являются, например, открытие Периодической системы Менделеева, математические и философские законы.

Вид мышления формируется у человека в процессе деятельности и может меняться.
Мы не рождаемся с ним, просто один нам привычнее.

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

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

Благодаря тому, что мы разные, получается полноценный продукт.

Разный фокус

Из первой причины вытекает вторая: разные задачи и фокус внимания.

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

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

То, на чем сфокусирован человек кажется ему наиболее важным.
Очевидно что для дизайнера и программиста важны разные вещи.

Профдеформация

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

Образ мышления, схожесть задач и фокус внимания, если они сохраняются длительное время, профессионально деформируют человека.

Еще одна причина недопонимания — это то, что дизайнеры и разработчики профдеформированы по-разному.

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

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

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

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

Смутное понимание процесса работы коллеги

Да, дизайнеры знают, что программисты пишут код. Но как именно?

Мало кто из дизайнеров в деталях знаком с программированием, с его сложностями и подводными камнями.
Равно как и программисты не представляют, как именно работает дизайнер и с какими сложностями сталкивается.

Жесткие установки границ ответственности

“Не моя проблема”
“Им за это деньги платят”
“Ты в этом разбираешься, ты и делай”
Это удобно. Всегда ясно, с кого спросить и кто виноват.

Таким подходом отличаются организации за пределами счастливого пузыря IT. Часто должностная структура в муниципальных организациях многоуровнева, незыблема и священна, а «not my job» — священная мантра.

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

Предубеждения

«Вы надизайнили свое творчество, а нам разгребать…»
«Ну это программисты, они же только код писать умеют…»

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

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

Решение такой многогранной проблемы, как коммуникация — комплексное. Я постаралась сформулировать несколько принципов, которых придерживаюсь сама и которые помогают мне в работе.

Активировать эмпатию

Про коллегу вам важно понять три вещи:

1. Ваш коллега не тупой.
   В большинстве случаев у разработчиков такой же богатый опыт, как и у вас. И поверьте, разработчик может подсказать UX-решение, может дать дельный совет.
2. Ваш коллега не бездельник.
   Никто не ковыряет в носу по 8 часов в день. “Фронтендеры делают черт знает что и в макеты даже не смотрят”. Это не потому что они лентяи. Просто у них много времени уходит на проектирование архитектуры кода, что, на минуточку, нисколько не быстрее, чем проектирование архитектуры интерфейса.
3. Ваш коллега не только пишет код.
   Разработчик ежедневно решает специфичные проблемы, о которых вы даже не подозреваете.
   Простой пример: фронтендер Василий перекрасил кнопки в оранжевый. В это же время разработчик Петр перекрасил часть кнопок в светло-оранжевый. Они оба “сливают” свой код в общий репозиторий и система выдает конфликт. Этот — не сложный. Но бывают конфликты, для решения которых нужно часами анализировать два кода (свой и чужой), и выискивать ошибки.

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

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

Разговаривать, а не спорить

На совещании фрондендер говорит: “Это редизайн? Да это вообще новая система! А у нас пользователи уже привыкли!”

Что слышит дизайнер: “Дизайнер вообще никуда не годится. Он о пользователях не думает. Тоже мне специалист”

Что при этом чувствует фрондендер: “Нам все с нуля переписывать. Сколько работы! Если не взлетит, клиент будет недоволен, а нам огребать и переделывать”.

Фрондендер критикует не дизайнера. Он критикует новый дизайн. И за этой критикой стоит страх и неуверенность.
Вам не стоит расстраиваться. Лучше спросите коллегу, что конкретно его смущает. Объясните, откуда взялся тот или иной дизайн, приведите примеры, результаты исследований.
Только не делайте это оружием спора. Лучше используйте технику “5 почему”, чтобы докопаться до истинной боли коллеги.

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

Помнить о единой цели

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

Думать коллективно

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

Играть в команде

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

Работа в проекте — это эстафета. Будьте готовы поддержать своего разработчика и помочь ему. Если ему нужны дополнительные макеты или объяснения — будьте командным игроком. Do your best.

Говорить на одном языке

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

Например, макеты дизайнер и разработчик видят по-разному.
Если для дизайнера кнопка — это синий прямоугольник размера 100x40px с текстом Arial 14px, то для верстальщика та же кнопка — объект класса .primary-button шириной в 20% контейнера и высотой auto, отступами 11 40 40 11. А бэкенд разработчик видит несчастную кнопку, как объект, который вызывает функцию Function() и отправляет набор данных, который надо распарсить и обработать.

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

Соблюдать консистентность

Если вы отрисовали основную кнопку синей 100x40px с текстом Arial 14px, то такими должны быть все кнопки основного действия в интерфейсе.
Договоритесь о правилах поведения компонентов, создайте UI kit и строго следуйте ему.
В организации компонентов мне помогает подход Умные и тупые компоненты.

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

Следовать сетке

Сетки — мега-удобный инструмент расстановки элементов на экране. Главная ошибка, которую допускают дизайнеры — нечеткое следование сетке.
К примеру, колонок 12, а элементов в ряд хочется 13. Не нужно фигачить элемент, игнорируя сетку. Разработчики потом об это руки поломают.

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

Позаботьтесь о коллеге

Отрисовывая макеты, не забывайте, что их увидит не только клиент. С ними будет работать фронтендер и ему нужно даже больше, чем клиенту.

1. Сделайте легче UI. Если можете разгрузить компоненты от теней, градиентов и сложных графических элементов — сделайте это. Легкие компоненты легче верстать, легче предсказать их поведение.
2. Продумывайте состояния. Если сомневаетесь, узнайте у фрондендера, какие состояния бывают у того или иного компонента интерфейса.
3. Отрисовывайте сценарии, а не отдельные макеты. Стрелки, кликабельные прототипы и комментарии помогают разработчику понять идею и то, как все связано.
4. Документируйте. Опишите отдельно поведение компонентов, правила и детали, которые не влезают на макеты.

Травить леску

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

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

Тимбилдить

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