Дизайнеры и разработчики: заклятые друзья и лучшие враги +10


Привет, Хабр! Меня зовут Лена Жукова, я фронтенд-разработчик в Сбертехе.

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



Наверняка большинство читателей Хабр сталкивались с такими ситуациями.

1. Непонятные термины


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

Например, в дизайне есть понятие интерлиньяж, который дословно означает «между линий». Аналогом в верстке является line-height.

Отсюда вытекает интересный вопрос — должен ли дизайнер понимать код, а разработчик понимать принципы дизайна? В статье «Почему дизайнер и разработчик должны работать вместе» автор дает советы по этому поводу. Чтобы преодолеть разрыв, разработчик и дизайнер должны говорить на одном языке и, по возможности, расширять свои наборы навыков.

И дизайнер, и разработчик должны иметь базовые знания:

  • основ дизайна, таких как цвета и шрифты
  • оптимальных графических форматов и калибровки
  • HTML и CSS
  • тенденций в дизайне и разработке
  • потребностей и желаний пользователя
  • сеток, рамок и каркасного моделирования

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

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

2. Это невозможно сделать


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

Совет. Спросите/объясните, почему нельзя — более простым языком, “на пальцах”, попробуйте сделать это чуть позже, либо облегчить первоначальный вариант.

3. Я что-то поменял в макете


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

Совет. Попросите дизайнера делать в макете метки с изменениями и расставить приоритеты. Это удобное решение для визуального ориентирования. Раньше часто делали общую папку с версиями макетов и ui китами. Сейчас подобные изменения отлично подмечаются в zeplin.



4. Этого не было в макете и я придумал сам


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

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

5. Верстка не совпадает с макетом


Это боль каждого дизайнера, поэтому обязательно делайте дизайн-ревью (без него работа по дизайну не считается законченной). Дизайнеры подмечают каждый пиксель, помогут исправить какие-то мелочи или ошибки. Но иногда после проверки может понадобится переделать всю верстку. Чтобы этого избежать, пользуйтесь инструментами для ее проверки, например Perfect Pixel.

Если все-таки продукт отличается от макетов, причина может быть в идеальных данных. Не используйте lorem ipsum. Контент всегда является частью решения, а фейковое наполнение не даст увидеть важные интерфейсные кейсы.

6. Несоответствие дизайна


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


Вам было бы понятно что значит эта иконка?

Общие советы


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

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

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

Хорошо, когда ты готов выложить все свои силы, чтобы сделать продукт, а не выложить все свои упреки.

Итог


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

Были ли у вас подобные истории? Поделитесь в комментариях, как вы их решали или НЕ решали.

P. S. Благодарю за помощь Бориса Мануковского и Дизайн-центр Сбертеха

P. P. S. Всех с днем радио!




К сожалению, не доступен сервер mySQL