Дизайнеры и разработчики: заклятые друзья и лучшие враги
Привет, Хабр! Меня зовут Лена Жукова, я фронтенд-разработчик в Сбертехе.
В посте я разберу не новую, но всегда актуальную тему — взаимоотношения дизайнера и фронтенд-разработчика. Статья пригодится новичкам и командам, у которых еще не выстроены процессы работы. Рассмотрим несколько примеров из жизни и попробуем разобраться, как избежать разногласий.
Наверняка большинство читателей Хабр сталкивались с такими ситуациями.
1. Непонятные термины
Вместо комментариев по верстке разработчик получил непонятные термины, либо дизайнер не понимает терминов верстки. Это связано с тем, что каждый рассматривает продукт из своей области. Поэтому стоит использовать общий словарь терминов.
Например, в дизайне есть понятие интерлиньяж, который дословно означает «между линий». Аналогом в верстке является line-height.
Отсюда вытекает интересный вопрос — должен ли дизайнер понимать код, а разработчик понимать принципы дизайна? В статье «Почему дизайнер и разработчик должны работать вместе» автор дает советы по этому поводу. Чтобы преодолеть разрыв, разработчик и дизайнер должны говорить на одном языке и, по возможности, расширять свои наборы навыков.
И дизайнер, и разработчик должны иметь базовые знания:
- основ дизайна, таких как цвета и шрифты
- оптимальных графических форматов и калибровки
- HTML и CSS
- тенденций в дизайне и разработке
- потребностей и желаний пользователя
- сеток, рамок и каркасного моделирования
В реальной жизни все бывает не так идеально, поэтому не стоит ругать дизайнера, если он не хочет учить верстку, или обвинять разработчика в том, что он по-своему видит интерфейс.
Совет. Объясните коллеге какие-то моменты подробнее, и возможно, он захочет дальше развивать свои знания в этой области.
2. Это невозможно сделать
Так разработчик может ответить дизайнеру, и на это может быть множество причин: ограничения системы, близость релиза, загрузка человека. Но дизайнер не всегда до конца понимает эти технические моменты и может думать, что вы просто не хотите этим заниматься.
Совет. Спросите/объясните, почему нельзя — более простым языком, “на пальцах”, попробуйте сделать это чуть позже, либо облегчить первоначальный вариант.
3. Я что-то поменял в макете
Дизайнер может что-то поменять в макете по ряду причин: проведенному исследованию, при изменении системы, изменении процессов приложения. Здесь параллель такая — всем нам нужны четко описанные задачи. Если кто-то где-то что-то поменял и никому не сказал, то никто об этом не узнает. Очень важно договориться о микроизменениях — это совсем не сложно.
Совет. Попросите дизайнера делать в макете метки с изменениями и расставить приоритеты. Это удобное решение для визуального ориентирования. Раньше часто делали общую папку с версиями макетов и ui китами. Сейчас подобные изменения отлично подмечаются в zeplin.
4. Этого не было в макете и я придумал сам
Если не указаны состояния элементов или в макете не учитываются какие-то особенности процесса, не делайте это за дизайнера. Все могут что-то забыть или не продумать, все мы люди. В любом случае, каждый должен заниматься своей работой.
Это довольно спорный кейс, и большинство моих знакомых дизайнеров были от него не в восторге. Но есть и противоположные мнения.
5. Верстка не совпадает с макетом
Это боль каждого дизайнера, поэтому обязательно делайте дизайн-ревью (без него работа по дизайну не считается законченной). Дизайнеры подмечают каждый пиксель, помогут исправить какие-то мелочи или ошибки. Но иногда после проверки может понадобится переделать всю верстку. Чтобы этого избежать, пользуйтесь инструментами для ее проверки, например Perfect Pixel.
Если все-таки продукт отличается от макетов, причина может быть в идеальных данных. Не используйте lorem ipsum. Контент всегда является частью решения, а фейковое наполнение не даст увидеть важные интерфейсные кейсы.
6. Несоответствие дизайна
Разработчик не может понять значения элементов в макете, элементы не соответствуют области приложения или общепринятому интуитивному интерфейсу для пользователя.
Совет. Скажите об этом дизайнеру. Конечно, критика не всегда бывает приятна, но конструктивная и корректная обратная связь всегда полезна для продукта.
Вам было бы понятно что значит эта иконка?
Общие советы
При первом знакомстве команды стоит просто поговорить — узнать, с чем до этого работал каждый из вас, особенности будущей или существующей системы.
Договоритесь о четком и последовательном рабочем процессе. Работайте в общей среде, интересуйтесь друг другом. Приветствуйте креатив обеих сторон. Делитесь обратной связью.
Уважение — важный аспект, но его невозможно включить, как кнопку, его нужно заслужить своей работой. Для это нужно:
- показать, что ты умеешь слушать
- показать, что ты умеешь искать решение вместо критики
- показать, что ты ценишь свой труд и своих коллег
- показать, что ты все время развиваешься и трудишься, готов делиться знаниями и обучать других
- показать, как для тебя важно сделать именно этот продукт
- наконец показать, что ты готов преодолевать разногласия, противоречия и идеологические трения с другими участниками, если есть шанс улучшить результат.
Хорошо, когда ты готов выложить все свои силы, чтобы сделать продукт, а не выложить все свои упреки.
Итог
На самом деле, идеального рецепта нет. Ограничения создаются не просто так, а командная игра помогает их преодолеть. Реальность такова, что вся разработка — это дизайн, и весь дизайн — это разработка. Одно не может существовать без другого.
Были ли у вас подобные истории? Поделитесь в комментариях, как вы их решали или НЕ решали.
P. S. Благодарю за помощь Бориса Мануковского и Дизайн-центр Сбертеха
P. P. S. Всех с днем радио!